You are missing clone individual instance outlets and I’m missing dynamic clone instance numbers.
I’d like to be able send a message to clone to change the number of instances so the server could save a bit more resources beyond using [switch~]. This is important for performance scaling between working on a project on a Macbook Air then performing with it live on a Mac Pro in the studio. More importantly, we have older projects which use large multi-channel files, so it would be nice to dynamically change the sound file outputs individually up to 32 channels. My only thought for these is to have separate *light* and *heavy* server patches which load different instances of the main abstractions with more or less numbers. Eh, seems clunky too. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Jun 6, 2020, at 10:47 AM, baptiste chatel <baptiste.cha...@gmail.com> > wrote: > > 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 <danomat...@gmail.com> 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 <baptiste.cha...@gmail.com> >>> 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 <danomat...@gmail.com> 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, pd-list-requ...@lists.iem.at wrote: >>>>> >>>>> Message: 5 >>>>> Date: Fri, 5 Jun 2020 19:20:36 +0200 >>>>> From: baptiste chatel <baptiste.cha...@gmail.com> >>>>> To: Pd-List <pd-list@lists.iem.at> >>>>> 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 >>>> danomatika.com >>>> robotcowboy.com >>>> >>>> >>>> >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >>
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
