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.
(in case relevant - on windows)
Best,
jmmmp
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
Em sáb., 18 de jan. de 2020 às 12:49, oliver oliver@klingt.org escreveu:
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).
Yeah, that's a nice feature to have, why don't you open a request on github? https://github.com/pure-data/pure-data/issues
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.
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 An: Pd-List 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Op za 18 jan. 2020 om 18:03 schreef Christof Ressi 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 An: Pd-List 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 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
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.
Christof
Gesendet: Samstag, 18. Januar 2020 um 18:30 Uhr Von: "tim vets" timvets@gmail.com An: Pd-List 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]>: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]> An: Pd-List <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] 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... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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...
that is usually enough, but in some cases there is no limit, and it has to be tried out what the best results are - not necessarily in realtime. For now I'm doing that by calling clone dynamically in a dedicated subpatch.