[PD-dev] multichannel signals, preliminary support

[Alexandre Torres Porres]

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

I'm glad I'm not the only one :) and usually Pd has some funny names, so it
felt quite proper to me ;)

Em ter., 24 de jan. de 2023 às 21:58, Christof Ressi <info at christofressi.com>
escreveu:

> 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 reusing t_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 onhttp://msp.ucsd.edu/tmp/multichannel-tests.tgz
> ... the interplay between multichannel inlets and outlets and clone
> are sometimes amusing.
>
> cheers
> Miller
>
>
>
> _______________________________________________
> Pd-dev mailing listPd-dev at lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> 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/20230124/d8c4685f/attachment-0001.htm>