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.

@geraldbiggs tbh i have no experience with control messages and don't know what matrix is exactly doing. But i know that [array] is the most efficient in vanilla, followed by [list], slower is [text].

Also i don't know if this helps, but if your numbers are coming in tupels, this might work:

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 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.

@geraldbiggs Here is a way to get tupels from a list: ctl-data.pd