[PD] mc – multichannel extension for Pd

Thomas Grill gr at grrrr.org
Thu Dec 9 16:34:52 CET 2021

Hi Christof,
i didn't know about the initiative, but good that this is on a todo list!
Many of your ideas listed here are implemented in my mc project.
One drawback is definitely that the send~/receive~ based architecture can't cope with varying block sizes.

There are other problems concerning state preservation of mapped objects upon changed in the signal graph which i think can't be solved within the abstraction-based system.

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

It is possible to also implement a detection whether a signal has been generated through mc._out (and represents a multichannel transport), or it is a normal signal.
This can be done using some watermark, but clearly, this will not be 100% safe.

> * [mc~ join <nchannels>] join several (single-channel) input signals into a multi-channel output signal.

i named that mc.pack~
Currently, there is also mc.concat to join two multi-signals.

> * [mc~ split <nchannels>] splits a multi-channel input signal into invidual (single-channel) output signals

there is mc.unpack~, but also mc.index / mc.slice to select channels (for example interleaved pairs) out of the multi-signal.

> * [mc~ sig <nchannels>] creates a multi-channel signal from several float inlets.

not implemented yet, but easy to do

> * [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.

mc.map maps (currently only mono) signal objects onto the multi-signal. Other mappings (most notably stereo) should be possible.
mc.effect maps the mc multi-signal to an abstraction with many signal inputs/outputs, like vstplugin~

best, Thomas

> 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/>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Thomas Grill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211209/b76c690f/attachment.sig>

More information about the Pd-list mailing list