@Boran-Robert I use [matrix~] for a 64 x 64 live monitor mixing setup.
Just send messages into it for changes. In my setup OSC messages from wifi tablets are translated directly to messages for [matrix~] .
It was the simplest solution.
You will be better off if you can find [cyclone/matrix~] for your system on Deken.
I only built that dynamic patch to solve the vanilla problem while I waited for such updates.
David.

@Boran-Robert No. It is that way because the whole audio chain has to be built for the patch, and if it is broken and rebuilt it will produce a big bang as the dsp is turned off and on again.
It could be done with dynamic patching but the problem would remain.
You can make a matrix mixer using [cyclone/matrix~] which can soft fade inputs to outputs, or switch using [zexy/multiplex~] and [zexy/demultiplex~] but depending on exactly what you want to do with the zexy objects you might need to take down the audio to zero before you switch and then bring it back up.
Using those objects you do not break the audio chain.
The ext13 library has? / had settable [catch~] and [throw~] objects, but again, the name was not set until dsp was toggled on and off.

I made a few years ago a Plain Vanilla [matrix~] that is dynamically created at loadbang, but then of course has to be connected to its inlets and outlets, which can be done automatically..... matrix~.zip
...... but I think the cyclone library has been updated for 64-bit on most os's now.

David.

@Nicolas-Danet [vline~] schedules its operations. But it has a control rate inlet, so it can only schedudule at block boundaries. But once it has it's schedule it will add that to the program and can be starting and stopping many times within blocks. That is my understanding.
It could be tested to see whether its control rate message inlet will take (in msecs) small enough float values to make that happen.
See C04.control.to.signal.pd in the doc.
You will need then to calculate how many blocks you need to schedule for until the end of the last schedule matches a breakpoint so that you can safely send in a new control message at that point.
David.

@lacuna The whole patch is recompiled within Pd and I think that although the data flow model is fantastic it makes it harder to understand the workings.
The blocks (of audio) are read, or generated, and all of the stuff that the patch needs to do to the block is done all at once to every sample in the block, and then the block is sent onwards.
So if you put [x~ 2] >> [/~ 2] then nothing is done..... the code that Pd is running has done the math and the result is "multiply sample values by one".......... so "do nothing". A complex patch will have been boiled down to "subtract x from sample1" "add y to sample2" etc...... up to sample 64, rinse, calculate the next set of additions and subtractions to apply, and do it to the next block.

Those operations..... add to sample value... or subtract from sample value.... are the only possible operations on a sample value.......
Interpolation uses adjacent sample values for the calculation, but adding or subtracting to / from the sample values is what happens when the calculations have been done.

Some objects like [x~] can be controlled by a control signal, and so the new value can only be applied at block boundaries as the control calculations are done between boundaries. The addition will be the same for every sample in the block. Pd didn't know in advance what it's next value might be, so a ramp cannot be applied across the samples in this block.
Some objects though, like [vline~] are scheduling changes of value that will happen across the block, and future blocks, and may finish at sample 43 within a block. Programmatically it is saying, as part of the whole patch "add a bit to sample 1 (if it has a +ve value or subtract if -ve)) and a bit more to sample 2 etc..... etc... and then for the next block, when the audio program runs again add even more to the 1st sample etc..... until.
So it is sample accurate.
And of course if [x~] is controlled by [vline~] it will do as it is told and be sample accurate too.
You can add a start delay to [vline~] so that it's start point is sample accurate too.

@Gustaw I have [dac~] running 32 channels regularly, but 64+ I have never tried.
I have come up against a 64 limit for IP addresses with MrPeach netsend objects as well, which surprised me.
Let us know how you get on with [dac~] 64+......
David.

@ddw_music With [abl_link~] you are syncing Pd to the other programs at the audio rate.... the audio "is" the time.
I don't see how you need to compare indexes. They have to be the same, or the same +/- any offset you want to apply.
If Pd is not originating time you only need to process messages received from [abl_link~] at each dsp tick. If Pd is originating time then you need to send the messages at least once into [abl_link~].
Only one of the linked programs is controlling the audio.
I imagine that the "resolution" setting determines that messages are sent every dsp tick.
But maybe it is the [abl_link~] object that generates the control data from the audio rate sync?
Looking at the C code that looks to be the case. It seems to be calculating in microseconds with double precision floats.
I guess from the [abl_link~] help patch (I have not read the Ableton doc) that you can receive the beat index and the phase at every dsp tick.
The phase will be 0-1 I imagine, so a control rate equivalent of the output you would get from a [phasor~] object in Pd running at the same tempo and starting on the beat.
The updates are at block boundaries, but you have also received the tempo, so you can calculate to sub-sample accuracy within Pd and schedule events across boundaries.

You can do a [text] lookup every tick, but it would be cheaper I think just to accept the data or not when it arrives........ some method such as using [==] as above to trigger events.
The events triggered by the bangs would run completely before the next tick, unless you have a delay programmed...... but a delay programmed is a delay that you want to apply.
You could distribute the values to the [==] objects from storage arrays to use "presets".

@EEight Cyrille again!..... brilliant as ever.
David.

@lacuna I haven't tried it, but thought it could be a starting point.
The help for the Pd object says that.......
"abl_link~ receives...... the current phase and beat time on each DSP tick....."
and as it's purpose is to keep all rewire programs in perfect sync that makes sense.
Pd can only execute control chains between dsp ticks, so everything that Pd needs to do with data from the object has to be executed (right down the chain) before the next tick starts..... so it should be accurate. All done after sample 64 and before sample no.65 . Of course if you try to do too much you could get dropouts.
Pd needs to run at the same samplerate and blocksize as the other programs of course, but you can go down to single samples in a subpatch if you need to.
Going sub sample can't be done. It is just a number at a time. If you want more accuracy you need to increase the sample rate, and if your sorce is not at that rate then you need to interpolate and will have more time accuracy but not sample accuracy.
I am hopeful it will get you what you are looking for.
David.

@ingox Agreed, but in this case, until they have handed over their project it has value, as it is not available for free.

@ingox Actually, I think everything I have written about passing on licenses is incorrect too as their client has them from their downloads, and all that they will copyright and license is the text files (patches) that they deliver to their client.
It is just an instruction set, like writing a macro for Microsoft Word.
The format belongs to Miller, and will be covered by the Pd license, which you must have to run the program, and which varies depending on the distribution that they use.
Maybe the Pd license for the distribution that they have used to create the patches should be included though.
But as you say, you have accessed the code of objects to create the patch...... so...
Then again, the text file could be written without Pd.
Does knowledge of an object, needed to write the text correctly, obligate the writer?
If I write letter.doc here do I have to upload the Microsoft office license to this forum?
Hmm.
No. But it obligates the reader if they use it.

On the monetary subject, yes for one client, but once it's "out there" you need real resources to protect your copyright.
Continued development can earn a revenue stream though.
A neighbour designs circuitry for mobile phone parts and stays in the game without patents...... through continuous development.
David.

@Gustaw 64.
It could be possible to combine multiple [writesf~] and so write multiple 64 channel files, and then combine them externally in a DAW or some other software. WAV format allows 65535 channels.
If you want to read your file back into Pd it looks as though [readsf~] can read 256 channels or more.
David.