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

@ddw_music Me too...... for a while.....
There is [cyclone/matrix~] which I see has now been updated for Deken for 64-bit.
I was so frustrated when it disappeared for a while in the 64-bit changeover that I made a dynamic vanilla version, but of course there was more fun involved to connect it up in the final patch as inlets and outlets could be of any number in the expandable mixer that I had built in 32-bit.
David.

@whale-av said:

@ddw_music Me too...... for a while.....
There is [cyclone/matrix~] which I see has now been updated for Deken for 64-bit.

Hm, yeah, matrix~ for the plumbing...

I was thinking of a modular mixing approach -- there are some VCV Rack mixers that don't unify into one big console, but rather, each channel is a standalone unit. I think most of the summing happens in chain in/out plugs...? Memory is vague here... But throw~ / catch~ would eliminate the need for chain cabling. For mid size projects I could imagine that this is easier to get started with, not sure about scalability.

Anyway I guess I'll open a feature request, maybe see if it's not too hard in the C sources.

hjh

FWIW, I had a look in the C source at the connection between throw~ and catch~, to see what is needed to change a catch~ name.

A throw~ object maintains a pointer to its catch~. There's only one pointer; this is why it's illegal to have multiple catch~ objects with the same name. When you "set" a throw~ object, it uses a function to locate the one catch~ with that name, and set the pointer to that object.

If you could set a catch~ object, because the pointer is held in the throw~ objects, it would have to iterate over every existing throw~ object for two conditions:

