Hi all -
Only Microsoft Windows users should care... but 0.43-2 is now finalized (essentialy the same as the "test1" version), which fixes the missing TK library problem on Microsoft Windows.
I think things are reasonably stable now and I can turn to some long-put-off projects. Foremost is a unification of message boxes with "textfile" functionality, and making a matching "message" type fr data structures (which will join "float", "symbol" and "array".)
Also, the pd~ object needs some more work, MIDI input is still buggy on Microsoft, and many small problems still need fixing.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: pd-announce@iem.at Cc: Sent: Sunday, March 25, 2012 1:52 PM Subject: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix)
Hi all -
Only Microsoft Windows users should care... but 0.43-2 is now finalized (essentialy the same as the "test1" version), which fixes the missing TK library problem on Microsoft Windows.
I think things are reasonably stable now and I can turn to some long-put-off projects. Foremost is a unification of message boxes with "textfile" functionality, and making a matching "message" type fr data structures (which will join "float", "symbol" and "array".)
I'm afraid whatever message type you come up with for data structures will be severely limited unless you solve the problem of locality wrt data structures. Currently, one can choose either a) a modular approach with [struct $0-name] which can be used inside abstractions, or b) state-savable [struct name] which is global and thus requires part of the user's brain power to remember _not_ to load more than one instance of the patch that contains the template.
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.
-Jonathan
Also, the pd~ object needs some more work, MIDI input is still buggy on Microsoft, and many small problems still need fixing.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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?
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
Hi João,
Or maybe, even continue to develop ftm for Pd instead of the current data
structures?
FTM is LGPL and Pd is BSD so this might be a problem for some people (in terms of replacing Pd date structures). Except for that, I think it would be great to have FTM in pd.
Also afaik, ftm isn't developing much anymore (I might be wrong).
every now and then there are bugfix releases with a couple of new features added, but I think more development time is now directed to MuBu (which I think shares a lot of code with FTM\Gabor, hence soem features developed for MuBu leak back to FTM releases)
best
Adrian
On Mon, Mar 26, 2012 at 10:05 AM, João Pais jmmmpais@googlemail.com wrote:
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?
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_Pagehttp://ftm.ircam.fr/index.php/Main_Page(including sourceforge link)
João
______________________________**_________________ Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/**listinfo/pd-announcehttp://lists.puredata.info/listinfo/pd-announce
----- 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.
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
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.
.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@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.
----- 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
On 3/25/12, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: pd-announce@iem.at Cc: Sent: Sunday, March 25, 2012 1:52 PM Subject: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix)
Hi all -
Only Microsoft Windows users should care... but 0.43-2 is now finalized (essentialy the same as the "test1" version), which fixes the missing TK library problem on Microsoft Windows.
I think things are reasonably stable now and I can turn to some long-put-off projects. Foremost is a unification of message boxes with "textfile" functionality, and making a matching "message" type fr data structures (which will join "float", "symbol" and "array".)
I'm afraid whatever message type you come up with for data structures will be severely limited unless you solve the problem of locality wrt data structures. Currently, one can choose either a) a modular approach with [struct $0-name] which can be used inside abstractions, or b) state-savable [struct name] which is global and thus requires part of the user's brain power to remember _not_ to load more than one instance of the patch that contains the template.
An idea for workaround: create your abstraction with one of each--a local $0-struct and a global-struct. When loading the patch, write the data from global-struct into $0-struct, and if you intend to save the data, write the data back into global-struct before saving the patch.
or maybe you'd need to make two abstractions--one global with one instance for saved data, and many instances of your local version. This starts to sound bad...
----- Original Message -----
From: Charles Henry czhenry@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at; "pd-announce@iem.at" pd-announce@iem.at Sent: Monday, March 26, 2012 1:46 PM Subject: Re: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug fix)
On 3/25/12, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: pd-announce@iem.at Cc: Sent: Sunday, March 25, 2012 1:52 PM Subject: [PD] [PD-announce] Pd 0.43-2 released (windows startup bug
fix)
Hi all -
Only Microsoft Windows users should care... but 0.43-2 is now finalized (essentialy the same as the "test1" version), which fixes the
missing
TK library problem on Microsoft Windows.
I think things are reasonably stable now and I can turn to some long-put-off projects. Foremost is a unification of message boxes with
"textfile"
functionality, and making a matching "message" type fr data
structures
(which will join "float", "symbol" and
"array".)
I'm afraid whatever message type you come up with for data structures
will
be severely limited unless you solve the problem of locality wrt data structures. Currently, one can choose either a) a modular approach with [struct
$0-name]
which can be used inside abstractions, or b) state-savable [struct name] which is global and thus requires part of the user's brain power to remember
_not_
to load more than one instance of the patch that contains the template.
An idea for workaround: create your abstraction with one of each--a local $0-struct and a global-struct. When loading the patch, write the data from global-struct into $0-struct, and if you intend to save the data, write the data back into global-struct before saving the patch.
or maybe you'd need to make two abstractions--one global with one instance for saved data, and many instances of your local version. This starts to sound bad...
The more I think about it, the more I think the data structure design itself is defective and is the culprit. Reading/writing data structure data should be done through an object, not by sending read/write messages to the corresponding canvas. Then you could specify the struct to the object whose function is to read/write scalar data, and it wouldn't have to save the struct name as part of the data.
-Jonathan
-
Adrian Gierakowski -
Charles Henry -
Hans-Christoph Steiner -
Jonathan Wilkes -
João Pais -
Miller Puckette