For example, [myabs] can then have a [r $0/init], so you can (re)init
all instances from the parent patch.
Sorry, that should be [r $1/init], of course!
The first argument of the abstraction is the global identifier. With
[myabs $0], the instances are scoped to the enclosing abstraction, with
[myabs foo], they are in global scope.
Christof
On 16.08.2020 13:10, Christof Ressi wrote:
The purpose of subpatches is to hide stuff. If you feel the need for
creation arguments, it is a good indication that you really should be
using an abstraction instead. That's what they are made for.
Like, when you need to make just 2 copies of something in a patch.
Left / right pairs for stereo processing, etc. Much easier just to
have 2 subpatches than save a separate abstraction file, especially
if you're working on a big project with lots of files.
This is rather messy. If you have to (almost) identical patches, you
should be using an abstraction instead. This is cleaner and guarantees
that the instances stay in sync. If you edit one instance, do you
always want to delete and recreate all other instances, like you have
to with subpatches?
Also makes it easier to share things with people if you only have to
share one .pd file rather than a folder with abstractions, etc.
Just share a .zip file?
If you could do something like [pd volume #0] and have that argument
unique to that subpatch
Just pass some identifier that is unique to the enclosed abstraction,
e.g. [myabs $0]. For example, [myabs] can then have a [r $0/init], so
you can (re)init all instances from the parent patch. This is actually
a common pattern.
But the main thing i have always wanted it for is for state saving.
BTW, have a look at the new [savestate] object.
Christof
On 16.08.2020 12:49, Matt Davey wrote:
Creation arguments for subpatches is something i have wanted for
years. Would come in very handy in a few cases.
Like, when you need to make just 2 copies of something in a patch.
Left / right pairs for stereo processing, etc. Much easier just to
have 2 subpatches than save a separate abstraction file, especially
if you're working on a big project with lots of files. Also makes it
easier to share things with people if you only have to share one .pd
file rather than a folder with abstractions, etc.
But the main thing i have always wanted it for is for state saving.
If there was something akin to $0 for subpatches, then they could be
uniquely identified, and uniquely tied to an enclosed abstraction.
So, say you have a simple volume control abstraction ( inlet~ -> *~
-> outlet ), and you enclose that it [pd volume] subpatch which is
just a graph-on-parent slider. If you could do something like [pd
volume #0] and have that argument unique to that subpatch, and then
put [volume-abstraction #0] inside that subpatch, then you would have
unique caller / listener pairs for that subpatch only, but also have
the ability to save the state of the slider in the subpatch by
setting it to 'init'.
So, in effect, you could create any number of [pd volume #0]
subpatches, and all have them with their own independent slider
values that can be saved in the parent patch.
For simple examples like that, maybe not too much to be gained...can
just use an inlet to the abstraction and join it that way. But would
be very useful for larger patches with multiple GUI elements. Would
save a lot of messy cable joining, and [route 0 1 2 3 4 5 6 7] etc
solutions.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
