How short can ramps be?

I've always sequenced those by placing two timing marks down and putting an intensity in there, but I can see the advantage (less grid clutter) to having a tool that will take care of sending both commands (protocol wise, this is in fact two commands).

 

Actually, for the circumstance you describe, I actually prefer to put in a short (0.05 to 0.1) full on command and then follow it up using a 50% to 0% ramp for about 0.35 seconds to 0.5 seconds (depending on the tempo).  It gives it the "pop" desired with a very subtle/non-distracting sustain (kinda like audio reverb but with lights).  Give it a try... if you like the effect I can probably automate this into a "pop tool" for 2009.  There are already plans for other "hybrid tools" like a "LED ramp" tool that will break ramps into 3 ramp commands in an attempt to linearize ramps on LEDs.

 

cheap piece of trash PIC :) <- kidding. I fully understand pushing hardware past logical points.

 

BUT, I bet that when the data is compiled to be sent down the network, knowing the limits of the hardware, and yet knowing what the user input into Aurara, Aurora could then push a blink command perhaps? nudge-nudge. something like on until 50%? Then I wouldn't see a point of a blink command, and users/onlookers wouldn't notice a blink (on-off) vs a split second fade anyway.

So fades could still work normally, going though many intensities until .15s, then they technically turn into a .075 100% on, then .075 0% off. (or 3 levels, or whatever) That's danged near the .03 that the TRIACs seem to not ba able to handle. But I think that the shortest "ramp" allowable should be .08s so that a .04s on can still be sent fairly reliably.

 

no?