Module to connect/disconnect rack cables over midi

@stoermelder is there any limitation on how big the json can be? (generally on how many connections you can have?)

Actually its very minor problem…if its more than 15 minutes you should not spend time on this… anyway, as you said these plugins will be used by very few people who will know how to use…

I just note it, in case someone scratching his head to understand why his mapping doesnt work.

I think, this update will make the cabling even better than doing that on screen. :slight_smile:

you can add one more key-value pair on every output, like:

{
      "type": "cable",
      "midiChannel": 16,
      "midiCc": 2,
      "midiCcTriggerValue": 127,
      "moduleId": 9,
      "portType": "output",
      "connectionType": "red",
      "comments": "blue: clocks/gates/trigger, green: modulation, yellow: v/oct, red: audio",
      "portId": 0
}

@mudjakub

You are afraid without reason…json is the simplest thing on earth if you spend some time understand the syntax. Paste the “example” of T7-code to notepad++ and just read it… then, replace the CC and moduleID and ports numbers with the one you want. (to find these info, click a module and watch T7-assistant). The only purpose of T7-assistant is to help you edit the json file according to your modules.

So, what you want is (if you used buttons), while you are pressing the buttons the cable is working, if you release them, you disconnect the cable. corrent?

question for @stoermelder doesnt it add a lot of cpu work if it is checking the connection always and not only during connection and disconnection?

isnt it already in the plugin? (there is a “midiCcTriggerValue”, isnt it the threshold?)

i think there will be a problem soon with this approach… lets say you put a cable and your controller understand this as a push button (for example you make an internal connection with the arduino) and send a midi message. Then you do the same to the other arduino (your second midi controller) and you make the connection. ok.

but if i understand correctly you have to be very careful when connect or disconnect cables because you must do them in pair: if you connect the one side, the T7-code will wait the other side, (will wait…how much time? there will be time out?) and vice-versa… you cannot have a cable connected in an output waiting…and then do another connection also, you cannot you stack cables. But i think with these limitations you can make this work:)

(its off topic so maybe we can talk with pm: what do you use to print the midilar layout on top of the aluminum? i’ve seen people use vinyl prints…but i dont know if there is a better way…)

Exact.

If it works for now with pushbuttons, and also knobs, I can do it same with cables, so it should work same with cables. Maybe we think different in hardware way no software. What I need in this moment is behavior I proposed to Ben. (In current state if I use cables - it means, I plug cable to one module, plug end of cable to another = everything is connect perfectly in VCV Rack, but if I want deactivate cable I have to unplug cable and plug again to deactivate it, why I asked for GATE, behavior. It should work fine after.

Yes, it will work fine as long you connect every cable completely. If you connect/disconnect only a single end of a cable and start with the next one, everything will get confused :upside_down_face:

An advanced topic: How about stackable cables? Can your hardware handle them? :wink:

boom…haha…

is any timeout waiting for the connection? or it can wait for ever?

again not so big limitation

@stoermelder what do you think about my previous comment?

I told you…quarantine gave me nice time to think… :slight_smile: proof of concept here (no stack cables available…but i guess you get the point)

from me: big congratulations Ben…you plugin works better than i could imagine before opening this topic :slight_smile:

1 Like

@stoermelder and @ligant thank you guys for your explanation, I got it, it’s so easy to edit json file. :+1::+1::+1:

2 Likes

@mudjakub :slight_smile: also google: json validator… it will help you a bit more…

1 Like

@ligant Can you rename this thread to something more suitable?

1 Like

@stoermelder it will take a lot of time to compile your modules into mac version? Because primary I am on mac.:upside_down_face:

I just want to add, that it will be better also for me (because i think @mudjakub asked the same), to have the connection enabled only with:

“midi cc 2 value 127, midi cc 3 value 127”

and disconnect only with:

“midi cc 2 value 0, midi cc 3 value 0”

because if you open rack with cable already connected and you unplug it, the T7 connect it, vice versa: if you have it on your preset on rack, and not on the midi controller, when you connect it in midi controller, you disconnect it on rack… so it better to have only one midi message for connection and only one for disconnection.

what do you think?

Finally, will you release it in the Rack Library and generally in github?

maybe ill do i pull request in the future :stuck_out_tongue:

I haven’t read this thread, but I assume a plugin messing with RackWidget's CableWidgets and Engine's Cables.

Are you going to handle my bug reports when people report that Rack crashes when using undo/redo after your plugin has modified the cables?

1 Like

the question is for me or @stoermelder ?

Other DAWS are doing similar things … Didn’t read the thread but the first. Reason has a something called remote codec. where you configure a controller (hardware) which interface item it is mapped to, when the DAW as the focus set to it. So this means RACK would need to be able to track focus of a selected module and based on this select the propper mapping which then sends the according message…

The current way it is implemented in RACK is as much useless as it is in Reason. For 2 specific purposes.

Reason allows mapping from midi messages from controllers to devices, but it doesn’t allow to save it as a generic mapping, that can be used in every template/song.

Rack doesn’t allow mapping at all based on selected context, which makes it impossible to control different modules with one controller with a limited set of actuators like knobs, faders and so on. The other think RACK is missing for being useful for remote controlling would be direct 1:1 controlling everything at the same time without midi to directly adress every single thing in one rack. Something like naming conventions would have to be created, and something like OSC or other RPC mechanisms to be established.

I think I wrote a suggestion about that somewhere else.

If @Vortico is open for this kind of this I could elaborate more on this and even offer to work on it.

If you’re asking about adding a feature to Rack, please read https://vcvrack.com/manual/Issues.

First of all, I’m not going to release this one to the VCV Library.
Second, I checked how Rack adds and removes CableWidgets and I’m doing it the same way. I know it is not stable and might change on any update which could lead to crashes in the future. Would you consider a feature request for a stable API on cable-handling?
At last, I absolutely don’t want more bug reports on your side. If you are worried about that I will continue this discussion privately and won’t release anything publicly.

2 Likes

I’ve read it all and enjoyed seeing how this idea came to life, Ben, :raised_hands:t4::raised_hands:t4:

Open source it’s one of the beautiful things humans can do.

1 Like

Are the T7 modules available anywhere yet? Missed this whole thread somehow and now my brain’s on fire after catching up (thanks to @mudjakub’s knots video for sending me down a rabbit hole that eventually dropped me here)

Answered my own question… found packtau :+1:t3:

This is quite truly fabulous… all working! Now to build a l’il 4in 4out control surface to experiment with.

I’m just gonna leave this here for anyone skimming the thread and wondering why they can’t get things to work (spent HOURS yesterday getting nowhere due to this):

2 Likes

Well, pleased to say it all works - got 14x stackable outputs and 14x stackable inputs from a single Pi Pico with no additional hardware required… (well, apart from mono sockets and patch cables).

1 Like