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

[Hans-Christoph Steiner]

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.

.hc



> 
>> 
>> 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
>> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther King, Jr.