With a new harddrive I'm presently considering playing with the idea of a dual Ubuntu / KX Studio for work / playwork. I primarily work with pure data and supercollider, may optionally look at other repos KX Studio has in hand.

However, my primary concern is if there are known advantages of making a slightly more complicated setup, cast against any potential install / compiling issues?

I found very little difference between the two. However, I realized that tuples from a list format would be more efficient across the board for handling values.

However, I discovered the biggest difference was in improving midi latency via jack settings. My computer wasn't pleased, but it did confirm the issue resides in midi latency. Probably should be glaringly obvious.

At this point I'll say midi latency is the biggest bottleneck in this instance - which leaves the freedom for whatever makes the most readable and bug free patch.

Ah, awesome. I played with matrix a while back as my unit to transfer data from file to pure data.

Upon loading of a song, it pulls up all the potential states / programs into a txt. Firing a state or program load event selects the correct matrix. Then arrives at the example above.

Matrix was my method to store the cc-value pairs, and unload them via the [row( command. I was thinking of matrix in terms of storing a multidimensional array.

After loading a state or program, the initial information is rounded up into a array to act as a buffer for storing all changes I make. That array is pulled to save the next state. So either in live performance or composition, I load a program and or state, goof around, save a state - and pull up that reference at any time.

I'll make a bench mark for the method you've shown above and see the results. Thank you.

I'm currently working on a program bank / state saving system for my external synths to exceed their memory capacity, and to create an easy approach to performance using the limited gear I possess.

The gist is that I use an APC 40, and have pure data switch LED lights referencing either a patch or state.

Each program references a loaded sysex message which creates the base sound. Between songs, or when inaudible. A state is a list of any values safely transmitted as CC data without interrupting the external's sound (pauses, etc). These switches happen while sound is transmitted

Signal flow example:

iemmatrix - first two relate to x-y coordinates of LED, followed by 42-2 as CC-Value Pairs
4 1 matrix 42 2 5 0 6 0 7 127 10 64 12 20 13 82 14 4 15 0 18 1 19 64
20 127 21 115 22 0 23 0 24 0 25 0 26 88 27 127 28 70 29 64 30 64 31
64 59 0 70 74 71 29 72 84 74 70 73 4 75 0 76 47 77 54 78 64 79 120
82 127 83 43 85 85 87 0 88 85 89 0 92 0 93 0 94 0```

[row(
|
[matrix]
|
[route 5 74 72, etc]
|               |           
[ctlout 5]    [ctlout 74]  [etc]

This solution works, even though it looks slightly silly in the route object extending out for however many CCs.

I was more concerned with efficiency than something conveniently dynamic. There is a slight "catching up" effect, whether it's from the external synth or the current rate of transfer I'm not completely sure. Without a method to test this(?), it's all in the ears. However I'm interested in eliminating all potential bottlenecks outside of the actual transfer rate from my usb midi - to external synth.

If anyone has a recommended potential alternative, which may be more efficient I'd be grateful. Or some foresight to say "it can't get more efficient, it's midi. Have a cookie" Thanks.

Thank you all for your responses. I've been away from this specific challenge as it's been stable "as-is," and my preemptive goal is to finish my performance suite and teaching myself the in/out of pure data itself.

In the future I plan on trying all these options in step and document the path to hopefully a fix. I have some experience in instructional writing and documentation so I hope to also write up whatever path leads to a solution for potential help of others.

@NoDSP

Sorry, I'll see if I can clarify a little further.

My motu handles most of the channel routing, etc. Nothing complicated. It's one of the older models without USB, so the Laptop <-> UM one <-> Motu <-> Ms2000

This is consistent across PD .47 and .48

I have not tried realtime kernel yet.

I had some time to do a couple more tests. Removing the Motu from the chain, and monitoring with kmidimon and no other applications running, including qjack.

The returned result induces zeros in the same location. Now for a quick gotcha: I have another ms2000, same result.

So it's not the ms2000(s), or the motu. This leaves the UM-One, or my computer configuration.

I can resurrect a windows zombie to do a basic midi monitor there, but it won't completely rule out the UM-One.

I'd be happy to learn more about midi tweaks, as it seems my primary use of pure data is to develop a midi ecosystem more than sounds and synthesis.

Thanks for checking in

I'm trying to create a MIDI environment for my MS2000 to extend its warranty of "fun."

However, I've noticed in the midi dump for a single patch random 0's. They always arrive in the same location UNLESS I switch between generic or low latency kernels on Ubuntu.

I've not tried realtime at this moment. I've tried taking the received data and transmitting it back without any alterations, received a data error from the MS2000.

I'm extending this research outward in case someone happens to have experienced this as a puredata / maybe qjackctl / audio domain.

Connection comes through a Motu Timepiece
Roland Um One

Have not been able to find a related scenario in any of my searches. I don't like fully relying on my workaround which assumes the faulty zero's will just "stay put."

Any insights or pointers appreciated!