I would like to send multiple outputs to inputs using the same name for send~ and receive~ but when I have multiple send/receive with the same name pure data give me warning and it won't send my audio. is there any work around?

use throw~ and catch~ instead

Related: Does anyone know the design reason for these limitations?

• Multiple [throw~ a] but only one [catch~ a] is allowed (one and only one summing bus target.)
  • And you can set the throw~ name dynamically but catch~ is frozen forever.
• Only one [send~ b] but multiple [receive~ b].
  • And you can set the receive~ name dynamically but send~ is frozen forever.

What if I need to use the same sum-bus signal in multiple places? Sure, you can catch~ --> send~ but why the extra object?

And what if you would like the user to be able to choose the routing at runtime? The lack of "set" messages for catch~ and send~ is a real bother here. I'm currently depending on dynamic patching magic from spacechild1 to get around this (adding a dependency on iemguts, and getting tons of errors when loading some patches, and devs were rather resistant to my use case).

I would have to guess that Miller Puckette is trying to prevent some impossible case by imposing these limits, but I'm not insightful enough to see what those impossible cases are. Absent that, it looks like a case where Pd is just stubbornly getting in the user's way.

hjh

@ddw_music I'm unsure why they are different pairs of classes, but I don't see what couldn't be done with the [catch~] -> [send~] method that would need dynamic patching..

if you want a specific [send~] to send to specific [receive~]s, just set it from the [receive~] side.

similarly, if you want a specific [catch~] to get stuff from specific [throw~]s, set it from the [throw~]s

Maybe it's due to implementation reasons?

edit: also see this recent relevant thread on the pd-dev list: https://lists.puredata.info/pipermail/pd-dev/2023-01/023195.html
it seems like the reason is to avoid a block delay?
anyways the ext13 library has settable [send13~] and [catch13~] objects too, that might be easier than iemguts and dynamic patching.. though you have to turn dsp off and on again (but if you're dynamic patching signal objects that's the case anyways I think)

@seb-harmonik.ar "it seems like the reason is to avoid a block delay?"

I really wish he had elaborated on that.

In SuperCollider, I have an example where the InFeedback UGen produces inconsistent results depending on the evaluation order: https://scsynth.org/t/supernova-groups-threads-ndef/1915/4

This might be what MSP is thinking of: the choice is either to impose a consistent block delay (breaking backward compatibility) or to risk inconsistent behavior depending on scheduler ordering of audio objects.

What he doesn't explain is why name changes have anything to do with this.

I guess I will have to join the mailing list and ask for clarification... didn't really want to do that because I don't need every thread coming into my inbox, but that seems to be where this is being discussed.

My use case is a modular mixing framework.

You create [fader~ myCoolSynth] (using the default target name "main"). Now there are:

• [catch~ myCoolSynth-auxL] and [catch~ myCoolSynth-auxR]
• [throw~ main-auxL] and [throw~ main-auxR]
• [send~ myCoolSynth-preL] and [send~ myCoolSynth-preR] (pre-fader sends)
• [send~ myCoolSynth-postL] and [send~ myCoolSynth-postR] (post-fader sends)

Now you change your mind and you want to call the channel "lead." So you go to the name symbol box (because, in a DAW mixer, you can change the name of the channel by [double-]clicking and typing), type "lead" <ret> and the catch and send objects need to change name... but this is not supported in vanilla.

spacechild1 had suggested dynamic patching for this, and was generous enough to make dcatch~ and dsend~ abstractions for me... ext13 may be fine as well, although the mailing list thread points out that it's 10 years old without recent updates.

(but if you're dynamic patching signal objects that's the case anyways I think)

I found in practice with my mixer objects that sometimes it's necessary to reset DSP, but not always.

hjh

@ddw_music I guess I would say that might be a use of an argument to specify a name, but I can see now why you might want it dynamically settable via symbol box or something.

I meant: if you restructure the dsp graph, I think the audio graph will stop and start whether you do it manually or not, while it gets recomputed. And I think that applies to changing send/receive/throw/catch names.

Slightly OT: the reality of the situation is that Pd is not as ideal as supercollider for live-coding, since so much stuff happens on the audio thread (namely memory allocation for classes/objects and audio graph recomputation)

I think you could still get around dynamic patching if you used a bunch of global state to lookup static abstraction names/templates but that may not be ideal, and may still need iemguts for [closebang] to unregister.
because ironically [receive] can't be set..

@seb-harmonik.ar said:

@ddw_music I guess I would say that might be a use of an argument to specify a name, but I can see now why you might want it dynamically settable via symbol box or something.

There's one reason why the name can't be set only by an argument. Step 1/ Create the object with one name. 2/ Set the gain by GUI. 3/ Edit the object text to change the name by argument... now the gain reverts to the initial level and your carefully arranged mix is destroyed. (I tested this in a simplified case.)

I meant: if you restructure the dsp graph, I think the audio graph will stop and start whether you do it manually or not, while it gets recomputed. And I think that applies to changing send/receive/throw/catch names.

I don't object to this. I'd think it's a good solution.

Slightly OT: the reality of the situation is that Pd is not as ideal as supercollider for live-coding, since so much stuff happens on the audio thread...

Right, and the video is a bit misleading in suggesting that live patching is the goal. What I'm really after is improved usability. For instance, in my class demos I often use ezoutput~ but it resets to -inf gain when you load the patch, so I'm constantly guessing what volume level in a student's homework will not destroy my ears. My fader~ uses savestate, so, you put mixers in the top level patch, and saving the patch also saves your mix. Also you should see the truly insane things students come up with when they're trying to patch effects in... but I'm providing a structure that is conceptually the same as send/return buses. Students often get this wrong too, but it's really nice to have that send trim control just right there, following a time-tested design... once you understand how to implement that design with these objects, then you don't waste time considering bad signal flow designs.

Why shouldn't we have nice things in Pd? It may not be MSP's priority but I tend to think that usability matters.

I think you could still get around dynamic patching if you used a bunch of global state to lookup static abstraction names/templates...

I'm not sure what that would look like. In any case, the dynamic patching works pretty well, apart from spurious error messages while savestate is updating the objects. (I complained about that but was told pretty clearly that even a momentary improper state shouldn't be tolerated under any circumstances, even if you know what you're doing and your patch will fix it automatically.)

hjh