I'm tired of not having a proper mixer abstraction. (Interestingly, searching http://blazicek.net/list_of_pure_data_objects.html for "mix" turns up nothing related to a mixing framework...?)

I was considering a design something like this:

For sends, I'm inspired by VCV Rack expander modules: Rather than fold a limited number of sends into one bigger abstraction, the mixer abstraction would handle only the main signal chain, and you would add a separate abstraction for each send.

In my mental plan, I was also thinking to have a symbol box at the top so the user could change the name of the mixer interactively... but then discovered in the [throw~] help file that this won't work for the mixer's aux input, because [catch~] doesn't accept any messages (must be [catch~] because many mixers can sum onto one submix or master channel). The only way for it to have a changeable name is based on an abstraction argument...

... so, if you need to change the name, you would have to edit the object string, re-creating the abstraction...

... but then, if I set the level/pan sliders' "init" property to true, then I guess the level/pan settings would be overwritten when re-creating the abstraction. So the behavior would be counterintuitive from the user's perspective: change the name, lose the level. So then I would need a global repository of channel internal IDs and values (but there is no singleton object in Pd yet, so there is no good way to do this either). Storage would have to be global because the abstraction is getting rebuilt, losing all of its local state; thus storage must live outside the abstraction itself.

Same problem for the target of a send: You can't reroute programmatically.

Is there any way around this?

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