| Main Hardware Software Cables/Adapters Forum Contact |
|
How short can ramps be? |
Post Reply 
|
Page <1234> |
| Author | |
Pony_God 
Senior Member 
Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
 Quote Reply
 Posted: 21 Nov 2008 at 8:37pm |
|
lawn chair
laptop
nice hot tottie....
some really "inovative" displays. :)
|
|
 |
|
|
ChrisL1976
Beta Testers 
Joined: 01 Sep 2008 Location: Kankakee, Ill Online Status: Offline Posts: 1341 |
Quote Reply
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 |
|
|
|
|
Pony_God
Senior Member
Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
Quote Reply
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.
|
|
|
|
|
ChrisL1976
Beta Testers
Joined: 01 Sep 2008 Location: Kankakee, Ill Online Status: Offline Posts: 1341 |
Quote Reply
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 |
|
|
|
|
ChrisL1976
Beta Testers
Joined: 01 Sep 2008 Location: Kankakee, Ill Online Status: Offline Posts: 1341 |
Quote Reply
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 |
|
|
|
|
Pony_God
Senior Member
Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
Quote Reply
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.
|
|
|
|
|
LightsOnLogan
Admin Group 
Joined: 11 Oct 2007 Online Status: Offline Posts: 3187 |
Quote Reply
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.
|
|
|
|
|
|
|
Pony_God
Senior Member
Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
Quote Reply
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?
|
|
|
|
|
LightsOnLogan
Admin Group
Joined: 11 Oct 2007 Online Status: Offline Posts: 3187 |
Quote Reply
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.
|
|
|
|
|
|
|
|
Pony_God
Senior Member
Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
Quote Reply
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! |
|
|
|
|
Post Reply
|
Page <1234> |
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
Topic Options