Beginning channel range support

[dmeltzer]

This is early work on how we might generate a "gradiant" across a range
of channels. It still needs quite a bit of work.

This PR is more of a review request/feedback on the direction I've taken. It's been a while since I've worked with Qt, and that was before QML existed, so I'm sure I'm not doing things the most efficient way :)

This is based on the suggestions in #3. I had to modify triggergenerator::checkForTrigger() to do all the range calculations, I'm not sure if this should be extracted somewhere else or not, and I need to look at how to reduce the calculations there as much as possible.

I'm going to keep working away at this to at least make it functional, but if I should be going about this in another direction I'll be happy to do that as well!

Thanks in advance,

TODO:

• Save/restore settings.
• More dynamic updating of levels--My current math seems to pick a value for each range and it sticks there.
• Allow custom start/stop levels.
• Optimize triggergenerator code.
• Debug.

[dmeltzer]

It's getting closer. It gets really laggy when trying to use more than one range at once, I think it's just a lot of generating of messages...

One thing that I added this morning was sending 0's for values that are not matched in the trigger each time checkForTrigger() runs. This (obviously) generates a lot more messages. Is there any way currently for osc to generate a "bump" message for a channel rather than setting a manual value? Would seem to be something the console could handle better... although I guess the question would be how long the bump lasted for..

[dmeltzer]

One potential processing improvement (and this would have to happen on the console side (and maybe the OSC spec?) as well, so I'm not holding my breath :) would be to add to the OSC support for passing an array, something like /eos/user/1/channelRange/{"1"=>50, "2"=>65, "3"=> 43, "8"=>67} or similar, using qjson to serialize and deserialize the values. This would allow sending one string for each update, rather than one string for each channel in each update.

[HendrikNoeller]

Hello Daniel,

have you looked into sending command line information (look into the bpm detectors osc messages, you need the "user/0/" part)? This could potentially save som bandwidth.

Am 03.10.2016 um 14:05 schrieb Daniel Meltzer [email protected]:

One potential processing improvement (and this would have to happen on the console side (and maybe the OSC spec?) as well, so I'm not holding my breath :) would be to add to the OSC support for passing an array, something like /eos/user/1/channelRange/{"1"=>50, "2"=>65, "3"=> 43, "8"=>67} or similar, using qjson to serialize and deserialize the values. This would allow sending one string for each update, rather than one string for each channel in each update.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[dmeltzer]

I don't know that sending command line information would save much, because each channel has its own value, so each one would need to be it's own command.

[dmeltzer]

Thanks for the suggestions on sending commands. On EOS at least I'm able to send a command like "Chan 1 thru 5 at 01 thru 65" and have the console do the fanning for us. I'm not sure if congo/colorsource offer the same functionality?

Still working on this feature, it currently is having some issues with multiple concurrent triggers for some reason, and doesn't restore properly after a restart of the application. It's getting closer though (I think). I'll test this with some LED's tomorrow and see how it behaves.