@whale-av Hey, c"mon, I went obsessively deep on this topic, remember? And you came along for at least part of the ride.
https://forum.pdpatchrepo.info/topic/13512/s-r-throw-catch-latency-and-object-creation-order
Actually, I don't blame anyone if they didn't follow, it was pretty mind-numbing.

You need [throw~] to run before [catch~], but simply creating [throw~] after [catch~} isn't enough. The head of its audio chain has to be created after. So here's an example where [throw~] was created after [catch~] but it still has a 1 block delay:
catch~throw~test.pd

#N canvas 761 75 604 489 12;
#X obj 89 58 phasor~ 1;
#X obj 108 189 catch~ something;
#X obj 90 227 -~;
#X obj 90 301 snapshot~;
#X floatatom 90 325 5 0 0 0 - - - 0;
#X obj 127 248 tgl 15 0 empty empty empty 17 7 0 10 #fcfcfc #000000
#000000 0 1;
#X obj 127 268 metro 100;
#X obj 89 82 *~ 44100;
#X obj 109 124 throw~ something;
#X connect 0 0 7 0;
#X connect 1 0 2 1;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 5 0 6 0;
#X connect 6 0 3 0;
#X connect 7 0 8 0;
#X connect 7 0 2 0;

Cut and repaste [phasor~ 1], connect it back to [*~ 44100] and the delay goes away.

If you look at audiotest.pd in @ingox's msend~.zip you can see that [osc~] was created last, therefore runs first, and therefore that interesting solution (that I need to study) shows no latency.

... if only the 'sorting algorithm' would take into account s~ r~ and such

@jameslo I remember your research into this

Now here is a version that uses a different approach. It has fixed [catch~] objects and creates [throw~] objects for each [catch~]. When the name changes, everything is just rewired. No objects are deleted, which should be more stable.

I hope that it is usable without latency and that every problem would be solved now.

msend~.zip

Amazing stuff here, especially @jameslo's other thread and @ingox's abstractions.

I can reproduce the no-block-delay and one-block-delay.

This will still be very easy for students to mess up. "Create the head of the chain last" -- I'd guess this is an uncommon working method. Perhaps cut/paste/rewire.

Still it seems a weak point, if DSP behavior depends on invisible factors.

hjh

Prototype:

hjh

@ingox -- I should also note that the algorithm which msend~ and mreceive~ use to track the connections appears to have an exponentially increasing execution time when a large number of them are created simultaneously.

The fader abstraction creates 2 mreceive~ (aux inputs) and 6 msend~ objects (pre-fader send, post-fader send, and output to the named target, all stereo pairs).

• A patch containing 1 fader (nothing else) takes < 1 second to open
• 3 faders: 4 sec
• 5 faders: 9 sec
• 8 faders: 25 sec

I'm not sure how much could be done about that though, short of implementing some of it in scripting objects.

hjh

@ddw_music This doesn't sound good. After posting the abstractions i did some more work to make them more efficient and updated the post. Is this still the case with the newest version?

@ingox said:

@ddw_music This doesn't sound good. After posting the abstractions i did some more work to make them more efficient and updated the post. Is this still the case with the newest version?

I thought I had downloaded the latest (I downloaded two versions and based my abstractions on the later of those two).

Spacechild1 had another approach that initializes very quickly. I'll probably use those (except that receive~ posts warnings -- trying to get the devs to understand the use case).

hjh

@ddw_music Yes, it is very unfortunate that my proposed solution is so inefficient. Can you send me the link to the approach of Spacechild1? I couldn't find it.

@ingox said:

@ddw_music Can you send me the link to the approach of Spacechild1?

dynamic-catch: https://github.com/pure-data/pure-data/issues/1567#issuecomment-1026971671

dynamic-send: https://github.com/pure-data/pure-data/issues/1567#issuecomment-1026990681

They use [iemguts] for dynamic patching.

hjh

Here is another version that doesn't has the problems when multiple names are changed: msend~.zip.

But since it creates a [send~] and a [receive~] it has again the one block delay.

The problem in the previous version was using [vis 1( and [vis 0( to disconnect the [throw~]s. But without them it gives TCL errors. So i don't see a way to achieve all goals at once.

Now here is a solution that allows sending audio to and from multiple sources and destinations, changing sources and destinations, without errors, without clicks and without delay.

msend~.zip

It uses [switch~] instead of dynamic patching. Only when new objects are created dynamic patching is used.

There are some test abstractions included in the zip.

Edit: It also slows down opening the patch when many [msend~]s/[mrecieve~]s are present (see test/many_name_changes.pd), but hopefully it is still reasonable. Around 6 seconds on my computer with 32 [msend~]s and 8 [mreceive~]s in the patch.

Now my probably final approach to the topic: This version has all the benefits of the previous, but also the patch opens quickly now.

msend~.zip

The patch uses [*~] instead of [switch~] now, so everything is straight forward, no delays in the patch and much cleaner code. I hope that now all problems are solved.

@ingox said:

Now my probably final approach to the topic: This version has all the benefits of the previous, but also the patch opens quickly now.

Cool! I can have a look at it later.

In my mixing abstractions, it's basically a simple substitution (and change some messages -- Spacechild's dcatch~ and dsend~ need "set xyz" while I recall msend~ / mreceive~ take "symbol xyz").

Incidentally, I finally decided about the block delay just to accept it and document it. The primary use case of a send is reverb, where an extra couple milliseconds of pre-delay isn't so bad.

I'm half thinking of proposing a feature request for "priority (float)" messages to DSP chains. That is, part of the reason for the [t] object is that a patch shouldn't depend on invisible information for ordering -- but, the DSP scheduler does handle delays and throw~/catch~ based on the order in which objects were created, and it's impossible to read in the patch, and quite obscure to control, and very easy to break accidentally. That's really unfortunate... but, in context of my mixing abstractions, I just decided that this is a design flaw in Pd and I'm not going to try to fix it. DSP chains would benefit from something like the way that [gemhead] uses float input. (SuperCollider has an edge here -- DSP order is completely under user control.)

hjh