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/> > >> > >> _______________________________________________ > >> [email protected] mailing list > >> UNSUBSCRIBE and account-management -> > >> https://lists.puredata.info/listinfo/pd-list> > > -- > > Thomas Grill > > http://grrrr.org > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list -- - ao.Univ.Prof. DI Winfried Ritsch - [email protected] - 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
