How short can ramps be?

Message Topic Search Topic Options Post Reply Create New Topic Printable Version

   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
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.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version
Pony_God Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551	Quote Reply Topic: How short can ramps be? 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 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. D-Light users Unite!

beavis Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 01 Sep 2008 Online Status: Offline Posts: 15	Quote Reply 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. Edited by beavis - 09 Dec 2008 at 10:18pm

LightsOnLogan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 11 Oct 2007 Online Status: Offline Posts: 3187	Quote Reply 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.


beavis Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 01 Sep 2008 Online Status: Offline Posts: 15	Quote Reply 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. Edited by beavis - 09 Dec 2008 at 2:45pm

LightsOnLogan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 11 Oct 2007 Online Status: Offline Posts: 3187	Quote Reply 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. Edited by LightsOnLogan - 01 Dec 2008 at 12:26pm


Comporder1 Members Profile Send Private Message Find Members Posts Visit Members Homepage Add to Buddy List DMX Joined: 11 Dec 2007 Location: Brookhaven, MS Online Status: Offline Posts: 163	Quote Reply 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.

LightsOnLogan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 11 Oct 2007 Online Status: Offline Posts: 3187	Quote Reply 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.


Comporder1 Members Profile Send Private Message Find Members Posts Visit Members Homepage Add to Buddy List DMX Joined: 11 Dec 2007 Location: Brookhaven, MS Online Status: Offline Posts: 163	Quote Reply 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.

LightsOnLogan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 11 Oct 2007 Online Status: Offline Posts: 3187	Quote Reply 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.


Comporder1 Members Profile Send Private Message Find Members Posts Visit Members Homepage Add to Buddy List DMX Joined: 11 Dec 2007 Location: Brookhaven, MS Online Status: Offline Posts: 163	Quote Reply 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 Edited by Comporder1 - 29 Nov 2008 at 10:29pm