Aurora Homepage
Forum Home Forum Home > Aurora Sequencer Software > Aurora 1.0
  Active Topics Active Topics
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

How short can ramps be?

 Post Reply Post Reply Page  <1234>
Author
Message
  Topic Search Topic Search  Topic Options Topic Options
Pony_God View Drop Down
Senior Member
Senior Member
Avatar

Joined: 01 Sep 2008
Location: Naples, FL
Online Status: Offline
Posts: 551
  Quote Pony_God Quote  Post ReplyReply Direct Link To This Post 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.
D-Light users Unite!
Back to Top
LightsOnLogan View Drop Down
Admin Group
Admin Group


Joined: 11 Oct 2007
Online Status: Offline
Posts: 3187
  Quote LightsOnLogan Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
BigDPS View Drop Down
Beta Testers
Beta Testers
Avatar

Joined: 13 Dec 2007
Online Status: Offline
Posts: 471
  Quote BigDPS Quote  Post ReplyReply Direct Link To This Post 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.

Back to Top
Pony_God View Drop Down
Senior Member
Senior Member
Avatar

Joined: 01 Sep 2008
Location: Naples, FL
Online Status: Offline
Posts: 551
  Quote Pony_God Quote  Post ReplyReply Direct Link To This Post 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.
D-Light users Unite!
Back to Top
LightsOnLogan View Drop Down
Admin Group
Admin Group


Joined: 11 Oct 2007
Online Status: Offline
Posts: 3187
  Quote LightsOnLogan Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
ChrisL1976 View Drop Down
Beta Testers
Beta Testers


Joined: 01 Sep 2008
Location: Kankakee, Ill
Online Status: Offline
Posts: 1341
  Quote ChrisL1976 Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
Pony_God View Drop Down
Senior Member
Senior Member
Avatar

Joined: 01 Sep 2008
Location: Naples, FL
Online Status: Offline
Posts: 551
  Quote Pony_God Quote  Post ReplyReply Direct Link To This Post Posted: 21 Nov 2008 at 1:42pm
Originally posted by LightsOnLogan

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 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.
D-Light users Unite!
Back to Top
LightsOnLogan View Drop Down
Admin Group
Admin Group


Joined: 11 Oct 2007
Online Status: Offline
Posts: 3187
  Quote LightsOnLogan Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
Pony_God View Drop Down
Senior Member
Senior Member
Avatar

Joined: 01 Sep 2008
Location: Naples, FL
Online Status: Offline
Posts: 551
  Quote Pony_God Quote  Post ReplyReply Direct Link To This Post 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.
D-Light users Unite!
Back to Top
LightsOnLogan View Drop Down
Admin Group
Admin Group


Joined: 11 Oct 2007
Online Status: Offline
Posts: 3187
  Quote LightsOnLogan Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
 Post Reply Post Reply Page  <1234>

Forum Jump Forum Permissions View Drop Down

Bulletin Board Software by Web Wiz Forums® version 9.06
Copyright ©2001-2007 Web Wiz

This page was generated in 0.141 seconds.