[PD-dev] [PD] REQUEST: Passed parameters into subpatch

[Christof Ressi]

> 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.
>>
>>
>>
>>
>>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list