Cable management (suggestion)

One of the first things I did was to edit the “settings.json” file to get eight colours.

Mine has this section:

  "cableColors": [
    "#f3374b",
    "#ffb437",
    "#00b56e",
    "#3695ef",
    "#8b4ade",
    "#454545",
    "#ff85ff",
    "#00e0ff"
  ],

Most of the time I use Omri’s colour scheme. I added purple for connecting to meters and scopes; dark grey for Resets; pink and aqua for miscellaneous and for alternate scope connections (because the scope traces match the cable colours), and to bring the number of colours up to eight. If I’m hooking up things with groups of eight or sixteen connections, such as “Merge” or “Shift Register”, then I just use the default auto-colour selection, hence the eight colours. It helps in keeping track of the order of things.

Oh, and here’s a handy-dandy colour picker - HTML Color Picker

I had considered using the same colour code as for resistors, since I already have that memorized, but brown & orange are hard to distinguished, and grey and white can be hard to see on a patch.

color is distraction from the goal :broccoli:

I know someone that can’t live without, but If I had to choose, I would load PALETTE and set only ONE color, it depends on the mood

in the real modular world I think lenght of the cable makes much more sense

1 Like

I use to do that as first thing too

I don’t know if you say this seriously but I m agree, I used to use grey and black cables , but since the vcv scope use the cable color to the representation I had to change all to white

https://g.co/kgs/7gd6zb

@alltiagocom the feature requested is great but what append if i would like to distort a wave with the mutable utilities, or use the slew limiter as filter, what is the output? the feature is only useful for some and it is an inconsistency in the feature to all of us

2 Likes

If we were to need autocolouring it should not be acording to output but to input. Where you connect the signal makes the function of the signal, not where it comes from.

3 Likes

I prefer think from “the source”

If you send a square LFO in a gate input, is it a LFO or a gate ? If you send an envelope into a wavefolder, then a delay, then a CV input for a cutoff, what is it ?

The only way to make sense of a patch is to understand what each signal is used for, so the input makes the function, not the output.

I like the idea of labelling cable colours, an yes it should be optional of course. I don’t use Omri’s colour scheme because I need the left and right channel / path to be different. Also aware that everything is voltage, so I use cyan for left, red for right, blue for clocks, triggers and gates, and yellow for everything else. I’m still learning and this is what works for me. I know I’m in trouble if I ever share a patch and need to recolour all the cables …

I think It’s just a question of taste

Cable auto-coloring → From input? From output? No? Set …in the settings

The only way way “from source” would work is if the cable changes colour automatically depending on what you plug it into. Which is why it makes no sense to make it “from source”.

You can run a clock directly to the audio output. Is the cable then “clock” or “audio”?

1 Like

I don’t think this is an appropriate way of speaking to people, and also, if you really want to keep it simple, why use modular ?

I understand your point of view

‘From source’ is just more simple to code for now

If community resolve the complex “tree-destination”,go on

Cordially

I think color coding is useful when you start with modular, as it may help you think about what you are doing, but pretty fast it loses its usefulness, because when you know what you want to do and how to do it then it’s a bit moot. The one thing super useful for me when revisiting a big complex patch is to have the cable opacity low, to highlight them one by one… Anyway, “Palette” is enough for me…

1 Like

“auto cable coloring” could just be the same as “syntax coloring” in coding