this is what  am trying to do now. but how I am doing it is by creating a "menu bar" like abstraction that can produce the GUIs with state saving possibilities via dynamic patching and you only need to give $1 to the bar, ensuring that this will create the unique tag to every GUI coming from that "menu bar". Not what I wanted, but.. hey, problems get solved differently as you digg into it, right? :s



On Mon, Sep 5, 2016 at 4:56 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
​I see. Thanks; that scope problem is a little tougher, but the usual way around it is to keep only one ID-issuing machine in the top patch and then pass the top patch's $0 into all the lower level abstractions as the first creation argument. Anything instantiated in the top patch gets [abstraction $0]; anything deeper gets [​child-abstraction $1].

I could be wrong about one thing, though: I've been assuming that once everything in a patch (and all its abstractions) is saved in its final form that the instantiation order of everything will be identical across loads. I believe this is guaranteed, but I can't remember for sure.

On Mon, Sep 5, 2016 at 11:38 AM, José Rafael Subía Valdez <jsubiavaldez@gmail.com> wrote:
Hello Matt,

I mean that the abstractions created inside an abstraction will have an independent order of creation, so when the patch is initialized they count from 0 which conflicts with the ones created in the "main" that also begin in 0.



On Mon, Sep 5, 2016 at 4:11 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
For most of these situations I store settings in a table that saves in the patch. On load I just distribute them to my abstractions as init values. The problem of course is that you have to hand-code the receives and you want something automatic. The solution I posted on Facebook earlier (attached) uses the instantiation order of abstractions to request a unique ID from the main patch. But then you say this: "However, the order of creation resets if in a subpatch or an abstraction with GOP." I don't know what this means; are you saying that the instantiation order does not persist once you have the patch done?


On Mon, Sep 5, 2016 at 8:11 AM, José Rafael Subía Valdez <jsubiavaldez@gmail.com> wrote:
Hello Liam,

I am implementing a preset saving mechanism, not an initial value. Init will only save the initialization of the object. I was trying to avoid dynamic patching so users could just patch and if wanted to replace the normal TGL with the one that can record different states they could just replace it in a text file. But now I am looking into it. (but not happy as I got so close) 

cheers

On Mon, Sep 5, 2016 at 12:55 PM, Liam Goodacre <liamg_uw@hotmail.com> wrote:

Hi Jose


I am not clear on what it is you are trying to achieve.


If you're looking for a toggle with a preset 1 or 0, then there is the "init" option from the properties which will save and load the value for you.


If it is some sort of dynamic patching problem where you need to send messages to the parent patch, then the easiest thing is to use [iemguts/sendcanvas], which lets you dictate a target level (ie. [iemguts/sendcanvas 1] will send messages to the parent patch.


Do either of these help, or are you still needing a special ID number for each instance of an abstraction?


From: Pd-list <pd-list-bounces@lists.iem.at> on behalf of José Rafael Subía Valdez <jsubiavaldez@gmail.com>
Sent: 04 September 2016 11:02
To: pd-list
Subject: [PD] Stuck with a "persistency" problem
 
Hello List,

over the last couple of days, I have been programming a preset system using the [pool] object.
I have made a lot of progress but now I am stuck with a persistence problem.

a couple of days ago I started with my "scope" tests to see if its working, this included

- on the main canvas
- in a subpatch
- in a GOP abstraction with no arguments 
- in a GOP abstraction with arguments.

and here is where it got tricky. The solution that I have been trying to implement is to retrieve the parent window name or better yet the name of the canvas. [window_name] object by HCS does the trick, but the name changes every time you open PD and the file, so it is not persistent. [canvasname] on the other hand does not provide the parent canvas name.

Until now, the idea was to create a double ID that sets the name dynamically in order of creation thanks to M. Barber's and L. Goodacre's way of doing it, However, the order of creation resets if in a subpatch or an abstraction with GOP. so the second ID, would let me know the scope that I am in by adding the "window or canvas" that contains the abstractions.

Maybe someone can point me in the right direction or enlighten me with a different solution.

the objective of the set of abstractions is to just replace the object [tgl] with my abstraction [tgl_pre] and have the preset system working, so I am trying to do it without setting arguments with [tgl_pre $1] as this would imply that if I have 128 tgls, I have to rename each with a unique $1 each.

Thanks to all that have helped: T. Grill, M. Barber, L. Goodacre.

and thanks to anyone that can chip in with some ideas.

cheers
--
José Rafael Subía Valdez
www.jrsv.net
Home. Welcome to my website, here you will find information regarding my work in different fields of research and production. Find out about my projects that involve ...






_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list




--
José Rafael Subía Valdez

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





--
José Rafael Subía Valdez

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





--
José Rafael Subía Valdez
www.jrsv.net