why havent i seen more usage of tables as patch storage? save contents automatically loads last saved value, easy to load file into. perfect patch memory or any kind of memory for that matter.
I wish this could be applied to sequential patch playing.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Charles Goyard Sent: Monday, March 26, 2012 6:21 AM To: pd-list@iem.at Subject: Re: [PD] [pd] tables as patch storage
Hi,
Billy Stiltner wrote:
why havent i seen more usage of tables as patch storage?
Maybe because you can only store numbers, not strings.
A textfile seems more versatile.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote:
Hi,
Billy Stiltner wrote:
why havent i seen more usage of tables as patch storage?
Maybe because you can only store numbers, not strings.
A textfile seems more versatile.
Or a message box. Miller's help-files are crammed full with message boxes used as patch storage. Patch-level storga it nice for toplevel patches, but often not really useful in abstractions, when each abstraction instance needs a different state, although they all share the same patch file.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Le 2012-03-27 à 12:50:00, Frank Barknecht a écrit :
On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote:
Billy Stiltner wrote:
why havent i seen more usage of tables as patch storage?
Maybe because you can only store numbers, not strings. A textfile seems more versatile.
Or a message box. Miller's help-files are crammed full with message boxes used as patch storage. Patch-level storga it nice for toplevel patches, but often not really useful in abstractions, when each abstraction instance needs a different state, although they all share the same patch file.
[textfile] fakes being a filehandle or linked-list in the way it has a sequential interface instead of a random-access interface, even though it's really stored in RAM as a binbuf.
arrays ([table]) don't have that limitation, but have other limitations. This creates unnecessary decisions in Pd, as people have to pick between free-form anythings that have to be iterated through, or direct access to items that have to be floats, and they can't have both advantages at once.
(Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Frank Barknecht fbar@footils.org Cc: pd-list@iem.at Sent: Tuesday, March 27, 2012 9:45 AM Subject: Re: [PD] [pd] tables as patch storage
Le 2012-03-27 à 12:50:00, Frank Barknecht a écrit :
On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote:
Billy Stiltner wrote:
why havent i seen more usage of tables as patch storage?
Maybe because you can only store numbers, not strings. A textfile seems more versatile.
Or a message box. Miller's help-files are crammed full with message
boxes used as patch storage. Patch-level storga it nice for toplevel patches, but often not really useful in abstractions, when each abstraction instance needs a different state, although they all share the same patch file.
[textfile] fakes being a filehandle or linked-list in the way it has a sequential interface instead of a random-access interface, even though it's really stored in RAM as a binbuf.
arrays ([table]) don't have that limitation, but have other limitations. This creates unnecessary decisions in Pd, as people have to pick between free-form anythings that have to be iterated through, or direct access to items that have to be floats, and they can't have both advantages at once.
Anythings aren't really free-form, either. "float my boat" isn't a valid message in Pd. But even if you're reading a Pd file with [textfile]-- which as far as I know doesn't ever start with the word "float"-- you're limited in what you can do with it if you use the vanilla objects. The obvious choice to filter messages, [route], will choke on data structure definitions like [struct foo float bar] and give you an error if you happen to [route foo].
(Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit :
Anythings aren't really free-form, either. "float my boat" isn't a valid message in Pd.
I mean as free-form as storable Anythings can be. I not talking about atoms that are not storable, nor about non-atoms, pink elephants and winged pigs.
But even if you're reading a Pd file with [textfile]-- which as far as I know doesn't ever start with the word "float"--
selector float can always be implied, so it needs not be written. This is because of what binbuf_eval does.
(Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine, rather than being designed in a pragmatic way. There's not enough basic functionality in the language, to be able to make abstractions that are both simple enough and fast enough.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Tue, Mar 27, 2012 at 11:21:15AM -0400, Mathieu Bouchard wrote:
list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine, rather than being designed in a pragmatic way.
Actually I consider list-abs to be very pragmatic *because* it only uses builtins. This makes it highly portable and trivial to use everywhere, even without installing it globally.
If you treat list-abs as an interface or API, it also is very easy to optimize the objects by using externals inside of the list-abs-abstractions without having to change the surrounding patches.
I already sketched this approach four years ago: http://lists.puredata.info/pipermail/pd-list/2008-12/066571.html
Ciao
Frank
Le 2012-03-27 à 17:45:00, Frank Barknecht a écrit :
Actually I consider list-abs to be very pragmatic *because* it only uses builtins.
I just mean that Pd's builtins are too deficient to make your approach worth it. Miller has another fifteen years to spare to figure out what will be the five next [list] builtins.
But lists in pd aren't as inefficient as pd-list.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Cc: Sent: Tuesday, March 27, 2012 11:45 AM Subject: [PD] list-abs and externals [was: Re: [pd] tables as patch storage]
On Tue, Mar 27, 2012 at 11:21:15AM -0400, Mathieu Bouchard wrote:
list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine, rather than being designed in a pragmatic way.
Actually I consider list-abs to be very pragmatic *because* it only uses builtins. This makes it highly portable and trivial to use everywhere, even without installing it globally.
If you treat list-abs as an interface or API, it also is very easy to optimize the objects by using externals inside of the list-abs-abstractions without having to change the surrounding patches.
There's actually a much bigger potential benefit to using abstractions to build a common interface, which is that _anyone_ in the community can build the interface, and the guts (which may very well be filled with externals) can get replaced later as the internal objects necessary to support them get added to core Pd.
For example, I could make a symbol manipulation library, similar to all the subcommands of the tcl [string] command, and fill the guts either with externals or a crazy symbol-splitting hack using only vanilla objects (so that vanilla users can at least try out the interface). Then the interface could get commented upon, tweaked, and changed (maybe using a different model than tcl) until it looks very good, and during this process, or at any point in the future when Pd's symbol stuff gets improved one can just change the guts of the interface to improve the performance/usefulness of the library.
But I find it interesting that you only imagine the guts of list-abs getting replaced with externals in order to improve the performance, and not with new core objects. I think this is because the process of getting stuff included in core Pd is so badly broken that it's not even worth mentioning-- unfortunate since the abstraction interface-building I describe would be a really nice development model.
-Jonathan
I already sketched this approach four years ago: http://lists.puredata.info/pipermail/pd-list/2008-12/066571.html
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On Tue, Mar 27, 2012 at 12:11:10PM -0700, Jonathan Wilkes wrote:
But I find it interesting that you only imagine the guts of list-abs getting replaced with externals in order to improve the performance, and not with new core objects.Â
Oh, but I can imagine it and it has already happened: list-len.pd was counting the output of [list-drip] before [list length] was introduced, which is now the sole object inside of list-len.pd
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
----- Original Message -----
From: Frank Barknecht fbar@footils.org To: pd-list@iem.at Cc: Sent: Friday, March 30, 2012 3:58 AM Subject: Re: [PD] list-abs and externals [was: Re: [pd] tables as patch storage]
Hi,
On Tue, Mar 27, 2012 at 12:11:10PM -0700, Jonathan Wilkes wrote:
But I find it interesting that you only imagine the guts of list-abs
getting replaced
with externals in order to improve the performance, and not with new core
objects.
Oh, but I can imagine it and it has already happened: list-len.pd was counting the output of [list-drip] before [list length] was introduced, which is now the sole object inside of list-len.pd
But it's not significant enough to hold up as a virtue of your approach. The user benefits from your approach because they can have your consistent interface in all their patches, and if they run into a place where the poor performance of the abstraction becomes a problem, they can replace the guts with an external-- whether it's one already available in someone else's library or one they write themselves.
Another model is to use your library for a consistent patching interface, and when the user runs into a performance issue, he/she can decide whether a solution that replaces part of the abstraction with a compiled object class is a) idiosyncratic to their particular use case and belongs in an external library or b) generally useful and belongs in the set of classes that are common to _every_ pd implementation.*
I can tell you after going through the bulk of externals out there and documenting them that lots of Pd developers are creating generally useful list manipulation classes. An internal class that does [list-drip], for example, is necessary for just about any fast, expressive list processing in Pd vanilla. But it's not there after a very long time, and the evidence on the patch tracker is that it's a waste of time for devs to even add new functionality there, so that's why I say that part of the dev model is broken.
-Jonathan
- there's also c) writing a ridiculously complicated hack to get a big performance boost,
like the current [list-drip], but for obvious reasons this shouldn't be the dominant model.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2012-03-27 at 11:21 -0400, Mathieu Bouchard wrote:
Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit :
Anythings aren't really free-form, either. "float my boat" isn't a valid message in Pd.
I mean as free-form as storable Anythings can be. I not talking about atoms that are not storable, nor about non-atoms, pink elephants and winged pigs.
But even if you're reading a Pd file with [textfile]-- which as far as I know doesn't ever start with the word "float"--
selector float can always be implied, so it needs not be written. This is because of what binbuf_eval does.
(Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine
I can only speak for myself (your opinion obviously differs), but I actually find the list-abs library pretty useful. Though, I am sometimes not using it directly, but copy&pasting stuff from it to my patches. And sometimes I really use it as a library. I find the goal of it being only vanilla rather a pragmatic than an academic one.
I also expect Frank not to have made it only for academia's sake.
Roman
On 27 Mar 2012, at 18:41, Roman Haefeli wrote:
I can only speak for myself (your opinion obviously differs), but I actually find the list-abs library pretty useful. Though, I am sometimes not using it directly, but copy&pasting stuff from it to my patches. And sometimes I really use it as a library. I find the goal of it being only vanilla rather a pragmatic than an academic one.
I also expect Frank not to have made it only for academia's sake.
I also find it useful especially for "pure Pd" projects.
However, I would add that had it been developed for academic reasons only, this wouldn't necessarily be a bad thing. [list-abs] is a gold mine of Pd patching techniques and there's a lot to learn from it even if you don't use it.
It's like a pragmatic API, with a very informative implementation!
best,
Jamie
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Frank Barknecht fbar@footils.org; "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, March 27, 2012 11:21 AM Subject: Re: [PD] [pd] tables as patch storage
Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit :
Anythings aren't really free-form, either. "float my boat"
isn't a valid message in Pd.
I mean as free-form as storable Anythings can be. I not talking about atoms that are not storable, nor about non-atoms, pink elephants and winged pigs.
But even if you're reading a Pd file with [textfile]-- which as far as
I know doesn't ever start with the word "float"--
selector float can always be implied, so it needs not be written. This is because of what binbuf_eval does.
Right but you can't help it being written in a Pd file, and thus the tools Pd vanilla gives you to read/write/parse a textfile-- the [textfile] object and [route]-- cannot even be used to parse the software's own file format. You have to either use list-abs [sroute] or build your own workaround to avoid the "bad argument" error with impunity.
(Of course, there are externals, but they're not the kind of thing
used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
list-abs was designed to only use pd's builtins, no externs, which makes it more like academic exercises of proving that anything can be done with a Turing tape machine, rather than being designed in a pragmatic way. There's not enough basic functionality in the language, to be able to make abstractions that are both simple enough and fast enough.
Well, yes, that's obviously true just by the fact that there isn't a (sensible) way to get an abstraction's arguments using the core objects.
Question is: what needs to be added to make abstraction use simpler and faster? I found that the "get" method I added to canvas opened a lot of doors, even providing a quick way to get better locality in Pd (and the coding only took about 30 mins for that). I'm sure there's a lot more that I'm missing, though.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't.
Ciao
Frank
Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit :
On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't.
Well, by calling it « teasing » you're avoiding the point of my remark, which is essentially ignoring it. I think that you're deliberately jumping to the wrong conclusions about my mail, too.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Tue, Mar 27, 2012 at 11:38:13AM -0400, Mathieu Bouchard wrote:
Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit :
On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't.
Well, by calling it « teasing » you're avoiding the point of my remark, which is essentially ignoring it. I think that you're deliberately jumping to the wrong conclusions about my mail, too.
I have 6 minutes left on my battery and won't leave the warm garden sun to jump to other conclusions.
Ciao
Frank
I haven't been on this list for a long time. The first thing I see is the same old crank acting like a crabby sour puss.
Par for the course. I think that kind of negativity spoils a lot of productivity. Maybe you could work on social skills and how to not come off as a jerk so much?
Peace and Love,
~Kyle
On Tue, Mar 27, 2012 at 10:38 AM, Mathieu Bouchard matju@artengine.ca wrote:
Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit :
On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote:
From: Mathieu Bouchard matju@artengine.ca (Of course, there are externals, but they're not the kind of thing used by the kind of people who come up with list-abs.)
I don't know what that means. What does that mean?
Matju is teasing me as maintainer of list-abs as a vanilla-based library, deliberatly jumping to the wrong conclusion I would despise externals. But I ignored the remark. Or actually now I didn't.
Well, by calling it « teasing » you're avoiding the point of my remark, which is essentially ignoring it. I think that you're deliberately jumping to the wrong conclusions about my mail, too.
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
so there are 3 builti ways to do some sort of patch storage - msgbox, table, and txtfile. the only one I have used so far is table, my boogiebox is kinda like a little sequencer computer model built with puredata's components.
http://www.geocities.ws/billy_stiltner/music/pd/
On Mon, Apr 2, 2012 at 7:30 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
turing tape machine, haha
On Thu, Jun 14, 2012 at 11:29:10PM -0400, Billy Stiltner wrote:
so there are 3 builti ways to do some sort of patch storage - msgbox, table, and txtfile.
- "data structures" i.e. the [struct] object and relatives.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
-
Billy Stiltner -
Charles Goyard -
Frank Barknecht -
Jamie Bullock -
Jonathan Wilkes -
Kyle Klipowicz -
Mathieu Bouchard -
Pagano, Patrick -
Roman Haefeli