Minimum hold duration for chasers

dmxWolf · Sat Feb 14, 2015 6:12 pm

I think the minimum hold duration for steps should be hard coded. Possibly to the mastertimer frequency, or say 30MS, to give the program time to figure out what's going on. Hold durations set to 0 with no fades behave erratically. 30MS would be equivalent to watching a video at 30fps, which I think would be acceptable.

FactorFilms · Sat Feb 14, 2015 9:48 pm

Not a fan of this. I like being able to create effectively strobe flashes with LEDs setting the hold time @ 100% to 1 or 2 ms

ie. in my recreation of Ryoji Ikeda's SPECTRA II installation!

[[embed url=http://www.youtube.com/watch?v=cV5O6lXcRME]]

dmxWolf · Sat Feb 14, 2015 11:13 pm

Your options are in tenths of seconds.. .5 being 1/2 second, or 500ms. The lowest you can set it is .1 seconds, or 100ms, which works fine. But if you leave the hold at 0, with no fadein or fadeout, it tries to chase as fast as your processor can calculate, which causes the chase to operate erratically, because the program can't seem to process things fast enough to keep up with the steps (or something like that). 30ms wouldn't even be noticeable to the human eye.

dmxWolf · Sat Feb 14, 2015 11:24 pm

Hmmmm... at 30ms you could actually make a video using scenes on a pixel screen, or whatever.

OddSocks · Sun Feb 15, 2015 8:06 am

Actually the timing is in 0.01s but there is a problem with the control / display.

The maximum refresh speed for a full DMX universe is 44hz or 22ms, so if a minimum is to be hard coded I would go for 20ms.

dmxWolf · Sun Feb 15, 2015 2:54 pm

Yes, above .1 it increments in .01s. If you use the speed dial to go below .1, you get .1 increments.... .1 .2 .3 -> .9. If you try to manually enter a a number below .1, say .03, it will default to tenths of a second .3. It is the actually value, not just a problem with it displaying 100th's wrong. You can see this by using the speed dial to try to go below .1.... spin it down to a fade in of .9 and run it. You can see that it fades for nearly a full second.

Above .1 you can do .01 increments, but not below. Maybe they did this on purpose to avoid timing issues, like happen if all values are 0. A default stable minimum hard coded would ensure that things run smoothly even if the user leaves all values set at 0.

OddSocks · Sun Feb 15, 2015 3:25 pm

Sorry you are wrong here. If you enter a value of .03 in the milliseconds it will run at 0.03s but will display .3s

If you then use the + or - button it will then go wrong and be using the displayed value (0.4s or 0.2s). This is a known problem and is caused by QT stripping the leading zeros.

dmxWolf · Sun Feb 15, 2015 5:24 pm

Nope. I just tried manually entering .09 and it displayed .9, then I ran the scene. It faded in at .9 seconds. .09 seconds would be noticeably faster. So even if it is QT stripping it, it's still being calculated at the stripped and displayed value.

OddSocks · Mon Feb 16, 2015 8:42 am

That's strange.

I have just created a quick project with two chasers, one with steps of 0.3s and one with 0.03s and very different speeds on the flash.

I have attached the file.

FactorFilms · Mon Feb 16, 2015 9:58 am

Ya. .3 is the same as .30, or roughly a third of a second, whereas .03 is stroboscopic.

dmxWolf · Mon Feb 16, 2015 12:14 pm

Hmmm... I only tried it with a scene fade and manually entering .09 defaults it to .9, which actually runs at .9.

Looking at your scene in function editor, it is actually displaying .03 in the hold and duration columns, with the leading 0 not stripped. In the speed dial window if I change fade in to per step and enter .03 fade in, it defaults to .3 and changes hold to .3. But shows .03 fade in, 0 hold, and .03 duration in the steps. Start changing fade in times and checking different default, per step, and common radio buttons and things start going wonky. At one point, changing the fade in speed changed hold to 1193h02m47s.02!

Jano Svitok · Mon Feb 16, 2015 12:34 pm

Guys,

if someone wants to fix this: [Here](https://github.com/mcallegari/qlcplus/b ... al.cpp#L61) is FocusSpinBox class derived from [QSpinBox](http://qt-project.org/doc/qt-4.8/qspinbox.html) (see also related header file). Your goal is to create new class MsFocusSpinBox that derives from FocusSpinBox and adds proper handling and formatting of the fractional part.

The step is defined [here](https://github.com/mcallegari/qlcplus/b ... al.cpp#L40).

The MS spinbox is initialized [here](https://github.com/mcallegari/qlcplus/b ... l.cpp#L159).

Read section called "Subclassing QSpinBox" in QSpinBox documentation how to implement the conversions. I suppose the format should be ".999" or ".99" or ".990" where the last digit would always be "0" (i.e. if the step stays at 10 ms). It would be great if value() is always provided in ms, regardless of the format used (return 990 also when format ".99" is used).

[Here](https://github.com/mcallegari/qlcplus/b ... l.cpp#L286) is some magic that tries to workaround limitations of current QSpinBox. If MsFocusSpinBox is correctly implemented, this magic may be replaced by simple

value += m_msec->value();

Check also other uses of m_msec if there's more of similar magic.

This is quite simple C++ task, so maybe someone wants to give it a try. Ask me if you need more guidance. I'm not going to fix this myself, since I'm busy with other ideas.

dmxWolf · Mon Feb 16, 2015 1:31 pm

I only took a brief look through this code, so maybe I'm missing something, but why are you not using the displayed value in the fraction of seconds box as an integer x1000 (i.e. .03x1000=30 ms) to get milliseconds and doing your calculations, then converting it back (30/1000=.03) to display it? Sorry if I'm just missing something somewhere.

dmxWolf · Mon Feb 16, 2015 1:48 pm

But anyway, if you are converting the fraction of a second to milliseconds right off, then you wouldn't need any magic to check if it's less than 0 and contains a zero and it would simplify everything