----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: João Pais jmmmpais@googlemail.com; "pd-list@iem.at" pd-list@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@googlemail.com To: "pd-list@iem.at" pd-list@iem.at;
"pd-announce@iem.at" pd-announce@iem.at; Jonathan Wilkes jancsika@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