[PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix) + ftm

[Jonathan Wilkes]

----- 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.

> 
> Besides being interesting to add messages to data-s, it would also be very 
> productive if some easy operations could be done, that nowadays can only be 
> achieved through more intense patching around the data-s objects: choose a 
> particular scalar on a canvas by its index number like in an array (or without 
> having to detect it's values to see if it's the right one), [previous X( 
> message for [pointer], etc etc. I've sent once such a list to Mr. Puckette, 
> I think I still have it around.
> This would make data structures patching less time consuming, and maybe also 
> more approachable to newcomers. When I did my data structures workshop last 
> Pd-Con in Weimar everyone was very happy to understand it, but also not very 
> happy that to make a more complex circuit many operations are necessary. I mean, 
> if [tabread] would only take bangs instead of indexes (which is the case with 
> [struct]), how many people would be taking the trouble to use it?
> 
> 
> Another related question: I was looking at the ftm library, and it is quite 
> complete, not only for data management, but also for expressions using 
> data's variables with direct access, and also audio objects. In the 
> beginning the difference bweteen Pd and Max was that Pd had the 
> "unique" (although rudimentary) data structures (as said in 
> Puckette's Paper), but with ftm there isn't any exclusivity anymore. 
> Since ftm seems to be a much more mature concept - both in terms of features, 
> and integration with other dimensions of the environment -, would it make sense 
> to make a Pd port of ftm? Or maybe, even continue to develop ftm for Pd instead 
> of the current data structures?
> Afaik, IOhannes has done some work porting the ftm lib to Pd, but the work with 
> the gui is missing. Does it make more sense to try to reinvent a wheel someone 
> already did, or just get that wheel and make it better? Also afaik, ftm 
> isn't developing much anymore (I might be wrong).
> http://ftm.ircam.fr/index.php/Main_Page (including sourceforge link)
> 
> João
>