hello list, I'm wondering if there is the need of a new object in pd....
there is one problem in patching: often, someone need some repetition of objects, or group of objects, and their connections (e.g.: making a data seqencer, or some routing matrix, or multiple instances of a "foo").
for example some piece of code in a subpatch has to be repeated many times, in front of a route, or select, a mixer or whatever, and you have to copy+paste many objects and connect manually together.
I know, exists dyn~, but it doesn't offers the same flexibility as classic-patch-editing concept.
what do you think of a naw type of object, that can act like a subpatch (or abstraction) does, and provide yet multiple inlets for controlling N instances of that subpatch? is this (already) possible to do? perhaps can be made with an external...?
ciao
I know, exists dyn~, but it doesn't offers the same flexibility as classic-patch-editing concept.
not sure if you ran across nqpoly. but i think it was some attempt to provide polyphonic abstractions like you described
what do you think of a naw type of object, that can act like a subpatch (or abstraction) does, and provide yet multiple inlets for controlling N instances of that subpatch? is this (already) possible to do?
in om-synth you can have N instances of a subpatch appear as one. in PD you wil have to copy/paste them or generate them via some hack..
On Apr 22, 2006, at 2:42 AM, carmen wrote:
I know, exists dyn~, but it doesn't offers the same flexibility as
classic-patch-editing concept.not sure if you ran across nqpoly. but i think it was some attempt
to provide polyphonic abstractions like you described
nqpoly4 is a really nice object (but could use some good docs). Its
included in Pd-extended, including some decent examples. I've used
it for polyphonic, and for controlling many clones of the same object
in Gem.
.hc
what do you think of a naw type of object, that can act like a
subpatch (or abstraction) does, and provide yet multiple inlets for controlling N instances of that subpatch? is this (already) possible to do?in om-synth you can have N instances of a subpatch appear as one.
in PD you wil have to copy/paste them or generate them via some hack..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Information wants to be free." -Stewart Brand
Zitat von Federico xaero@inwind.it:
hello list, I'm wondering if there is the need of a new object in pd....
...
i usually deal with this problem by using send/receive instead of patch cords. i seldomly experience problems with the order of execution when dealing with many instances of an object (they tend to work in parallel and not interfere with each other - at least not where execution order is a problem).
you can interact with each object separately either via special receive-names ("$1_my_param" where $1==1..N) or via special messages to a "global" (could be localized with $0) receiver and the use of [route] (msg "$1 <parm>" to "my_param" and then do a [route $1]))
both approaches have pros and cons (symbol-table pollution vs. [route]-evaluation)
apart from that, a hierarchical approach (loads and loads of abstractions) often helps a lot, even if you don't like hierarchies...
mfg.adsr IOhannes
zmoelnig@iem.at wrote:
Zitat von Federico xaero@inwind.it:
hello list, I'm wondering if there is the need of a new object in pd....
...
i usually deal with this problem by using send/receive instead of patch cords. i seldomly experience problems with the order of execution when dealing with many instances of an object (they tend to work in parallel and not interfere with each other - at least not where execution order is a problem).
you can interact with each object separately either via special receive-names ("$1_my_param" where $1==1..N) or via special messages to a "global" (could be localized with $0) receiver and the use of [route] (msg "$1 <parm>" to "my_param" and then do a [route $1]))
uhm... you mean that [apart creating gui objects, and renaming their send/receive symbols], receiving their values it's just a message/route/send work?!? no additional patching would be required? (i.e. expanding number of sliders from 128 to 512 would not affect the logic code, but only copying and pasting and renaming 512 sliders?)
however my point wasn't only this... more generally i would say: repetition of objects, groups, or instances, is a common pattern in pd. and there are certain ways to do it (select, route, multiple inlets, and so on), but all of them require a lot of patching (proportional to the number of instances you want). why souldn't exists an object which does this for you?
Federico wrote: ...
more generally i would say: repetition of objects, groups, or instances, is a common pattern in pd. and there are certain ways to do it (select, route, multiple inlets, and so on), but all of them require a lot of patching (proportional to the number of instances you want). why souldn't exists an object which does this for you?
it is possible to make crippled substitutes like nqpoly or rabin/clone, but it is not possible to introduce proper multi-abstractions without a major redesign of Pd internals.
The main obstacle is that Pd maintains only a single monolithic dsp graph. Breaking that would not be easy now: there are optimizing hacks in dsp graph handling, plus various patches in the code for features like resampling, etc. These are all great, but they make the implementation quite complex, and nobody seems to dare touching it.
k
On Sun, 23 Apr 2006, Krzysztof Czaja wrote:
The main obstacle is that Pd maintains only a single monolithic dsp graph. Breaking that would not be easy now: there are optimizing hacks in dsp graph handling, plus various patches in the code for features like resampling, etc. These are all great, but they make the implementation quite complex, and nobody seems to dare touching it.
Well, it's also that no-one wants to do it for 0.39 when 0.40 is supposedly coming soon and that no-one knows how the internals will change in 0.40 and what it would take to get Miller interested in including the feature in Pd before Pd changes too much. (same old story)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Apr 23, 2006, at 1:00 AM, Krzysztof Czaja wrote:
Federico wrote: ...
more generally i would say: repetition of objects, groups, or
instances, is a common pattern in pd. and there are certain ways
to do it (select, route, multiple inlets, and so on), but all of
them require a lot of patching (proportional to the number of
instances you want). why souldn't exists an object which does this for you?it is possible to make crippled substitutes like nqpoly or rabin/clone, but it is not possible to introduce proper multi-abstractions without a major redesign of Pd internals.
nqpoly~ may be crippled, but nqpoly4 is actually quite good. The
only tricky thing about it is initialization. And you do have to
close and reopen patches sometimes to reset everything. But once you
get things running, its quite stable. I used nqpoly4 in my solitude
piece, there I controlled 500 instances of an object. Right now I am
helping someone control 100 spheres in Gem using nqpoly4.
I have been meaning to write some good docs for it, plus I want to
try my hand at some minor improvements too. Some day...
.hc
The main obstacle is that Pd maintains only a single monolithic dsp graph. Breaking that would not be easy now: there are optimizing hacks in dsp graph handling, plus various patches in the code for features like resampling, etc. These are all great, but they make the implementation quite complex, and nobody seems to dare touching it.
k
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies."
- Amy Smith
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
nqpoly~ may be crippled, but nqpoly4 is actually quite good. The
only tricky thing about it is initialization. And you do have to
close and reopen patches sometimes to reset everything. But once you
get things running, its quite stable. I used nqpoly4 in my solitude
piece, there I controlled 500 instances of an object. Right now I am
helping someone control 100 spheres in Gem using nqpoly4.
I'm not sure, if you can use it, but there is a nice Gem idiom which makes dealing with large numbers of objects of the same kind (like 100 spheres) much easier than creating 100 [sphere] objects. It involves the use of IEMlib's [any] object connected to a [separator]. I use this idiom a lot when visualising physical models with [msd]. Attached is the abstraction I use there.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I'm not sure, if you can use it, but there is a nice Gem idiom which makes dealing with large numbers of objects of the same kind (like 100 spheres) much easier than creating 100 [sphere] objects. It involves the use of IEMlib's [any] object connected to a [separator]. I use this idiom a lot when visualising physical models with [msd]. Attached is the abstraction I use there.
Great patch. I use 30 spheres in a patch and this patch solves my problem of dyn or copy-and-paste! Thanks for sharing...
br, Piotr
Hallo, Federico hat gesagt: // Federico wrote:
you mean that [apart creating gui objects, and renaming their send/receive symbols], receiving their values it's just a message/route/send work?!? no additional patching would be required? (i.e. expanding number of sliders from 128 to 512 would not affect the logic code, but only copying and pasting and renaming 512 sliders?)
Actually something like this is automatically built into the RRADical patches using Memento. If you create several instances of an abstraction using the same OSC-name (== first argument of RRADical patches), you can use one as the "master" abstraction and connect the OSC outlet of the master to the OSC inlet of all slave abstractions. Every change of settings inside the master will then propagate to all slaves. I use this feature quite often to create polyphony. You can see it in action in the PDX7 V2 poly example: http://footils.org/cms/show/51
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Federico wrote:
zmoelnig@iem.at wrote:
Zitat von Federico xaero@inwind.it:
hello list, I'm wondering if there is the need of a new object in pd....
...
i usually deal with this problem by using send/receive instead of patch cords. i seldomly experience problems with the order of execution when dealing with many instances of an object (they tend to work in parallel and not interfere with each other - at least not where execution order is a problem).
you can interact with each object separately either via special receive-names ("$1_my_param" where $1==1..N) or via special messages to a "global" (could be localized with $0) receiver and the use of [route] (msg "$1 <parm>" to "my_param" and then do a [route $1]))
uhm... you mean that [apart creating gui objects, and renaming their send/receive symbols], receiving their values it's just a message/route/send work?!? no additional patching would be required? (i.e. expanding number of sliders from 128 to 512 would not affect the logic code, but only copying and pasting and renaming 512 sliders?)
i only described how I deal with multiple instances of objects without getting into too much connection fiddling. i am not saying that it works "out of the box".
however, i daresay that a lot of patches as you describe would involve to only a copy'n'paste of your 512 sliders and 512 instances of logic. (matju, that was for you)
however my point wasn't only this... more generally i would say: repetition of objects, groups, or instances, is a common pattern in pd. and there are certain ways to do it (select, route, multiple inlets, and so on), but all of them require a lot of patching (proportional to the number of instances you want).
i cannot follow you here. i think that you can do most of this tasks with a constant(!) patching overhead instead of an overhead proportional to the number of instances. however, the overhead might be big and sub-optimal.
why souldn't exists an object which does this for you?
i haven't said that it would be a bad idea. i just tried to explain my workarounds.
and the reason is most likely: time, money, and more important things to do :-)
mfg.asdr. IOhannes
i used to spend a LOT of time renaming multiple send / recieve pairs, making giant [route a b c d e f ....z] objects, etc....then connecting hundreds of patch cords by hand.
but i generally don't do that at all anymore. there are usually other ways.
for example:
*store your data in tables and use tabread to access it
*use qlist, or even better [msgfile] to access lots of data
[pack f f] | [; $1-send $2<
however: >>what do you think of a new type of object, that can act like a subpatch (or abstraction) does, and provide yet multiple inlets for controlling N instances of that subpatch? is this (already) possible to do? perhaps can be made with an external...?<<
i think it might be handy, and i think you could make an abstraction that does this for you.
have a think. good luck.
Hey,
I use an abstraction [dir2abstractionArray] in pixelTANGO for the pixel effects stuff, which makes a dynamic array of abstractions that are listed in a directory. Dynamic patching gets more ugly with many many objects, but I've not needed to do manual connections for some time.
Most of the time I use [constructor] which was once in the pmpd stuff, maybe its in pixelTANGO, and therefore pd-extended too, I'm not sure. Anyhow its just a abstraction that makes arrays of abstractions.
dir2abstractionArray does this for abstractions listed in a directory, and also brokers the communication. You give it an index, and it routes two inlets and two outlets to the abstraction selected by the index.
I'm sure there are better repeat/nqpoly ways of doing this stuff, at least arrays of abstractons, but I've not gotten my head around those quite yet.
.b.
hard off wrote:
i used to spend a LOT of time renaming multiple send / recieve pairs, making giant [route a b c d e f ....z] objects, etc....then connecting hundreds of patch cords by hand.
but i generally don't do that at all anymore. there are usually other ways.
for example:
*store your data in tables and use tabread to access it
*use qlist, or even better [msgfile] to access lots of data
[pack f f] | [; $1-send $2<
however: >>what do you think of a new type of object, that can act like a subpatch (or abstraction) does, and provide yet multiple inlets for controlling N instances of that subpatch? is this (already) possible to do? perhaps can be made with an external...?<<
i think it might be handy, and i think you could make an abstraction that does this for you.
have a think. good luck.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 23 Apr 2006, IOhannes m zmoelnig wrote:
however, i daresay that a lot of patches as you describe would involve to only a copy'n'paste of your 512 sliders and 512 instances of logic. (matju, that was for you)
I'm listening, but what are you trying to say?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 23 Apr 2006, IOhannes m zmoelnig wrote:
however, i daresay that a lot of patches as you describe would involve to only a copy'n'paste of your 512 sliders and 512 instances of logic. (matju, that was for you)
I'm listening, but what are you trying to say?
i hoped you were commenting on "512 instances of logic"
mfg.asdr. IOhannes
On Mon, 24 Apr 2006, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sun, 23 Apr 2006, IOhannes m zmoelnig wrote:
however, i daresay that a lot of patches as you describe would involve to only a copy'n'paste of your 512 sliders and 512 instances of logic. (matju, that was for you)
I'm listening, but what are you trying to say?
i hoped you were commenting on "512 instances of logic"
Well... if it's exactly 512 you can patch that in logarithmic time using a sequence of abstractions that instantiates each preceding abstraction twice, yielding 2^n copies of the original abstraction. The technique may also be trivially expanded to any prime power by a similar divide-and-conquer technique. ;-)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
B. Bogart -
carmen -
Federico -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Krzysztof Czaja -
Mathieu Bouchard -
Piotr Majdak -
zmoelnig＠iem.at