[PD] Stuck with a "persistency" problem

José Rafael Subía Valdez jsubiavaldez at gmail.com
Mon Sep 5 17:38:36 CEST 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160905/dc7a1f7c/attachment.html>


More information about the Pd-list mailing list