[PD] Stuck with a "persistency" problem

Matt Barber brbrofsvl at gmail.com
Mon Sep 5 17:56:54 CEST 2016


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


More information about the Pd-list mailing list