[PD] Stuck with a "persistency" problem

José Rafael Subía Valdez jsubiavaldez at gmail.com
Mon Sep 5 18:35:14 CEST 2016 

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 at 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 at 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 at 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 at 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 at 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 at lists.iem.at> on behalf of José
>>>>> Rafael Subía Valdez <jsubiavaldez at 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
>>>>> 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 ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pd-list at lists.iem.at mailing list
>>>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>>>> stinfo/pd-list
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> José Rafael Subía Valdez
>>>> www.jrsv.net
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>>> stinfo/pd-list
>>>>
>>>>
>>>
>>
>>
>> --
>> José Rafael Subía Valdez
>> www.jrsv.net
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160905/04a28f5c/attachment-0001.html>

More information about the Pd-list mailing list