[PD] mc – multichannel extension for Pd

Winfried Ritsch ritsch at iem.at
Thu Dec 9 18:22:33 CET 2021


Hello,

Yes, thank you Christof for your notices,there are a lot of ideas about 
PdSnake  ( https://git.iem.at/pd/pdsnake/-/blob/master/docs/
, which Miller can laugh about sometimes  ;-)

We started this repository in case someone want to implement it, maybe a place 
also for ideas  ideas in there...:

- https://git.iem.at/pd/pdsnake

mfg winfried


Am Donnerstag, 9. Dezember 2021, 16:44:33 CET schrieb 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
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list


-- 
- ao.Univ.Prof. DI Winfried Ritsch 
- ritsch at iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 







More information about the Pd-list mailing list