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 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.chatel@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 <danomatika@gmail.com mailto:danomatika@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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 5 Date: Fri, 5 Jun 2020 19:20:36 +0200 From: baptiste chatel <baptiste.chatel@gmail.com mailto:baptiste.chatel@gmail.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: [PD] [clone] with individual signal inlets/outlets exposed ? Message-ID: <CABrNpLyvGHrRV-+9wDj2p8NnZENQDwEgg-tO7yFHEjw5L1eV6Q@mail.gmail.com mailto:CABrNpLyvGHrRV-+9wDj2p8NnZENQDwEgg-tO7yFHEjw5L1eV6Q@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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/