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

@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.

@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.