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 < [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> 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 <[email protected]> on behalf of José >>>> Rafael Subía Valdez <[email protected]> >>>> *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 >>>> JRSV | Official website <http://www.jrsv.net/> >>>> 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 ... >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >>>> stinfo/pd-list >>>> >>>> >>> >>> >>> -- >>> José Rafael Subía Valdez >>> www.jrsv.net >>> >>> >>> >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >>> stinfo/pd-list >>> >>> >> > > > -- > José Rafael Subía Valdez > www.jrsv.net > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
