Simplified color routing across sub-patches

[ceasless]

How I'd ideally like to see colors work in Usine (I quote "bus" here because I may be meaning something different than what Usine considers a bus):

Be able to create a color "bus" that can be easily selected through a new fader, but for color "buses". This fader would show the list of these "buses" that are currently wired in the patch (we could call these "active"). There would be another new module (like the color picker) where you could choose "buses" from 'rack', 'top-parent patch', 'parent patch', etc. The most important of these for me personally would be 'polyphonic voice' and 'top polyphonic voice'. These would be displayed in a 'triangle browser' view and would allow you to easily create colors that persist across an entire rack, patch together one simple interface for changing them, and then turn on polyphony and now have easy control of your colors across X voices. Interface elements within these voices could even be controlled by rack (or parent patch) level "buses" independently.

Since it is something like color, maybe it doesn't seem like such a big deal. But when I'm trying to keep everything looking how I want it it becomes a nuisance quickly and makes my patches very messy (and heavy!). As it is just color (which I doubt one would ever change during a live set without there being a technical reason for it like color blindness or a bad monitor), it feels to me like maybe there is a way to create a new "bus" that doesn't care about latency but is rather concerned with consistent routing for the color events that are (rarely) sent to modules.

Any thoughts?

[ceasless]

The other option would just be to allow polyphonic patches that use a bus to automatically create a bus for each voice and route to this voice bus. This would benefit more than just colors, but might be more complicated.

Is that perhaps already on the roadmap? Should I post this as a feature request in the bug tool?

[ceasless]

Any chances that colors will be easier to use in the next version? I really want to make some more patches but I don't want to do that if there is going to be a better solution soon.

[senso]

thanks for feedbacks
few comments
1)It's not recommended to multiply colors flow inside Usine. It can kill the process engine.
2)poly in Usine is very complex and create automatic buses capabilities seems to be very hard and will not give expected results if you considere the remark 1)
3) create color buses is a good idea

[ceasless]

Hey senso, thanks for the response!

I'm glad it makes some sense… The color buses do not need to be so complicated, or even really based on "buses" in the traditional sense. Some module that sets some value and gives it a name, and then another module to read the value based on name. I imagine this could be easily implemented in IML? I will take a look at writing a script after the next release.

When you say "multiply colors flow", do you mean it is not recommended to have all these color wires going into sub patches and such? I do believe that color management slows down my patches and the patching interface itself. But maybe you meant something else?

[senso]

yes color flows are are generally processed differently than audio flows and are much more cpu heavy. So be careful.

[woodslanding]

I'm confused--isn't a color just an integer as far as usine is concerned? Why should a color on a buss be more cpu heavy than an integer? Am I misunderstanding something here? Or are we just talking about a control changing color within a control itself? If that's the case then there shouldn't be any cpu overhead, except when a color actually changes, right?

And when you say 'multiply' I'm not sure what you mean..... just having colors on a buss, or multiplying RGB values to generate a color number?

I have a lot of controls that change color as a result of the user pressing a button, but they are static the rest of the time. Are they using cpu just because their color is attached to a buss? I like to color-code my FX sends, so I can see at a glance which effect is on a track.... It's just choosing one of four colors via a selector. One control changing color as a result of the user pressing a button.

This always worked fine in v5, but I do notice colors are often not updating in HH between busses in poly subpatches (if I can isolate it, I will file a bug report.) Still, I haven't noticed problems with cpu when they do update, maybe I'm just lucky?