• If it matched the old name, set to the old name again (either clearing the connection, or finding another catch~ with that name, which shouldn't exist but might).
• If it matches the new name, set to the new name.

The internal C findbyclass function doesn't support "iterate over all objects of class 'x'" so it's not a direct transfer. I think it's fixable (thinking out loud here) but was a bit more than a trivial copy paste.

hjh

@ddw_music Just remembered @alexandros suggested an external [tabreceive_mult~]
He linked to it in this post.....
https://forum.pdpatchrepo.info/topic/12397/dynamic-send-and-receive-in-pure-data/5
Would need to be compiled from c though.
Davic.

I remember that those limitations with signal send/receive are not easy to explain during workshop with students. For users, all those technical rules (one only to many with send~ / receive~ , use another named object Throw~ / catch~ for many to one objects) are a bit clunky to learn, even it there is a technical reason behind.

Would be a great step to be able to simplify them

made by dynamic patching:

dynamic_catch~2.zip

It works, but gives some error messages, has to be slowed down for not messing with Pd's GUI, and keeps asking: "Do you want to discard changes?" ... Surely an external would be better off.

Edit: That pull request "add an inlet to [receive]" sounds related somehow : https://github.com/pure-data/pure-data/pull/604

Updated: Now it's cheaper, I moved more math inside the [switch~]ed subpatch:

Here is another solution using dynamic patching. [msend~] and [mreceive~] can send and receive to multiple sources or targets. Names can be set via creation argument or message.

msend~.zip

Thanks for these! [msend~] / [mreceive~] seem like they would Just Work.

I ended up logging a feature request (https://github.com/pure-data/pure-data/issues/1567) and there received another minimalist pair of abstractions (though they depend on iemguts).

It was also pointed out there that [tabsend~] / [tabreceive~] may be an easier vanilla way.

hjh

It was also pointed out there that [tabsend~] / [tabreceive~] may be an easier vanilla way.

Related to this: Is there a way to query the dsp engine for the currently active block size? To set the array size.

This is amusing but also a lot of extra work for the engine.

hjh

@ddw_music [iem_blocksize~] but only as dsp is turned on.
David.

@whale-av said:

@ddw_music [iem_blocksize~] but only as dsp is turned on.
David.

OK... trying to avoid external dependencies but if there's no other way...

AFAICS, with tabsend~ / tabreceive~, I'd have two choices: 1/ use iem_blocksize~ to size the array, because there's nothing to stop someone from putting one of the abstractions into a 'block~'ed subpatch, or 2/ allocate the array(s) to be large enough for any reasonably foreseeable block size -- this means wasted memory in the normal case, but memory is cheap these days. So I'll probably do #2.

hjh

@ddw_music A spanner in the works or a solution.....
You could separate the naming from the internal structure.
Busses could be added...... as modules..... and names for faders etc. could be changed in the GUI by messages..... but the busses/inputs/aux inputs/inserts etc. could simply be numbered and fixed bus1 bus2 etc.
Modules can be added, you just need to keep track of their index and their associated name using [text] or similar.
That is generally how software driven hardware mixers operate....... and how I dealt with problem in my dynamically created mixer (mess in screenshot top left).
Please excuse the messy patching.... it was my first ever and before I was rigorous with triggers.
David.

@ingox said:

[msend~] and [mreceive~]

yes!!!

@lacuna said:

dynamic patching:

but both introduce latency dyncatch~ 1 block, msend~ mreceive~ ~3blocks

http://www.pdpatchrepo.info/hurleur/latency-tester.pd

https://forum.pdpatchrepo.info/topic/7710/latency-on-output-and-input/2

@lacuna Here is a version that uses [inlet~]s and [outlet~]s so that between each [msend~] and [mreceive~] there is only one [throw~] and one [catch~] to hopefully reduce latency to the minimum. Hope that works.

msend~.zip

@lacuna Not sure if i use the latency-tester right, but it seems that the new version has 65 samples latency. I don't know if there is a way to improve this, since [throw~] and [catch~] do bring some latency with them as far as i know...

Here is the result with [throw~] and [catch~]. The results are the same.

So if this where true, [msend~] and [mreceive] would produce the same latency as [throw~] and [catch~] but with the ability to change sources and destinations freely.

Here another version with some improvements: [msend~]s now keep track of the [mreceive~]s so that they don't always have to be rebuilt.

Also there is now a click prevention in place. Output is muted when the name changes. I used [line~] with 2 milliseconds ramp time. On my computer this is enough to not hear any clicks. There is a hollow sound, but no clicks. Hope that works.

A patch to test audio is included.

msend~.zip

Edit: Small bugs fixed. Hopefully everything works now

Oh... block delay. Rats. Well, that's gonna tank this design, then.

That's a pity. In SC, I can arrange mixer channels in the order source --> target, and mixers incur no latency. In Pd, it looks like the only way to force order is using an explicit patch cable (which I was hoping to avoid).

Will have to table this idea until I can think of a better approach.

hjh

@ingox said:

latency-tester right,

it's not. here some fixes:

latency-tester2.pd

[throw~] and [catch~] do bring some latency with them as far as i know...

It depends on the execution order, described in 3. G05 of Pd documentation.

Patching like this has no latency for your 2nd and 3d version, as for dyncatch~ and throw~ chatch~ and s~ r~.

But there is other trouble with the 2nd and 3d version:
Deleting by 'dynamic-mouse-clicks' doesn't work if I use Pd's zoom-in, as I usaually do.
This is a bug of Pd: it messes up the coordinates.
Same happens if I undo after moving an object, it reappears somewhere else...

@ddw_music said:

In SC, I can arrange mixer channels in the order source --> target
[...] looks like the only way to force order is using an explicit patch cable

Not sure, but I belive only the order of objects is important, and even msend~ v1 could have 0 latency, if it would care about creation order!? Even across multiple patches? Creation order = execution order ?

Edit: yes and no: it's the creation order of the whole chain ...
in latency-tester2.pd:
[pd latency-meter] is the first object, [pd click] comes later,
... so deleting the patch-cord between [pd s] [pd r] brings back block-latency.

@ddw_music [catch~] created before [throw~]...... no block delay.
http://puredata.info/docs/manuals/pd/x2.htm Chapter 2.4.5
David.