How short can ramps be?
Printed From: Aurora
Category: Aurora Sequencer Software
Forum Name: Aurora 1.0
Forum Discription: This is the place to discuss (and report bugs) the 1.0 version of Aurora
URL: http://www.aurorashow.com/forum/forum_posts.asp?TID=480
Printed Date: 17 Apr 2025 at 4:48pm
Software Version: Web Wiz Forums 9.06 - http://www.webwizforums.com
Topic: How short can ramps be?
Posted By: Pony_God
Subject: How short can ramps be?
Date Posted: 11 Nov 2008 at 5:31pm
|
I'm doing a number of quick fadeouts on my mini trees that don't register at all. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite! 
|
Replies:
Posted By: ChrisL1976
Date Posted: 11 Nov 2008 at 6:01pm
I'd think 0.05 is way too short for a fade....Heck, I think its too short for a full on command. I'd throw together a quick test sequences and try some different time lengths.....0.1 0.2 0.3 and so on until you get the look you want. I'm pretty sure I dont use anything under 0.1....and that normally on either side of a solid ON command of 0.1 or longer. You eyes just dont see something that fast. ------------- Chris www.lightsonsixth.com |
Posted By: LightsOnLogan
Date Posted: 11 Nov 2008 at 6:13pm
|
0.05 is an acceptable ramp duration. There is a firmware issue with 1.15 (beta) that D-Light is aware of where short duration ramps are concerned. If you downgrade the controller firmware to 1.14 or 1.13 the problem might go away (but the old problems that those firmwares have will reappear). I expect that once 1.15 is a release firmware this will be fixed, but only D-Light can answer that (I too am waiting BTW.. I have some 0.35 ramps that are glitching on 1.15 that render properly in earlier firmwares). ------------- http://www.aurorashow.com/"> 
|
Posted By: ChrisL1976
Date Posted: 11 Nov 2008 at 8:30pm
You are right......0.05 does show up..........looks about equal to the shimmer command...Maybe is was 0.01 I was thinking....There was a big discussion on PC about this.. ------------- Chris www.lightsonsixth.com |
Posted By: Pony_God
Date Posted: 12 Nov 2008 at 9:00am
|
Ah, alright, wasn't shure if it was hardware, software, or not valid. I have two main places that I use really short ramps.
1. Think begining of "Wish Liszt" BaDummmBaDummm, although, those could be converted to ONs without a problem.
2. Think "Carol of The Bells" BummmDaDaBummm. That would be the hard one to fix because I have the roof ridges/eves/outline as the main notes so I would have had to add an off to every single marker.
So other than the short ramps in 15beta, did I miss anything else? I havn't seen anything else funny going on. Any idea when 15 will be out of beta? ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 12 Nov 2008 at 11:44am
|
If we must get this specific, 0.0154s is the fastest interval the protocol will recognize. Anything shorter is rendered by Aurora as 0.0154s.
FYI... that is 1/65th of a second. The human eye isn't even that fast... anything less than 0.02s might as well be rendered as on/off since it really doesn't matter anyway at those speeds. ------------- http://www.aurorashow.com/">
|
Posted By: Pony_God
Date Posted: 12 Nov 2008 at 11:59am
That's about what I want... Kind of a sudo "blink" command. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 12 Nov 2008 at 12:47pm
|
Send a 100% shimmer for a really short time (the command compresses really well for fast send and if you keep it short you should only get one firing pulse)?
BTW, 0.0154s is a limitation of ramps in the protocol, not of Aurora. The Aurora editor can go down to 0.001 resolution. Playback itself is limited to the frame size settings in playback properties (1280 is the default, which works out to 0.01451s). You can use a smaller frame size (e.g. 512) to gain better resolution, but you risk dropping frames if the COM can't keep up with the amount of commands you are sending in a single frame (I don't recommend messing with it!).
Since we are ducumenting these settings, I might as well touch on "frame offset" as well. The "frame offset" setting compensates for "protocol lag" (the amount of time it takes to send all of the bytes out the COM port). To compensate, the data being sent out is this number of frames ahead of where we actually are at. The default of "2" should be fine for most users. If the lights in the yard seem to come on sooner than in your visualiation, then a lower value can be used. If they seem to come on later then a higher value can be used.
If you are using speakers instead of an FM transmitter, you can compensate for the speed of sound being slower than the speed of light with the frame offset setting as well. Just use one of the negative number settings to make the lights go on later than in the visualizer. Trial and error at the street is best to fine tune this, but if you want the math:
Frame Size / 88200 * Frame Offset * -1 = Delay (in seconds)
The speed of sound is about 1125 feet per second (it varies with atmospheric conditions). If your speakers are 100 feet from the listener, this results in a propagation delay of 100/1125 = 0.09 seconds (very noticable). With a frame size of 1280, this works out to about -6. Add a couple in for protrocol lag and a setting of about -4 will time align the speakers with the lights. ------------- http://www.aurorashow.com/">
|
Posted By: Pony_God
Date Posted: 12 Nov 2008 at 1:53pm
|
Do we really need to work with the speed of light to put christmas light up... Do we get time on Nasa's super computer too?
Hum... short shimmer, I'll see how that looks. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: Pony_God
Date Posted: 20 Nov 2008 at 6:30pm
|
Alright, so I'm back at 1.14 so that I can get short ramps on the controllers, but they still do not display.
Now, I'm still running Aurora 1.02.
I did some testing, and a ramp that is shorter than .15 seconds does not show up at all, anything longer seems to be fine.
So I tested 100% intencity commands, they work down to .03, then it seems as though the TRIACs can't keep up and the lights start to go really funny. By funny, I mean that they might not all turn on, and will most likely not be at 100%.
So, if I _should_ be able to do a ramp .05, what an I doing wrong?
I have all of the controllers set to auto rate, standard 1280 frame, Aurora 1.0.2, fw/ 1.14, and lets call it 100' of cat5. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 7:19am
|
Anyone know if the ramps should work better with Aurora 1.0.29? ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 21 Nov 2008 at 11:50am
|
The data stream for short ramps (all the way down to 0.0154) looks good coming out of Aurora 1.0.25+. The protocol supports the command and it is getting out the serial port. This may just be a hardware limitation.
Honestly, I find it difficult to find a perceptible difference between a 0.02 ramp and an "off" command in the first place. If you are using incandescents then it is going to take the bulb filaments more than 0.02 to cool down. LEDs can respond this fast, but can the eye really tell the difference between "off" and "ramp" at these speeds (we're talking 50 FPS here)?
I have never used a ramp less than 0.15 before, but I wouldn't find support on down to 0.07-ish unreasonable for ramps (I suspect such a ramp would make an LED mimic the cool down behavior of an incandescent but I have never tried it). Every other command should respond on down to 0.0154. ------------- http://www.aurorashow.com/">
|
Posted By: BigDPS
Date Posted: 21 Nov 2008 at 12:32pm
|
I have had the same problem. If I have a small ramp going from 100 to 0 intensity, it won't light up. However, if it's from 0 to 100 with the same length, it will light up no problem. ------------- http://www.aurorashow.com/"> 
|
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 12:47pm
|
Well, it's not that I want real fade to happen, per-say.
What I want is 'blink', so I have the Eve's following the beat, and so if the beet is BummmBummmBummm, I can just to FadeeFadeeFadee, rather than OnOffOnOffOnOff
4 timing marks vs 7 tming marks.
In places like mini-trees or arches, I can change the fades to intencities since the next 'beat'/'note' whatever is on the next section.
I'll see what 1.0.32 does tonight.
If I had something like a 'blink' tool that let me set intensity and percent of selected area to divide to the on/off, then that would do the same idea as well. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 21 Nov 2008 at 1:10pm
|
I just did some testing here. It appears that the hardware treats a ramp down less than 0.15 as "off" and a ramp up less that 0.15 as "on". Given the intended design it makes sense (I don't think D-Light ever thought of using the ramp as a blink). 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. ------------- http://www.aurorashow.com/">
|
Posted By: ChrisL1976
Date Posted: 21 Nov 2008 at 1:36pm
|
Is the 0.15 seconds Minimum for ramps with version 1.15 or 1.13? I wonder if this is going to be resolved in the new update that supposed to be coming out here shortly.
------------- Chris www.lightsonsixth.com |
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 1:42pm
I would guess translating the command that fast and short saves a lot of bandwidth...
hum.... well.... DANG! Foiled again!
I'll just have to go complain then... They're limiting my creativity!
grumblegrumble... Now I have to tweak the sequences! ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 21 Nov 2008 at 1:54pm
|
It doesn't affect bandwidth (the full command is sent by Aurora) but it does affect how the hardware processes it.
The ramp you describe has to proceed through 239 levels of intensity on the way down and there is a finite amount of time in which to do it. A 0.15 ramp must change intensity every 0.000628s (we're into microseconds now). That little PIC microcontroller can only go so fast! There are ways around this (like skipping levels), but I imagine it isn't worth the risk of over-complicating the firmware... quick fix is to just treat <0.15 as on or off depending on the direction of the ramp. From what I hear the LOR controllers produce a similar result under this circumstance. ------------- http://www.aurorashow.com/">
|
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 2:22pm
|
true, true, true....
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? ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: LightsOnLogan
Date Posted: 21 Nov 2008 at 3:55pm
|
PG,
I thought about doing this during our discussion earlier. This would involve swapping out the real event with a "phantom event" during the compilation steps. We already partially do something like this for the RGB tool mapping to legacy command sets.
The change would be in AuroraData3, which is code-locked for the season at the moment. Unless we have to fix something else in AD3 there will be no additional changes to it this season. This is simply risk mitigation: AD3 is classified as stable and we're very close to "live" time, so it has to be more than a 5% user feature before a code change is considered for this season. The UI is still subject to changes between now and 1.1, but AD3 is most likely final for this season. ------------- http://www.aurorashow.com/">
|
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 5:44pm
|
Hay, I compleately understand killing feature creap....
I'll just have to go back though and swap out all of the mini tres and arches for ONs first. Then I'll worry about the eves. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: ChrisL1976
Date Posted: 21 Nov 2008 at 6:07pm
 the thought of going back and changing all those short ramps to stepped full on.
------------- Chris www.lightsonsixth.com |
Posted By: ChrisL1976
Date Posted: 21 Nov 2008 at 6:15pm
|
New Feature Request: Find and Replace Function Find all ramps less than 0.15 and replace with......... Think we can have this by Monday?  ------------- Chris www.lightsonsixth.com |
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 8:07pm
|
How about at least a "you have X ramps that are to short." so that it's the least amount of impact? Possibly a tiny external thing like the export? I know it's not the best, but I'd much rather have a stable 1.1 out, then add more things to the next release that need to be tested. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: ChrisL1976
Date Posted: 21 Nov 2008 at 8:11pm
|
I was joking about the find and replace....... Keep things stable....... I'll just spend some time this weekend replacing ramps. ------------- Chris www.lightsonsixth.com |
Posted By: Pony_God
Date Posted: 21 Nov 2008 at 8:37pm
|
lawn chair
laptop
nice hot tottie....
some really "inovative" displays. :) ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|
Posted By: Comporder1
Date Posted: 29 Nov 2008 at 10:26pm
|
Michael,
I am wondering if some of the short ramp issues may be related to Aurora..... I was running some tests today on my arches. I had everything unplugged except my 4 ACx16 arch controllers, wired using the USB adaptor. I used Aurora (editor) to test parts of certain sequences and more often than not, my aches were OFF. I decided that it was too late to do anything about it, so I just let it run, as is for my first night live. So I set up the scheduler and started the show..... and much to my surprise, many of my leaps that would not even register before, now look half way decent! So.... Aurora = nothing..... Scheduler = LEAPS!! Explain that!
 Carey
|
Posted By: LightsOnLogan
Date Posted: 30 Nov 2008 at 11:06am
|
Comporder1,
There is presently an issue with running the visualizer at the same time as running the output to the lights in the current version which will cause what you describe. Don't run those two combined. You shouldn't see what you described when running the grid/lights pair (but it does happen with the visualizer/lights pair). Of course, Borealis doesn't have to worry about pairing at all so it does just as well (or slightly better) as grid/lights.
Long story short... the visualizer/lights pairing is the result of a Vista compatibility change. While Vista can run MSCOMM32, too many users were completely unable to install it on Vista due to "magic combinations" of UAC, elevation level, login credentials, sunspots, moon phase, and relative humidity. Because of this we ditched MSCOMM32 in favor of a different COM handler. The thread timing is different on the new handler than the old one, so some frames are dropping when the visualizer is running. We plan to fix this in 2009, but in the meantime avoid the visualizer/lights combo. ------------- http://www.aurorashow.com/">
|
Posted By: Comporder1
Date Posted: 30 Nov 2008 at 2:22pm
|
For the record..... I was using the Grid/lights combination on XP Home. I will say that my dedicated "Christmas Light" laptop is not the most snappy machine (Celeron M 1.3Mhz/1.25GB RAM), but it seems to handle Aurora fine. |
Posted By: LightsOnLogan
Date Posted: 30 Nov 2008 at 4:20pm
|
What zoom level were you at? Try zooming out so that the page count is less when "generating preview frames". It is possible that you were hitting the page file (disk rendering) instead of rendering in memory. ------------- http://www.aurorashow.com/">
|
Posted By: Comporder1
Date Posted: 01 Dec 2008 at 10:33am
| Will do. I will also watch my memory usage. If I remember correctly, I was zoomed out at about 30 sec or so showing in the window. |
Posted By: LightsOnLogan
Date Posted: 01 Dec 2008 at 12:25pm
|
30 seconds should be more than enough to not cause any problems. In your case (the exception and not the rule) this might be a thread timing on slower hardware issue... I'll look into it. Fortunately it doesn't affect Borealis so the real show isn't affected. This is one of the reasons we have kept Borealis extremely simple. ------------- http://www.aurorashow.com/">
|
Posted By: beavis
Date Posted: 09 Dec 2008 at 2:41pm
|
I think someone mentioned, maybe in another thread that they used a full on followed by a half intensity or whatever to simulate a quick fade. I tested with it a little, and it translates to the lights pretty well.
What if there were a tool similar to the waveform tool, where you select however many FPS, or maybe Frames per Cell, and then have Aurora do some sort of calculated gradients of ramped intensities. Say a short cell separated into 3 separate intensities of 100, 66 and 33. Or 5 of 100, 80, 60, 40, 20. At high speeds, it would probably look like a fade. And it would save the controller processor the work of calculating fades.
On it's face this would seem difficult, but when you look at the way the waveform tool already works, I'd think it could be tweaked pretty easily to allow something like this.
Of course I'm sure it's easier said than done.
|
Posted By: LightsOnLogan
Date Posted: 09 Dec 2008 at 6:14pm
|
It can be done, but it greatly increases the amount of bandwidth being used on the network. The fact that the controllers can "coprocess" the ramps is actually an advantage of the protocol that makes it better than DMX for our particular application. A single ramp command with a 9-11 byte structure (depending on options) would have to be replaced with Nx6 bytes (where N is the number of frames to complete the ramp). W2E is typically used on a limited number of channels where this isn't a huge concern, but it isn't intended to scale into a general purpose tool either. Imagine simultaneous ramps in a 500 channel display (not impossible) and you will see that one method scales much better than the other. Then there is also the part about increasing the minimum processor and memory requirements for Aurora... something we do not want to do.
That said, there are some developments in the works for 2009 which might render this discussion obsolete. ------------- http://www.aurorashow.com/">
|
Posted By: beavis
Date Posted: 09 Dec 2008 at 10:15pm
|
Yeah, but then again if you think of the only alternative being adding new super-short timing marks just to allow a quick off before another on, I'd think having a stepped dimming might make sense.. I don't think you'd need to have nearly as many frames available as the waveform.
It's really only a problem with short fades, so I'd think anything more than 3 or 4 steps would be overkill anyway. The normal fades would still be preferred for anything longer. For me, like someone else mentioned, I use the short fades mostly for repetitive beats on the same channel.
I wouldn't think - On (100) On (66) On (33) On (100) - would cost that much more than just - On (100) Off On (100) -
And the other thing is, there's nothing preventing us from doing this manually already, we just have to muddy the water with more timing marks, and it's more work.
I have to say I'm really impressed with the software overall though. Other than some fade issues, it has been rock solid compared to spectrum. The only problems I've really had is fading that I imported from Spectrum not looking exactly the same as it did.
But with Spectrum, I literally had to sequence with 16 strands of Christmas lights hooked up to a controller in my basement to figure out how it would look. The visualizer was pretty much unusable. Totally not the case with Aurora. The only problems I've seen is that the controllers have a hard time keeping up. I guess when you figure out their limits, it gets better.
|
Posted By: Pony_God
Date Posted: 10 Dec 2008 at 8:35am
|
You also need to consider the time that incandecent lists need to cool off and the percieved fade.
We talked about this on page two. http://www.lightsonlogan.com/forum/forum_posts.asp?TID=480&KW=blink&PN=2 - http://www.lightsonlogan.com/forum/forum_posts.asp?TID=480&KW=blink&PN=2
Something that short will never be able to precieved as a pretty/smooth fade, so there are ways around it. One way would to be to understand that ramps to not function faster than .15 seconds, so Aurora could see those commands as a half on/half off command. Or something equivelent. ------------- Fine. You're so smart you rig up the lights. http://www.frappr.com/dlight - D-Light users Unite!
|