Am I right in thinking that this is however only copies of one and the same abstraction?
Yes, that's correct. So in your case dynamic patching might be still the easier solution. Actually, it would be nice to have some kind of object which can load abstractions on the fly. It doesn't have to be [clone]. Christof
Gesendet: Samstag, 18. Januar 2020 um 19:50 Uhr Von: "tim vets" timvets@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Betreff: Re: Re: [PD] clone vs. dynamic patching
Op za 18 jan. 2020 om 19:23 schreef Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:> Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet,
rather than having parallel copies of one abstraction...?
You can do this with [send~]/[receive~]: each abstraction could have a [receive~] based on its instance number, e.g. [r~ /foo/$1], and also a [send~] which you can route to wherever you want, e.g. to the next instance:
[loadbang] -> [f $1] -> [+ 1] -> [set /foo/$1( -> [send~]
You can feed a signal into [clone] with [send~ /foo/0] and in the last instance you can send the signal to a [receive~] outside of clone. Alternatively, only the first instance could read from the [inlet~] and only the last instance could write to the [outlet~] by using [*~]. You can pass the total number of instances, so each instance knows whether it's the last one. Hi Christof, thanks for this, interesting! Am I right in thinking that this is however only copies of one and the same abstraction? What if I want to, say, load a bass-synth abstraction and route it through some sound effect, say a flanger? I'm currently working on a patch that should become dynamically reconfigurable, so that you can load up a new synth with some effects of your choosing... So far, the only way I could come up with is dynamic patching the old-fashioned way. I'm open to suggestions otherwise! Tim Christof
Gesendet: Samstag, 18. Januar 2020 um 18:30 Uhr Von: "tim vets" <timvets@gmail.com[mailto:timvets@gmail.com]> An: Pd-List <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] clone vs. dynamic patching
Op za 18 jan. 2020 om 18:03 schreef Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at][mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]]>:I always use [clone] when I need several instances of an abstraction. Dynamic patching is a hack and shouldn't be used anymore for this purpose. Is there a way to make other kinds of structures inside [clone] though? Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet, rather than having parallel copies of one abstraction...? > one feature badly missing is the possibility ta allocate dynamic "voice"
(or "instance") numbers (i.e. how many instances of an abstraction are created).
That would be useful and it's actually on my to-do-list :-). But usually I just allocate the max. number of instances I need and simply "disable" instances I don't need. I think this is generally the better approach for cloned DSP objects (using [switch~], because dynamically changing the number of voices wouldn't be realtime safe anyway...
Christof
Gesendet: Samstag, 18. Januar 2020 um 16:46 Uhr Von: "oliver" <oliver@klingt.org[mailto:oliver@klingt.org][mailto:oliver@klingt.org[mailto:oliver@klingt.org]]> An: Pd-List <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]]> Betreff: Re: [PD] clone vs. dynamic patching
João Pais wrote:
Hello list,
I didn't try clone yet, I always worked with dynamic patching for similar issues. For those who are knowledgeable, I would like to ask: is there any advantage of clone against dynamic patching when using the same circuit, or is it the same? This pertains to patches working on both control and signal input/output.
if you are familiar with MAX:
[clone] is nearly the same as [poly~]
one feature badly missing is the possibility ta allocate dynamic "voice" (or "instance") numbers (i.e. how many instances of an abstraction are created). i hope miller has plans to implement this in the future.
right now, all you can do is a combination of using [clone] and dynamic patching if you want to change the number of instances on the fly (destroy the old clone object and re-create it with new arguments with PD messages).
i used [clone] on several occasions and find it extremely useful, as you can directly edit the original source and see the results (as opposed to MAX).
i would say the best use case is a situation, where you need let's say 10 or more copies of a patch (i.e. for parameter organisation, oscillator banks etc...). basically it's the same as creating multiple abstractions where you do the message routing internally with a creation argument
[abs 1] [abs 2] [abs 3] [abs 4] etc...
so, no - there's no direct ADVANTAGE over dynamic patching but in general i think it's the better and clearer concept
best
oliver
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]