How short can ramps be?

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

   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. 

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version
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: 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


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

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