[PD] mc – multichannel extension for Pd
Christof Ressi
info at christofressi.com
Thu Dec 9 15:03:29 CET 2021
> The main idea (trick) was to hold an parallel info about a signal which
> multichannel or not... to be upward compatible and add some multichannel
> natives object to collect and distribute.
FWIW, after talking to Winfried about Pd-snake a while ago, I worked out
a backwards compatible multichannel solution in my sketch book but never
came around making a proof of concept implementation (yet). AFAICT, it
should be possible to do.
Some things I wrote down:
* [mc~ join <nchannels>] join several (single-channel) input signals
into a multi-channel output signal.
* [mc~ split <nchannels>] splits a multi-channel input signal into
invidual (single-channel) output signals
* [mc~ sig <nchannels>] creates a multi-channel signal from several
float inlets.
* [mc~ <obj>] tells an object to operate in multi-channel mode. If the
object doesn't support it (or knows about it), it operates as if the
inputs were single-channel and Pd prints a warning.
* [clone] accepts multi-channel inputs and forwards them to the
abstractions.
* [clone -m], on the other hand, takes several multi-channel inputs and
distributes them channel-wise over abstraction instances, i.e. instead
of passing the same input to every abstraction, abstraction1 only gets
the first channel of each input, abstraction2 only the second channel of
each input, etc. The resulting outputs are not summed but rather joined
into multi-channel signals. If there are no signal inputs, [clone -m]
effectively *generates* multi-channel signals. The number of cloned
instances can be changed dynamically.
* only few objects, like [mc~ join] or [clone -m], require the user to
explicitly specify the number of channels, most other objects in the
chain would simply infer the number of output channels from the input
channels in the "dsp" method. In practice, this means you can just
change the creation argument of [mc~ join] or [mc~ sig] and all the
following objects will update automatically. Most existing objects would
simply have as many output channels as input channels, but new
(external) objects can follow their own rules. One example would be a
matrix multiplication object.
* Actually, [mc~ <obj>] wouldn't even be necessary, as we can simply
infer from the inputs if the object should operate in multi-channel
mode. But I can imagine that in this case explicit might be better than
implicit.
* in "t_signal", multiple channels are contained in a single buffer
consecutively (non-interleaved). We can simply add a new "s_channels"
member to the "t_signal" struct. Objects that are not aware of
multi-channel-processing would just ignore the "s_channels" member and
operate on a single channel. One problem arises if a multi-channel-aware
external is loaded into an older Pd version which doesn't have the
"s_channel" member yet. There a several ways to avoid this situation.
One easy solution is to require the external to call a new API function,
so it would simply refuse to load in older Pd versions.
Maybe I have some time next year to come up with a PoC. Or someone else
wants to pick up those ideas.
Christof
On 09.12.2021 09:41, Winfried Ritsch wrote:
> Am Sonntag, 5. Dezember 2021, 17:22:44 CET schrieb Thomas Grill:
>> Hi all,
>> i'd like to make you aware of an abstraction library i have made because of
>> working more with multi-channel loudspeaker systems lately.
>>
>> Dealing with many parallel signal connections was cumbersome, so i have come
>> up with the mc library in order to abstract multi-channel processing. It
>> consists of pure-Pd abstractions using dynamic object creation and it is
>> NOT related or compatible with the similarly named Max approach. I hope
>> there are no similar libraries out yet, i have not come across anything
>> related.
>>
> There was an discussion 2013 on a workshop with Miller on the IEM and a
> solution was proposed:
>
> "Pd-snake was an idea 2013 within a workshop with Miller Puckette at the IEM
> to extend Pd with multichannel signal connection, which is backwards
> compatible, but has not been implemented yet."
>
> The main idea (trick) was to hold an parallel info about a signal which
> multichannel or not... to be upward compatible and add some multichannel
> natives object to collect and distribute.
>
> In the meantime I did a sime multichannel objects for Ambisonics and other
> purposes as abstraction library only, using dynamic patching and used it in
> some projects (mainly Auditory Environments) until today:
>
> - https://git.iem.at/pd/acre-amb
>
> mfg winfried
>
>> Please check it out at
>> https://github.com/grrrr/mc <https://github.com/grrrr/mc>
>>
>> It is definitely not more than alpha quality and currently has only basic
>> functionality (as much as i have needed so far). But i'd like to put it out
>> to the public since i don't know how much i will be able to work on it, and
>> i'd like to hear about your feedback and suggestions for further
>> functionality.
>>
>> There are rough edges, for example message boxes popping up when closing
>> patches with dynamic modifications, but i am not sure to which extent these
>> effects can be handled on the patcher level.
>>
>> A technical note:
>> The connection logic works both on signal and message connections (the
>> latter over send/receive). In principle message-only would be possible, but
>> signals seem to be necessary for the correct ordering of the message graph.
>> Right now the same information is sent on signals (2 integer numbers per
>> vector: ID and channel count) and messages. There is definitely a lot to
>> optimize, maybe the signal connections can be dummy, without any
>> information sent at all. However, the connection logic overhead seems to be
>> absolutely negligible compared to the DSP load.
>>
>> Please let me know what you think.
>>
>> best, Thomas
>>
>> --
>> Thomas Grill
>> http://grrrr.org <http://grrrr.org/>
>
More information about the Pd-list
mailing list