+1 for dynamic change in instance numbers has come up here before…
best hans > Am 06.06.2020 um 11:31 schrieb Dan Wilcox <danomat...@gmail.com>: > > 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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
