That looks like an impressive bit of work ! I did something along thoses lines a while ago, while at a smaller scale. In the end, i guess the "clunkiness" was too much for me to deal with. But that was pre intelligent patching era ! That's why i can now think about simply connecting multi-i/os objects (IEM ambisonics plugins with [vstplugin~]) together in a blink, and scale the number of i/o as i need without resorting to workarounds, and more importantly without having to re-engineer what looks like a simple thing (in my head, that is). So now i feel that since we can connect a great number of cable easily, we should be able to multiply objects in the same way.
Le ven. 5 juin 2020 à 21:22, Dan Wilcox <[email protected]> a écrit : > I think you can also be clever about the mixing and the outputs... > > In my case, I usually end up with an output abstraction to [dac~]: > > [receive~ out$1] > | > [*~] <--- some gain control input > | > [dac~ $1] > > A use case would be the zirk_id -> zirk_speaker -> zirk_output handling in > the ZKM Zirkonium server patches: > > https://github.com/ZKM-IMA/ZirkoniumSpatializationServer > > (It's currently macOS-only as it includes custom binaries for the > spatialization algorithms. I will probably fix this by fall.) > > In this case, Zirkonium has the following layout: > > 64 live input channels > 64 input sound files (with 8 channels) > 64 IDs aka objects mapping between input channels (live or sound file) and > spatialization algorithms to virtual speakers > 64 virtual speakers wich are mapped to outputs > 64 output dac~ wrappers > > The ID objects & spat algo wrappers use additional clones internally to > map each channel to all of the virtual speakers. I imagine a setup like > this could work for you. A [zirk_vbap] object, for example, has an internal > clone with [zirk_dispatcher]s which handle the connections between the > named sends~/receives~. It's a little clunky but it works. > > I think a bunch of giant 64-channel output objects would also be clunky > and also work, but in a different way. :) > > On Jun 5, 2020, at 8:43 PM, baptiste chatel <[email protected]> > wrote: > > Clever, but you have to do a repetitive error-prone lengthy clicky process > either on the send side or on the receive side. > Since in my case i have four 16-tracks sends to a 64 by 16 matrix (3rd > order ambisonics monitoring), i mitigated the issue by making an > abstraction containing 16 settable sends, taking a float as an argument for > the first send number. On the other side, i still had to make 64 unique > receives... > > Le ven. 5 juin 2020 à 20:23, Dan Wilcox <[email protected]> a écrit : > >> Your abstraction can have a named [send~] which you can receive into your >> matrix. Use the $1 id assigned by clone to differentiate the sends, ie. >> >> In abstraction: >> >> | >> [send~ out$1] >> >> For matrix: >> >> [receive~ out1] [receive~ out2] [receive~ out3] >> | | | >> [matrix - - ...] >> >> etc >> >> In this way, the [clone] itself has no outputs, but you have all of the >> outputs via [send~]. I use this approach very often. >> >> On Jun 5, 2020, at 7:49 PM, [email protected] wrote: >> >> Message: 5 >> Date: Fri, 5 Jun 2020 19:20:36 +0200 >> From: baptiste chatel <[email protected]> >> To: Pd-List <[email protected]> >> Subject: [PD] [clone] with individual signal inlets/outlets exposed ? >> Message-ID: >> <cabrnplyvghrrv-+9wdj2p8nnzenqdwegg-to7yfhejw5l1e...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Would it be possible to have a [clone] option that allows clones >> individual >> signal inlets/outlets to be exposed ? >> >> An example : i need to make 64 of the following patch : >> [receive~ thing-$1] >> | >> [outlet~] >> that should go to a matrix, $1 in [1:64]. >> >> [clone] is useless because it will sum all outputs and expose only one, >> since the cloned patch has one output. >> >> I could do it with dynamic patching, but as practical as it could be, it >> is >> pretty convoluted to use for such a simple need. >> >> >> Baptiste >> >> >> -------- >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com >> robotcowboy.com >> >> >> >> > -------- > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
