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 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/
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 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 wrote:
Message: 5 Date: Fri, 5 Jun 2020 19:20:36 +0200 From: baptiste chatel baptiste.chatel@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] [clone] with individual signal inlets/outlets exposed ? Message-ID: 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 robotcowboy.com
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/
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 danomatika@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.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 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 wrote:
Message: 5 Date: Fri, 5 Jun 2020 19:20:36 +0200 From: baptiste chatel baptiste.chatel@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] [clone] with individual signal inlets/outlets exposed ? Message-ID: 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 robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.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.chatel@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 danomatika@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.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 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 wrote:
Message: 5 Date: Fri, 5 Jun 2020 19:20:36 +0200 From: baptiste chatel baptiste.chatel@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] [clone] with individual signal inlets/outlets exposed ? Message-ID: 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 danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
+1 for dynamic change in instance numbers
has come up here before…
best hans
Am 06.06.2020 um 11:31 schrieb Dan Wilcox danomatika@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.chatel@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 danomatika@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.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 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 wrote:
Message: 5 Date: Fri, 5 Jun 2020 19:20:36 +0200 From: baptiste chatel baptiste.chatel@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] [clone] with individual signal inlets/outlets exposed ? Message-ID: 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 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
Em sáb., 6 de jun. de 2020 às 07:42, hans w. koch hansw.koch@gmail.com escreveu:
+1 for dynamic change in instance numbers
has come up here before…
I'm surprised it hasn't been listed on github's issues, until now https://github.com/pure-data/pure-data/issues/1055
On 6/5/20 8:43 PM, baptiste chatel wrote:
Clever, but you have to do a repetitive error-prone lengthy clicky process either on the send side or on the receive side.
how so?
https://vimeo.com/273707442 https://vimeo.com/279631360 https://vimeo.com/340437816
gfmr IOhannes
Yes, i know about intelligent patching. I must admit that all the shortcuts are not stored in muscle memory yet ! But that does not solve the issue of having to duplicate and change the argument of a great number of objects. As i said to Dan, intelligent patching is so great now that having this -mcin -mcout option added to [clone] looks like intelligent patching and [clone] were made for each other !
Le ven. 5 juin 2020 à 21:25, IOhannes m zmölnig zmoelnig@iem.at a écrit :
On 6/5/20 8:43 PM, baptiste chatel wrote:
Clever, but you have to do a repetitive error-prone lengthy clicky
process
either on the send side or on the receive side.
how so?
https://vimeo.com/273707442 https://vimeo.com/279631360 https://vimeo.com/340437816
gfmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
baptiste chatel -
Dan Wilcox -
hans w. koch -
IOhannes m zmölnig