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 <[email protected]> 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 < > [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/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
