[PD-dev] multichannel signals, preliminary support

[Christof Ressi]

Hi all,

I am a bit late to the party. I finally got around studying the new 
multichannel code changes and wading through this massive sea of e-mails 
to get up to date on the discussion :-)

First off, I am very excited about this new feature! Here are a few 
comments from my side. The e-mail is a bit long, but I tried to write as 
concisely as possible, so please keep reading :-)

---

There are few things in the API that I think could be streamlined a bit.

1) Currently, external authors have to explicitly create the output 
signals if they want the object to be multi-channel aware. For example, 
here's the relevant line in plus_dsp():

sp[2] = signal_new(nullsignal->s_length, outchans, nullsignal->s_sr, 0);

Now, most of this information is redundant. I cannot imagine a situation 
where you would provide a different vector size or samplerate. The only 
thing we are really interested in is the number of channels.

Instead of creating the signal, I would rather prefer the following:

signal_setchannels(sp[2], outchans);

IMO, this would be much more descriptive and also reduce the chance for 
mistakes.

---

2) "dsp" methods now have an additional "t_signal *nullsignal" parameter 
for cases where you cannot get the vector size otherwise (except by 
going through the owning canvas). Typical example: multi-channel objects 
with no signal inlets (because the output signals are yet to be created).

Actually, the introduction of signal_setchannels() - see above - would 
make this obsolete because you would't need to create signals in the 
first place! The only remaining use case for the "nullsignal" would be 
an object with no signal outlets and where all signal inlets are 
"scalars" (= float to signal promotion is turned off). This is quite an 
edge case, though, and I cannot think of an example in the Pd core...

On the other hand, I kind of like this extra parameter because it 
provides a /uniform /way to access shared DSP parameters. However, I 
would suggest to make a proper structure instead of reusingt_signal, e.g.:

typedef struct _dspinfo
{
     d_blocksize; /* number of items per channel */
     t_float d_sr;  /* samples per second per channel */
     int d_overlap;  /* overlap factor */
     int d_nin; /* number of signal inlets */
     int d_nout; /* number of signal outlets */
     /* ... anything else? */
} t_dspinfo;

Note that we can take the chance to pass some extra info that is not 
part of t_signal, such as the number of signal inlets and signal outlets.

---

3) IMO, class_setdspflags() should be used consequently in the codebase 
instead of passing the DSP flags to class_new(). It is not strictly 
necessary, but it would set a good example to external authors.

As Miller explained, the main reason for class_setdspflags() is that 
externals using these new feature would refuse to load in older Pd 
version; otherwise they would just crash.

---

4) Whenever an object requires you to set the number of channels 
explicitly, e.g. in [send~]/[receive~]/[throw~]/[catch~], there should 
be a way to change the number of channels with a message!

For example, if I have an ambisonics patch, I would like to be able to 
change the ambisonics order (and hence the channel count) on the fly.

This can be implemented easily, you just need to update the DSP graph 
after changing the number of channels.

---

5) Regarding the naming of [pack~]/[unpack~]: I don't have a strong 
opinion. On the one hand it corresponds nicely to what [pack] and 
[unpack] does, on the other hand it clashes with the zexy library...

[split~] and [join~] are not bad, but I think they would fit better to a 
different kind of object (see below).

I find [snake~] and [unsnake~] quite funny :-)

---

6) Regarding the [clone] discussion: I very like the idea of creating 
embedded abstractions or even accepting compiled objects! I often 
thought about this myself.

I also think it would also be nice to have something like [mc~] as an 
alias for [clone -x -d] because the latter is not exactly obvious.

---

7) Ideas for new objects:

* [split~] (or [moses~], etc.): take a multi-channel signal and split it 
into two different multi-channel signals at the specified channel offset.

* [join~] (or [merge~], etc.): take several multi-channel signals and 
combine them as a single (multi-channel) signal. (Actually, the same 
functionality could be achieved by a more generalized version of [pack~] 
that also deals with multi-channel input signals.)

---

8) Ideas for existing objects:

AFAIU, the plan is to make all math objects multi-channel aware, but not 
touch any "stateful" objects, such as filters or oscillators. Generally, 
I agree with this!

Some random objects that could be made multi-channel aware:

a) [sig~], i.e. [sig~ 0.1 0.5 0.7 0.8] would output a 4-channel signal.

b) [snapshot~]. If the input is multi-channel, it would sample all 
channels and output them as a list. This would be quite handy for 
metering multi-channel signals :-)

c) [print~], with nice formatting!

d) [expr~] and [fexpr~] :-)

---

Thanks for reading :-)

Christof

On 17.01.2023 04:23, Miller Puckette via Pd-dev wrote:
> To Pd dev -
>
> I've pushed what I think is working support for multichannel signals.  Many
> objects haven't yet been adapted to deal with them, but there are enough to
> at least test the concepts: lop~, send~, receive~, and (ugh) clone are
> multichannel-aware, and new pack~ and unpack~ objects are provided to
> combine and split signal channels.
>
> I've put a couple of example patches on
> http://msp.ucsd.edu/tmp/multichannel-tests.tgz
> ... the interplay between multichannel inlets and outlets and clone
> are sometimes amusing.
>
> cheers
> Miller
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230125/d388fc75/attachment.htm>