[PD] mc – multichannel extension for Pd

[Christof Ressi]

Lots of nice ideas! I will definitely look at your abstractions for 
inspiration.

On 09.12.2021 16:34, Thomas Grill wrote:
> 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
> http://grrrr.org
>
>