Cherry Audio Forums

MRBarton wrote: ↑Sun Jun 05, 2022 8:19 am Just wanted to chime in regarding the ideas for standardized cable coloring like on the Nord Modular. I've got a couple of Nord Modulars and the reason they can have a cable color scheme is that they differentiate between signals. There's audio, control, gates, and I forget if there's anything else.

Master / Slave oscillator link in the Nord Modular G1 ecosystem (Grey, if memory serves). I believe this was dropped for NM G2.

basa333 wrote: ↑Sun Jun 05, 2022 7:26 am
a) simply duplicate moduls (or selected group of moduls) with drag/drop (+ Ctrl?)

You can do that already. Click and drag to select the modules you want, then alt+drag.

MRBarton wrote: ↑Sun Jun 05, 2022 8:19 am So you can see that with this kind of universality, standardizing colors would be difficult if not impossible. Also, in developerland, a jack is a jack. You get the idea.

Given that there are three different connector types in VM that are impossible to interconnect this is clearly not true. But glossing over this for the sake of argument and pretending that there is only one class of connection it's still perfectly possible to have a color-coding standard in an environment where there is only one type of signal.

Color-coding is merely a visual aid - a convention intended to make patches easier to understand.

Yes, a particular signal might be considered as both/either audio and/or control in nature, but this doesn't affect the usefulness of using color coding in those situations where there is a clear intent. Indeed one could use a particular color to indicate an ambiguous cable.

I'm not saying that color-coding standards should be forced on anyone. It should always be possible as now to change the color of any cable. What I would like is just another option in addition to the current choice between setting a fixed default/starting color for cables as they are created and automatically selecting a random color. What I am suggesting is a third option where the default/starting color is based on the socket clicked on to create the cable.

It would require the addition of a single button labelled "Recommended" next to the current "Random" button on the color picker popup and a logical color attribute attached to each socket in a module. This attribute would default to a "no-recommendation" value but could be set to a logical color programmatically by developers calling a setRecommendedColor() method.

This would take very little coding effort to add to VM and not have any impact on anyone who didn't want to use the feature as they simply wouldn't ever select the Recommended button on the color picker.

In the example where a filter's output is fed to a gate input the initial color of the cable would depend on which end was connected first. But because one socket would have the recommendation for the gate color and the other socket would have the recommendation for the audio color it would be easy to automatically assign the "ambiguous" color to the cable. So it would be clear that this was a slightly odd connection.

Enhancements could be added to allow individual users to assign their own favourite colors to logical colors and also to show or hide cables of a particular color.

3 different types? I'm aware of mono and poly. Is there something I'm missing?

Hey, I would love standardized colors as much as anyone here, and the method you propose "setRecommendedColor()" seems to me the only solution. I'd modify that to "setSignalType()" to divorce it from a specific color, but it's the same thing. That very solution crossed my mind as well, but I think it's about 1,500 modules too late. Some devs may modify and republish their modules and some won't. Confusion will reign. I can't imagine being a noob and having to deal, and can you picture Nrgzr78 having to revisit every jack in all his modules? That's what I call job security.

Whatever the case, patches always resemble a plate of spaghetti (or is it linguini?), and trying to figure out what goes where is an adventure of clicking on jacks. Something that might mitigate the problem would be the ability to selectively display cords of a particular color instead of just global invisibility. A SHOW and HIDE button next to the RANDOM button in the color chooser is all it would take and that's something that's clearly possible without burdening all the devs. I believe I suggested this way over a year ago. Perhaps I'll give Dan a bump and see what he thinks. Whatever I suggest, he's always got a better way of doing it.

I realize that I'm suggesting a solution to a completely different problem, but I think it would help.

martb wrote: ↑Sun Jun 05, 2022 9:39 am

basa333 wrote: ↑Sun Jun 05, 2022 7:26 am
a) simply duplicate moduls (or selected group of moduls) with drag/drop (+ Ctrl?)

You can do that already. Click and drag to select the modules you want, then alt+drag.

thanks!!!

greets tom

MRBarton wrote: ↑Mon Jun 06, 2022 1:51 am 3 different types? I'm aware of mono and poly. Is there something I'm missing?

Dave Smith died on Tuesday so I would have thought that MIDI might be somewhere in your mind. Maybe you hadn't heard.

