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/> >> > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://grrrr.org
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
