[PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix) + ftm
Jonathan Wilkes
jancsika at yahoo.com
Mon Mar 26 18:25:15 CEST 2012
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: João Pais <jmmmpais at googlemail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Monday, March 26, 2012 11:36 AM
> Subject: Re: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix) + ftm
>
>
> On Mar 26, 2012, at 11:15 AM, Jonathan Wilkes wrote:
>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: João Pais <jmmmpais at googlemail.com>
>>> To: "pd-list at iem.at" <pd-list at iem.at>;
> "pd-announce at iem.at" <pd-announce at iem.at>; Jonathan Wilkes
> <jancsika at yahoo.com>
>>> Cc:
>>> Sent: Monday, March 26, 2012 5:05 AM
>>> Subject: Re: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug
> fix) + ftm
>>>
>>>> One approach is to make a public API for the process you're
> already
>>> using for
>>>> the "Put" menu array and [table] objects. Users
> don't have
>>> to care (or even
>>>> be aware of) the loading of the templates for _float and
> _float_array which
>>> is
>>>> a good thing. There should be a way to make your own library using
> only Pd
>>>> patches, and have pd look for libname_setup.pd (or some such naming
>>>> scheme) in the path when I do [declare -lib libname], and if it
> exists load
>>> it
>>>> un-vis'd. That would allow a safe way for a library to use
> data
>>> structures
>>>> without $0-, and be able save/recall state. Plus allow all kinds
> of other
>>> things,
>>>> like a library of abstractions which all rely on a table to read--
> the
>>> table can
>>>> be in libname_setup.pd, and the user can create/destroy
> abstractions from
>>>> that library while the common table stays safe in the unvis'd
> setup
>>> patch.
>>>>
>>>> Of course there's still the problem of name clashes since
> [struct
>>> libname] is a
>>>> global variable and [table lib-whatever-table] is a global table,
> but a
>>> unique
>>>> libname shouldn't be too hard.
>>>
>>> I don't know if I understood all the consequences of what you
> wrote. Did you
>>> say to let templates with the same name "repeat" themselves,
> to allow
>>> for a better patching? Isn't it good for now that repeated
> templates do get
>>> marked as bad programming, to avoid conflicts where they aren't
> supposed to
>>> be?
>>> If all name conflicts are ignored, some more interesting patching can
> be done.
>>> If name conflicts remain, patching errors will be easier to detect. Is
> there a
>>> good solution?
>>> Or I was misreading the whole problem?
>>
>> When an external library is loaded, Pd looks for a setup routine and
> executes the
>> code there. What I'm proposing is a similar functionality for
> abstractions, so that
>> if you have a directory "fooberry" with a bunch of abstractions
> inside it, you can
>> put a patch there named something like fooberry_setup.pd, and if you try to
> load
>> the library "fooberry" Pd will find "fooberry_setup.pd"
> and load that patch un-vis'd
>> so that whatever is inside it will be available to any abstraction in that
> same
>> library. Thus if all the abstractions need to read from a table you can
> have the
>> table inside fooberry_setup.pd. Likewise if all the abstractions are
> helping to
>> manipulate/save/read a data structure, you have the [struct] inside
> fooberry.pd.
>>
>> Nothing about name conflicts needs to be changed-- there's still a
> warning if you
>> try to create another struct named that. However, it'd be nice to be
> able to name
>> a struct based on $dir + $filename-- that would avoid most name collisions.
>
>
> That is one of the ideas behind the *-meta.pd file in libdirs. That part has
> never been implemented tho. I still think it makes sense to use the meta file
> for that, rather than having another file.
Ah, ok. But that's a bit of a stretch for the term "meta", if one is accessing table
data and putting struct definitions there.
Also, how do you load libname-meta.pd only for the libdirs that want it loaded?
-Jonathan
>
> .hc
More information about the Pd-list
mailing list