A method name of setSignalType() would be inaccurate as it's not about signal type as you have already argued. I thought of setRecommendedLogicalColor() but that's a mouthful. Also of course it would end up being Set...() rather than set...() as CA for some mysterious reason break Java naming convention and name their methods as if they were classes.

Why would confusion reign? As the default attribute would be "no-recommendation", legacy sockets would behave as they do today. It's just that gradually "smart" sockets would replace "dumb" ones.

Retrofitting wouldn't be difficult for most developers anyway. With VMD property support it would be a matter of loading up a module, selecting each socket and setting a property in a Property Pane menu, hitting Publish and then Submit. Even without VMD GUI support, typing in something like socketName.setRecommendedColor( VoltageLogicalColor.AUDIO ); for each socket would take maybe ten minutes per module for anyone who knows how to use cut and paste.

It might result in a lot of submissions for CA to process but if the submission comment says something like "Cable color update" they could be nodded through in no time.

Trying to understand patches with a hundred randomly colored cables isn't an adventure it's an avoidable chore. As things stand it's extremely laborious setting the cable colors. My suggestion would gradually remove this burden and take CA maybe one day to implement.

-----

Edited to apologise for the opening sentence in this post. Sorry Mark I see now that it sounds absolutely terrible. Please forgive me for an extremely clumsy use of words.

ColinP wrote: ↑Mon Jun 06, 2022 7:44 am

MRBarton wrote: ↑Mon Jun 06, 2022 1:51 am 3 different types? I'm aware of mono and poly. Is there something I'm missing?

Dave Smith died on Tuesday so I would have thought that MIDI might be somewhere in your mind. Maybe you hadn't heard.

A method name of setSignalType() would be inaccurate as it's not about signal type as you have already argued. I thought of setRecommendedLogicalColor() but that's a mouthful. Also of course it would end up being Set...() rather than set...() as CA for some mysterious reason break Java naming convention and name their methods as if they were classes.

Why would confusion reign? As the default attribute would be "no-recommendation", legacy sockets would behave as they do today. It's just that gradually "smart" sockets would replace "dumb" ones.

Retrofitting wouldn't be difficult for most developers anyway. With VMD property support it would be a matter of loading up a module, selecting each socket and setting a property in a Property Pane menu, hitting Publish and then Submit. Even without VMD GUI support, typing in something like socketName.setRecommendedColor( VoltageLogicalColor.AUDIO ); for each socket would take maybe ten minutes per module for anyone who knows how to use cut and paste.

It might result in a lot of submissions for CA to process but if the submission comment says something like "Cable color update" they could be nodded through in no time.

Trying to understand patches with a hundred randomly colored cables isn't an adventure it's an avoidable chore. As things stand it's extremely laborious setting the cable colors. My suggestion would gradually remove this burden and take CA maybe one day to implement.

I'm sorry but some of you should really take it down a notch. Referring to Dave Smith's death in this situation and pretending like forgetting a cable type is somehow suggesting mrb doesn't care about the death of Dave Smith is unnecessary at best and shows really bad character at worst.

Also the actual amount of work that goes into implementing things can only be seen by Cherry Audio, and saying that 'it would only take a day to implement' suggests you have a full view on all that goes into the Voltage Modular program. And even if you were right, they still would have to decide whether they want to, its worth it for most of VM consumers, their resources, and it doesn't bring confusion in the long run.

That being said. I'm still hoping someone from Cherry Audio would like to answer the original question i had. If there are updates planned in the future, and if there will be another 'year bundle' (MRB can also answer ofcourse). If there aren't any planned, a simple 'we have no updates planned at the moment' would also suffice.

woau wrote: ↑Mon Jun 06, 2022 9:08 am Referring to Dave Smith's death in this situation and pretending like forgetting a cable type is somehow suggesting mrb doesn't care about the death of Dave Smith is unnecessary at best and shows really bad character at worst.

That was not my intention at all.

I can now see that my choice of words might be interpreted as such and I profoundly apologise to Mark and everyone else.

I'm upset by the loss of Dave Smith and didn't mean to exploit it in any way.

I could argue about the software engineering aspects of your comments but I've embarrassed myself and will leave it.

If you believe I am a bad character so be it.

Reference to and details of prior suggestions removed.

It's fine. No offense taken. I understood what ColinP meant when he invoked Dave Smith. I did forget about the MIDI connector because I almost never use it and have never written a module that does. We're all pretty wrecked over Dave's passing and his contribution to the synth world can never be overstated.