Choking individual triggers of a Copy device

[pdby]

Is your feature request related to a problem? Please describe.

No, not related to a problem.

Describe the solution you'd like

There would be an option or a tickbox inside Copy device where you can enable to choke the generated light effects but only affects the Copy device and not any other choke groups. Would be good to be an entry in settings to toggle this, or a checkbox in Copy devices.

Describe alternatives you've considered

I couldn't find any ways to do it.

Your setup

Latest windows 10, latest Apollo (at this time 1.8.4)

[mat1jaczyyy]

I don't understand this at all, what would this achieve that isn't doable with the Choke device already?

[pdby]

I don't understand this at all, what would this achieve that isn't doable with the Choke device already?

I mean if I use the current Choke device, it doesn't do the choking inside the Copy device. If I trigger a simple line movement, and then again with another button using Copy device, it clashes each other instead of restrarting the triggered effect. Send a video for better explaing?

[mat1jaczyyy]

Yeah sure, please send a video and project files with examples

[pdby]

Attached .zip file conatining a video and apollo project file. As well as updated the title and the description to "Copy device", because I wrote it wrong, sorry. So, if set a light effect triggered by the Copy device, (a line going up), I can't choke them, only if I put the same effects to different buttons, and use the current Choke device. But I'd like to do it in Copy device, without putting the same effects to different buttons.

copychoke.zip

[mat1jaczyyy]

I see what you're going for now. copychoke.zip The first Choke's purpose is to cancel whatever is running in the second Choke immediately before playing the 2nd Choke. You can move the Fade in or out of the 2nd Choke containing the Copy based on what all you want choked. I think this is the behavior you want?

[pdby]

Ah yes exactly. So it is doable fairly easily. This function could be implemented into move directly maybe?

[mat1jaczyyy]

It's easily doable this way, I don't see a reason why we should reimplement existing functionality

[pdby]

Thanks for showing this. Probably for simpler usage and maybe less devices decreasing the file size. (Don't know how much impact has this on filesize)

[mat1jaczyyy]

No problem! Implementing it would have little to no noticeable impact on file size, it's just reimplementing existing functionality which bloats the codebase. Closing.