Hi,

I got a MS20 controller and I have finally come around to try to make it work with Pd. For starter I would like to create a patch where the 34 jack patchbay and the knobs work as with the original software. The patchbay generates midi cc triggered by the patch chords in a specific sequence.

Question 1: I would like to have something like a list or an array with two elements for each index slot. Then a search or compare function where I can find what is connected to what.

Question 2. Creating the matrix for routing signals in the upcoming synth... I guess there are good and less good ways to go about it? Any suggestions is appreciated!

@cfry The s and r can be reversed if you want. The [obj 10 $5 dynpb $1 $2 $3 $4( message is just creating an instance of dynpb with $1-4 as its arguments, the abstraction has two object boxes [$1 $2] and $3 $4] which on creation get expanded to that arguments, I just did it in the order I created the objects when I patched up the abstraction so all the dollar arguments would be the same between the message and the abstraction, you can change these as you feel fit as long as you make sure r <symbol> end up in the first object of the abstraction and s <symbol> end up in the second.

No problem with s~ and r~, just add them to the routes and pass the list from the [text] foreward so we can set the first and third items of the [list store] as well, something like this but without the error in the message like I did, setting the wrong index.

And you can add in throw~ and catch~ if they suit a task better.

@cfry [matrix~] will allow stacked connections, and with a fade time set you can avoid clicks without adding a [line~] to all of your [*~ ] objects...... argument3 set to 1 for the cyclone version....
It would also allow different levels to be sent to jacks stacked on an output, but that might get too complicated.

I think it should make the patch build easier, but @oid's logic would need to send different messages for connect/disconnect.
You would simply connect all your jacks to the inputs and outputs of [matrix~] and send it the messages.

I use it for a 64in x 64out mixer on stage and replacing it with multiple abstractions would have been a nightmare.
The cyclone version will dump all the settings on command, which could be useful, but @oid has really taken care of the storage already.
David.

@whale-av I looked at [matrix] but I couldn't figure out how to use all the eggs(!) and eyes(!) etc. I would assume you use the same principles in [matrix~] ( or [mtx_*~] ) Could one use [matrix~] with control values too or should one then use two parallell matrixes?

Do you mind giving me an example on how to set this up? Re-route some objects in control and signal domain from input to output?

Are @oid dynamic object solution combinable with this approach? I could try both anyway. Is either one less mean on the cpu? If possible I would like to put the code on a raspberry pi later on.

The controller can do a dump of the current physical patching and knob values but it is of course great to be able to save multiple presets.

thank you for your input this is so cool.

@oid said:

No problem with s~ and r~, just add them to the routes and pass the list from the [text] foreward so we can set the first and third items of the [list store] as well, something like this but without the error in the message like I did, setting the wrong index.

And you can add in throw~ and catch~ if they suit a task better.

Sorry but I can not figure out where to put this :/ The pd.pd abstraction looks slightly different. It looks like you have merged what was previously two paths with parallel [route] objects.

EDIT: I managed to set up some logic to make the controller ccs work with this setup. Seem promising!

@cfry Yes.....
I had forgotten that it is the cyclone [matrix~] that I use as it is simpler for the messages.
So if you can install it then try this....... example.pd
The messages are simply setting the level at which inputs and outputs are connected, but using 100 and 0 is effectively on and off.

If the cyclone version is not available for your os then let me know and I will try to work out the strange messages for the iemmatrix version and post an example for that.
David.

@cfry said:

Sorry but I can not figure out where to put this :/ The pd.pd abstraction looks slightly different. It looks like you have merged what was previously two paths with parallel [route] objects.

I just showed one of those parallel paths since they are identical other than where the [route]s go and the [set( messages, one side handles send and send~ and the other side handles receive and receive~ and send it to the appropriate [set( message so the correct elements of the list are edited. Here it is merged as a single path with the [obj( message tweaked to work with the new data flow.
pb1.pd

Edit: lots of mistakes fixed.

@oid thanks for the update. Its really cool but I got a lot of errors from Pd not finding a matching send/receive and that was sort of expected, but it also only works if you enable disable connections in a specific way. Try my version with the synth to see what I mean:

oid-pb1-synth.pd

I think Pd disables the r~/s~ if it accidentally becomes duplicates of the s~.
...why can not Pd have a single send and receive object that accepts both multiple sends and receives at the same time... but I am just guessing what the problem may be.

EDIT: Would it make sense to mix the dynamic patch approach with using cyclones matrix~ for signal domain and vanilla s/r for control domain?

@cfry Right, as I said in the post where I first posted the patch, I assumed sane connections, that a jack would have to be unplugged before something else could be plugged into it. The logic will work with y-cables and stackable cables but only the logic as things stand and that is only because I skipped error checking because of the assumption I made about sanity. I left some work for you to do. [throw~] and [catch~] don't complain as much as [s~] and [r~] do and are generally less annoying to work with. And there is maybe some external with none of the multiple defined issues, no clue.

This method and [marix~] can be mixed, just replace the symbol with what [matrix~] wants and rewire the s~ and r~ outets of the [sel]/[route] as needed.

@oid Allright, I will try to do some safety net to make sure connections are sane. That should do it. Thank you so much for your cool patch I will continue working on understanding it!