Re: [PD] [clone] with individual signal inlets/outlets exposed ?
Em sáb., 6 de jun. de 2020 às 07:42, hans w. koch 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
Em sáb., 6 de jun. de 2020 às 05:32, baptiste chatel < baptiste.cha...@gmail.com> escreveu: > I wish i was as skilled as you think i am ! > I'm the one impressed by your work with Cyclone and Else while describing > yourself as not so skilled in the externals programming domain :) > As a musician, what you have to do is programm by ear :) - now, don't be too impressed with my work on cyclone, the most impressive work needs to be credited to Derek Kwan and Matt Barber, I literally knew nothing when we started ;) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
+1 for dynamic change in instance numbers has come up here before… best hans > Am 06.06.2020 um 11:31 schrieb Dan Wilcox : > > 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 > 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 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 >>> 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 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 appro
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 > 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 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 >>> 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 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 202
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 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 > 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 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 >> To: Pd-List >> Subject: [PD] [clone] with individual signal inlets/outlets exposed ? >> Message-ID: >> >> 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 > > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
I wish i was as skilled as you think i am ! I'm the one impressed by your work with Cyclone and Else while describing yourself as not so skilled in the externals programming domain :) To add to the noise : your -mcin -mcout option idea is great ! Sure, there are many ways to do without this in my case, but the general idea is to improve on [clone] to be able to do quickly and simply things instead of engineering convoluted workarounds (not trying to say that the work involved by such an upgrade to [clone] is easy). Actually, i would be very satisfied by : - this -mcin -mcout option added to [clone] - a new "duplicate and increment an arg by 1" feature, so i don't feel sad and lonely because i have to rename 64 [receive]s. Le ven. 5 juin 2020 à 21:10, Alexandre Torres Porres a écrit : > I guess making noise on the list helps :) it narrows down to someone also > feel it's worth it and implement it, aren't you a skilled fellow anyway? I > think this one is over my head... I'm still only able to managing lower > hanging fruits :P > > Em sex., 5 de jun. de 2020 às 15:30, baptiste chatel < > baptiste.cha...@gmail.com> escreveu: > >> Is there a way to nicely "upvote" this request other than commenting the >> issue ? >> >> Le ven. 5 juin 2020 à 20:16, Alexandre Torres Porres >> a écrit : >> >>> I already made that request by the way >>> https://github.com/pure-data/pure-data/issues/500 >>> >>> Em sex., 5 de jun. de 2020 às 14:51, baptiste chatel < >>> baptiste.cha...@gmail.com> escreveu: >>> 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 ___ 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
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 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 <mailto: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 >> <mailto:pd-list-requ...@lists.iem.at> wrote: >> >> Message: 5 >> Date: Fri, 5 Jun 2020 19:20:36 +0200 >> From: baptiste chatel > <mailto:baptiste.cha...@gmail.com>> >> To: Pd-List mailto:pd-list@lists.iem.at>> >> Subject: [PD] [clone] with individual signal inlets/outlets exposed ? >> Message-ID: >> > <mailto: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 <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/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 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 > To: Pd-List > Subject: [PD] [clone] with individual signal inlets/outlets exposed ? > Message-ID: > > 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 > > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
I guess making noise on the list helps :) it narrows down to someone also feel it's worth it and implement it, aren't you a skilled fellow anyway? I think this one is over my head... I'm still only able to managing lower hanging fruits :P Em sex., 5 de jun. de 2020 às 15:30, baptiste chatel < baptiste.cha...@gmail.com> escreveu: > Is there a way to nicely "upvote" this request other than commenting the > issue ? > > Le ven. 5 juin 2020 à 20:16, Alexandre Torres Porres a > écrit : > >> I already made that request by the way >> https://github.com/pure-data/pure-data/issues/500 >> >> Em sex., 5 de jun. de 2020 às 14:51, baptiste chatel < >> baptiste.cha...@gmail.com> escreveu: >> >>> 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 >>> >>> >>> ___ >>> 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
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
Is there a way to nicely "upvote" this request other than commenting the issue ? Le ven. 5 juin 2020 à 20:16, Alexandre Torres Porres a écrit : > I already made that request by the way > https://github.com/pure-data/pure-data/issues/500 > > Em sex., 5 de jun. de 2020 às 14:51, baptiste chatel < > baptiste.cha...@gmail.com> escreveu: > >> 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 >> >> >> ___ >> 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
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
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 <mailto:baptiste.cha...@gmail.com>> > To: Pd-List mailto:pd-list@lists.iem.at>> > Subject: [PD] [clone] with individual signal inlets/outlets exposed ? > Message-ID: ><mailto: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 <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [clone] with individual signal inlets/outlets exposed ?
I already made that request by the way https://github.com/pure-data/pure-data/issues/500 Em sex., 5 de jun. de 2020 às 14:51, baptiste chatel < baptiste.cha...@gmail.com> escreveu: > 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 > > > ___ > 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
[PD] [clone] with individual signal inlets/outlets exposed ?
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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
