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
