To Pd list,
Joe Deken and Jaime Oliver and I are interested in setting up a round table discussion to consider possible future developments for Pd vanilla. I have a lengthy list of ideas and I'm sure many of you have ideas as well. To prepare for this, it would be helpful to collect some of them in advance. If you have a direction you'd like to see Pd development go in, please feel free to suggest it in a followup e-mail to this one.
NOTE: this might generate a hurricane of discussion threads - in order to make it possible for Joe to collect ideas (as he has offered to do) please keep the tag "pdconv16_r" in the subject line. Better yet, add your own phrase to the subject line to disambiguate it. Also please send a copy of your post here for efficient compilation: pdcon_round@newblankets.org
cheers Miller
Joe Deken and Jaime Oliver and I are interested in setting up a round table discussion to consider possible future developments for Pd vanilla. I have a lengthy list of ideas and I'm sure many of you have ideas as well. To prepare for this, it would be helpful to collect some of them in advance. If you have a direction you'd like to see Pd development go in, please feel free to suggest it in a followup e-mail to this one.
Oh boy, I have a bunch bunch of ideas that are kinda sorta related to each other sorta not. Here we go!:
DEKEN: - I think library management is important to the future of Pd and I'd like to discuss idea of how to improve it. I basically think the current idea needs a bit more meat on its bones to truly be helpful and integral to the Pd experience. I'd like to discussion what sorts of metadata would be helpful to have, how updates to libraries can be handled (esp with previous versions on a user's computer), if perhaps it could handle package manifests ala Node.js so that projects are easier to distribute (which also brings up the issue of local project install vs global install)
CORE OBJECTS: - I'd like to discuss if the core objects included with Pd Vanilla should be expanded and what they should be expanded with. I like the modularity of Pd (this aspect being reinforced by Deken), but I also think maybe including objects to increase the functionality to Pd could be added. Things such as additional GUI objects, multidimensional arrays, more powerful sequencing tools, global transport like functions, hash tables, etc.
WEBSITE: - I'd like to discuss the future of the website (not totally related to Pd Vanilla, but important to the Pd world as a whole). I think the Pd community lacks a good solid go-to resource on the web that's up to date. Puredata.info has been a great resources, but I'm not sure that the wiki format lends itself to simplicity and clarity, esp for Pd newbies. It also hasn't been the best at being up-to-date (I mean, there's still mentions of Pd-extended in several places) and it would stand a better chance of being more up to date if more people in the community could freely contribute to its upkeep. I also think that a centralized Pd website could potentially become a great showcase of what people have done with Pd and a resource for abstractions and example code and although that can be done with member pages, I don't think member pages are the best way to get this info across (although I'm not opposed to member pages, I have one!)
COMMUNITY INVOLVEMENT: - I'm not sure if it's just me finally working on Pd community projects like Cyclone and writing on the list, but I have a feeling that the community has been grown and become more active and eager to be involved in the development and improvement of Pd and Pd-related projects and I'd like to explore perhaps if somehow more people could be involved in Pd Vanilla development, how that could be achieved, and how it can be made sure that development is focused and doesn't stray from a central idea of what Pd Vanilla should be.
Looking forward to some fruitful discussion!
Derek
================== Derek Kwan www.derekxkwan.com
On 29-10-16 13:04, Derek Kwan wrote:
DEKEN: - I think library management is important to the future of Pd and I'd like to discuss idea of how to improve it. I basically think the current idea needs a bit more meat on its bones to truly be helpful and integral to the Pd experience. I'd like to discussion what sorts of metadata would be helpful to have, how updates to libraries can be handled (esp with previous versions on a user's computer), if perhaps it could handle package manifests ala Node.js so that projects are easier to distribute (which also brings up the issue of local project install vs global install)
It would help the discussion if there was an inventory of actual problems the metadata would solve. There was a discussion about this on the Github deken-list, which (probably) went nowhere because of this.
With the current update policy of Pd-vanilla (add new functionality without breaking the existing one), not much issues arise between the core and externals. The best strategy for building externals is to anticipate differences in vanilla versions, implement workarounds if possible or fail gracefully if needed.
A version number would be a good idea, but how many external-packages depend on other entities than Pd-vanilla? Having more information available before downloading would be nice, and this could already be implemented as an extended deken-plugin.
Debian packages also have dependencies listed, but that is quite a different scale of complexity.
Without some actual problems, it will be hard to devise a solution to solve them.
Looking forward to some fruitful discussion!
Started already :-)
Derek
Greetings,
Fred Jan
================== Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
It would help the discussion if there was an inventory of actual problems the metadata would solve. There was a discussion about this on the Github deken-list, which (probably) went nowhere because of this.
This metadata would potentially solve issues with updates (I'll discuss this later) and just general ease-of-use. Deken as it is right now, you pretty much have to know the name of the library you want to install, and what it does/what it contains. As a new user, I'd find that pretty daunting. I don't know what external libraries are there for Pd, I don't know what any of them do, I don't know when they were last updated so I don't know how old these libraries are. Even as an experienced user, maybe I'll forget which libraries have sample-length delays, or bandlimited oscillators or limiters (you don't need to tell me this, I already know =P)
At least with pd-extended, everything was just there and you could dig through the Pd browser. In a post-extended world, we're just throwing users into the deep end and hoping for the best. At least in my experience, I've seen a lot of people asking how to install x library or wondering what library they can download for some certain functionality, and a lot of people just resorting to pd-extended because it's easier. I think as contributing members to the Pd community, it's our job (or at least it'd be nice) to make things easier for newcomers. Heck, even in the pd-extended era, it was kinda hard to tell what all the libraries did and what object classes they had just from the sheer scale of it all.
Taking a page from Processing, the Contribution Manager has a filter search where you can look up keywords, the version number, a short description of what the library does, and the author. Additionally, you can install, update, and also remove from the same window. Like if I type in "audio" into the filter, the list that used to display all the libraries is just displaying Beads, Loom, and Minim. There's also a dropdown menu to sort by category, such as Animation, GUI, Hardware, etc.
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
With the current update policy of Pd-vanilla (add new functionality without breaking the existing one), not much issues arise between the core and externals. The best strategy for building externals is to anticipate differences in vanilla versions, implement workarounds if possible or fail gracefully if needed.
I suppose I'm more concerned about updates to external libraries so it migth be a little off-topic =). But here's a case, say I have library x v 2.0 and it's buggy as heck and a v3.0 happens to get uploaded. One nice thing would be to have Deken tell me about that (esp if I have something like 20 libraries installed on my computer, it gets kinda hard to keep track of it all) but perhaps more importantly and realistically, I'd like to be able to download the update without having to mess with the current installation and not have to worry about duplicates. I'm just trying to think of smarter library management in a post-extended world and I suppose I'm thinking of pd-l2ork too and how to go about if one library gets updated inbetween pd-l2ork versions, but this also applies to using Pd Vanilla as well.
A version number would be a good idea, but how many external-packages depend on other entities than Pd-vanilla? Having more information available before downloading would be nice, and this could already be implemented as an extended deken-plugin.
Debian packages also have dependencies listed, but that is quite a different scale of complexity.
Without some actual problems, it will be hard to devise a solution to solve them.
Here's a case: Say I have this piece that requires library1, library2,... up to libraryn that are all avaliable compiled for various platforms on deken. I'm on linux and I want to share this piece with a group of people who are on MacOS, Windows, Raspberry Pi's, etc. What's the best way to go about this? Potentially I can just include the binaries for every single platform and have one thing I can ship out, I can on my own make platform independent distributions and make those available, or potentially a third option (my proposed idea), have a package manifest with a list of the libraries and their build versions, and have deken handle the versioning and platform-specific binaries by handing the package manifest over to deken like how you can use a package.json file in a node.js project to contact a central repository and download everything with their proper versions via npm install. Especially if these patches with library dependencies I want to distribute are didactic material, I want it to be as easy and painless as possible, almost as easy as downloading pd-extended in the past.
For the local vs global install issue , maybe this piece requires library3 v2.0 and doesn't work with the current library3 v3.0 because something broke. I want to be able to use library3 v2.0 with this piece but I don't want to screw up my Pd install and have both versions in my general Pd searchpaths (there would also be potential nameclashes with the the old and new objects but ignoring that for now... =P). Also maybe I use the majority of the libraries with only this one piece only so I don't want globally install these libraries.
Sorry if none of this made sense, a bit sleep-deprived and it's late =) I think my updates argument was the weakest one and I'll have to think about that more... And I suppose this discussion kinda is tangentially related to pd-vanilla development, but Deken is a part of the Pd Vanilla distribution now and I think library management in a post-extended world is a worthwhile topic.
Deken as it is right now, you pretty much have to know the name of the library you want to install, and what it does/what it contains. As a new user, I'd find that pretty daunting.
very good point!
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
that would make a lot of sense. maybe this info could then be synced with https://puredata.info/downloads/by-category/library so there would also be an up-to-date online ressource (without the need of running Pd)?
Gesendet: Montag, 31. Oktober 2016 um 13:11 Uhr Von: "Derek Kwan" derek.x.kwan@gmail.com An: "Fred Jan Kraan" fjkraan@xs4all.nl Cc: pd-list@lists.iem.at Betreff: Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
It would help the discussion if there was an inventory of actual problems the metadata would solve. There was a discussion about this on the Github deken-list, which (probably) went nowhere because of this.
This metadata would potentially solve issues with updates (I'll discuss this later) and just general ease-of-use. Deken as it is right now, you pretty much have to know the name of the library you want to install, and what it does/what it contains. As a new user, I'd find that pretty daunting. I don't know what external libraries are there for Pd, I don't know what any of them do, I don't know when they were last updated so I don't know how old these libraries are. Even as an experienced user, maybe I'll forget which libraries have sample-length delays, or bandlimited oscillators or limiters (you don't need to tell me this, I already know =P)
At least with pd-extended, everything was just there and you could dig through the Pd browser. In a post-extended world, we're just throwing users into the deep end and hoping for the best. At least in my experience, I've seen a lot of people asking how to install x library or wondering what library they can download for some certain functionality, and a lot of people just resorting to pd-extended because it's easier. I think as contributing members to the Pd community, it's our job (or at least it'd be nice) to make things easier for newcomers. Heck, even in the pd-extended era, it was kinda hard to tell what all the libraries did and what object classes they had just from the sheer scale of it all.
Taking a page from Processing, the Contribution Manager has a filter search where you can look up keywords, the version number, a short description of what the library does, and the author. Additionally, you can install, update, and also remove from the same window. Like if I type in "audio" into the filter, the list that used to display all the libraries is just displaying Beads, Loom, and Minim. There's also a dropdown menu to sort by category, such as Animation, GUI, Hardware, etc.
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
With the current update policy of Pd-vanilla (add new functionality without breaking the existing one), not much issues arise between the core and externals. The best strategy for building externals is to anticipate differences in vanilla versions, implement workarounds if possible or fail gracefully if needed.
I suppose I'm more concerned about updates to external libraries so it migth be a little off-topic =). But here's a case, say I have library x v 2.0 and it's buggy as heck and a v3.0 happens to get uploaded. One nice thing would be to have Deken tell me about that (esp if I have something like 20 libraries installed on my computer, it gets kinda hard to keep track of it all) but perhaps more importantly and realistically, I'd like to be able to download the update without having to mess with the current installation and not have to worry about duplicates. I'm just trying to think of smarter library management in a post-extended world and I suppose I'm thinking of pd-l2ork too and how to go about if one library gets updated inbetween pd-l2ork versions, but this also applies to using Pd Vanilla as well.
A version number would be a good idea, but how many external-packages depend on other entities than Pd-vanilla? Having more information available before downloading would be nice, and this could already be implemented as an extended deken-plugin.
Debian packages also have dependencies listed, but that is quite a different scale of complexity.
Without some actual problems, it will be hard to devise a solution to solve them.
Here's a case: Say I have this piece that requires library1, library2,... up to libraryn that are all avaliable compiled for various platforms on deken. I'm on linux and I want to share this piece with a group of people who are on MacOS, Windows, Raspberry Pi's, etc. What's the best way to go about this? Potentially I can just include the binaries for every single platform and have one thing I can ship out, I can on my own make platform independent distributions and make those available, or potentially a third option (my proposed idea), have a package manifest with a list of the libraries and their build versions, and have deken handle the versioning and platform-specific binaries by handing the package manifest over to deken like how you can use a package.json file in a node.js project to contact a central repository and download everything with their proper versions via npm install. Especially if these patches with library dependencies I want to distribute are didactic material, I want it to be as easy and painless as possible, almost as easy as downloading pd-extended in the past.
For the local vs global install issue , maybe this piece requires library3 v2.0 and doesn't work with the current library3 v3.0 because something broke. I want to be able to use library3 v2.0 with this piece but I don't want to screw up my Pd install and have both versions in my general Pd searchpaths (there would also be potential nameclashes with the the old and new objects but ignoring that for now... =P). Also maybe I use the majority of the libraries with only this one piece only so I don't want globally install these libraries.
Sorry if none of this made sense, a bit sleep-deprived and it's late =) I think my updates argument was the weakest one and I'll have to think about that more... And I suppose this discussion kinda is tangentially related to pd-vanilla development, but Deken is a part of the Pd Vanilla distribution now and I think library management in a post-extended world is a worthwhile topic.
-- Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Deken as it is right now, you pretty much have to know the name of the library you want to install, and what it does/what it contains. As a new user, I'd find that pretty daunting.
very good point!
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
that would make a lot of sense. maybe this info could then be synced with https://puredata.info/downloads/by-category/library so there would also be an up-to-date online ressource (without the need of running Pd)?
Hello,
See IOhannes's reponse to me about the -objects.txt. Also, yes, it would be good to have a centralized up-to-date resource with this information but I think it's also important that the same information or near the same information is available within Pd as well. Having to open a web-browser and dig around the internet for the information (which admittedly would be easier with an up-to-date centralized resource) just adds extra steps to the process when it's so much more convenient and intuitive to not have to leave Pd and get the information you want and download the library with just a few clicks or so.
On 2016-10-31 13:11, Derek Kwan wrote:
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
oh, you mean something like the "-objects.txt" file that you can upload alongside your deken package? https://github.com/pure-data/deken/issues/133
fgamsdr IOhannes
On 2016-10-31 13:11, Derek Kwan wrote:
Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description.
oh, you mean something like the "-objects.txt" file that you can upload alongside your deken package? https://github.com/pure-data/deken/issues/133
fgamsdr IOhannes
Yeah, something like that =). But also more info about the external library as a whole (description, etc.) that's also viewable within the plugin itself. I can search for something and come up with a big list of libraries, but as an end-user I can't be certain what I've actually found with libraryx-v0.2.0 and there isn't info that tells me why I should download libraryx over libraryz that's also in the same list of results and I can't see the -objects.txt from the plugin so I can't tell how closely libraryx fits what I actually am looking for (although this might be mitigated with a library description so I wouldn't actually need to see the whole -objects.txt within the plugin window or some sort of popup).
How can Pure Data's capabilities for dealing with different data sets be extended? Does it make sense to adopt concepts from scripted languages to the dataflow paradigm? Examples: tuples, dictionaries, multi-dimensional arrays, [...]
PROPOSAL: Syntax for nesting lists so that lists can be organized in a hierarchical manner and sublists (as opposed to only atoms) can be access with dollargs.
Reserved symbol atoms '{' and '}' could be used to enclose sublists (Since those characters are forbidden now, introduction wouldn't break anything).
An example nested list containing two sublists:
'list { a b c } { 1 2 3 }'
The third element of the the first list would be accessed like this:
[list $1( <- returns 'list a b c' | [list $3( <- returns 'symbol c'
Dollargs would strip the encompassing curly braces and return only the content of the specified sublist:
[list $2( <- returns 'list 1 2 3'
To extract the second sublist without losing its encapsulation, one would use:
[list { $2 }( <- returns 'list { 1 2 3 }'
The same syntax can be used for dollargs used in arguments. This allows to pass a whole list or even a list of lists through a single dollarg:
[myabstraction { animal mammal cat }]
and inside this abstraction, we have:
[oscformat $1 miau] <- instantiates [oscformat animal mammal cat miau]
Whether to use curly braces or something different as list markup and whether to separate markup symbols with spaces or not is to be discussed. Also, the feasibility to implement the proposed idea would be an important discussion point, since the proposer only considered a user point-of-view.
Hey all
After watching "Future Pd Developments" round-table (thanks to everyone involved for the effort to record/put online), I feel like poking some more into the structured list idea. Some of the conclusions that came up:
* Something like [list args] as a way to get all given arguments as a list would be utterly helpful.
* Many data structures like nested lists or hashes can actually be implemented without changing the core of Pd.
I agree and I'm totally looking forward to a [list args]. Now, here comes the thing. Let's say I want to make a wrapper abstraction around [oscformat] and my wrapper abstraction takes an arbitrary number of arguments. What I'm looking for is a way to define which part of the argument list is part of an OSC address and should be passed as arguments to [oscformat] and which part should be used to set some defaults in my wrapper abstraction.
Example:
[myOSCmodule { dog cat food } { foo 123 }]
inside this:
[oscformat $1] <- would be instantiated as [oscformat dog cat food]
[loadbang] | [list append $2] <- would return 'list foo 123'
As far as I can see it, it is currently impossible to pass a variable number of arguments to child objects and also [list args] wouldn't address that. The simplest case of passing all arguments to a child object could be covered with something like a '$@', but really cool would be a way to define which arguments specifically should be passed to child objects. That's why I came up with the idea of nesting lists. Actually, I'm interested in a more sophisticated mechanism for argument inheritance.
Comments?
Roman
On Mon, 2016-10-31 at 13:53 +0100, Roman Haefeli wrote:
How can Pure Data's capabilities for dealing with different data sets be extended? Does it make sense to adopt concepts from scripted languages to the dataflow paradigm? Examples: tuples, dictionaries, multi-dimensional arrays, [...]
PROPOSAL: Syntax for nesting lists so that lists can be organized in a hierarchical manner and sublists (as opposed to only atoms) can be access with dollargs.
Reserved symbol atoms '{' and '}' could be used to enclose sublists (Since those characters are forbidden now, introduction wouldn't break anything).
An example nested list containing two sublists:
'list { a b c } { 1 2 3 }'
The third element of the the first list would be accessed like this:
[list $1( <- returns 'list a b c'
[list $3( <- returns 'symbol c'
Dollargs would strip the encompassing curly braces and return only the content of the specified sublist:
[list $2( <- returns 'list 1 2 3'
To extract the second sublist without losing its encapsulation, one would use:
[list { $2 }( <- returns 'list { 1 2 3 }'
The same syntax can be used for dollargs used in arguments. This allows to pass a whole list or even a list of lists through a single dollarg:
[myabstraction { animal mammal cat }]
and inside this abstraction, we have:
[oscformat $1 miau] <- instantiates [oscformat animal mammal cat miau]
Whether to use curly braces or something different as list markup and whether to separate markup symbols with spaces or not is to be discussed. Also, the feasibility to implement the proposed idea would be an important discussion point, since the proposer only considered a user point-of-view.
Hi Roman,
On 29/11/16 05:36, Roman Haefeli wrote:
As far as I can see it, it is currently impossible to pass a variable number of arguments to child objects and also [list args] wouldn't address that.
Yes, you are right. You could do that with dynamic patching of course but I guess that answer is suboptimal for you.
Cheers,
Chris.
On Tue, 2016-11-29 at 11:56 +0800, Chris McCormick wrote:
Hi Roman,
On 29/11/16 05:36, Roman Haefeli wrote:
As far as I can see it, it is currently impossible to pass a variable number of arguments to child objects and also [list args] wouldn't address that.
Yes, you are right. You could do that with dynamic patching of course but I guess that answer is suboptimal for you.
Don't know. Dynamic patching might work, but requires a lot of effort to take care of ordering issues. Also, it might slow down loading substantially.
Roman
Hey all
After watching "Future Pd Developments" round-table (thanks to everyone
involved for the effort to record/put online), I feel like poking some more into the structured list idea. Some of the conclusions that came up:
* Something like [list args] as a way to get all given arguments as a
list would be utterly helpful.
Please don't name it that. [list] objects currently operate on incoming lists or take an incoming symbol and output it as a list. In both cases the output is generated from the data arriving at the inlet (and in the latter case at least the name tells you exactly what kind of non-list data to feed it). [list args] would instead operate on load time data associated with its parent glist. In the common case where a user creates it on a toplevel canvas, it also has the drawback of not outputting a sane default-- i.e., an outgoing "bang" doesn't give you any clue about what "args" refers to.
- Many data structures like nested lists or hashes can actually be
implemented without changing the core of Pd.
I agree and I'm totally looking forward to a [list args]. Now, here
comes the thing. Let's say I want to make a wrapper abstraction around [oscformat] and my wrapper abstraction takes an arbitrary number of arguments. What I'm looking for is a way to define which part of the argument list is part of an OSC address and should be passed as arguments to [oscformat] and which part should be used to set some defaults in my wrapper abstraction.
Example:
[myOSCmodule { dog cat food } { foo 123 }]
inside this:
[oscformat $1] <- would be instantiated as [oscformat dog cat food]
[loadbang] | [list append $2] <- would return 'list foo 123'
As far as I can see it, it is currently impossible to pass a variable
number of arguments to child objects and also [list args] wouldn't address that. The simplest case of passing all arguments to a child object could be covered with something like a '$@', but really cool would be a way to define which arguments specifically should be passed to child objects. That's why I came up with the idea of nesting lists. Actually, I'm interested in a more sophisticated mechanism for argument inheritance.
Comments?
There is this comment from the "$@" thread on the patch tracker:https://sourceforge.net/p/pure-data/patches/92/
"i think that $@ is what is necessary to allow abstractions to do what they want with args, and that $# is not so useful in comparison, and what would be more useful than $# (in the sense of avoiding more detours) would be to be able to do a $@-like thing that only starts at the Nth argument, e.g. if I have an abstraction that takes $1 $2 $3 and then a variable number of arguments, and those arguments starting with $4 are to be all written directly in an objectbox. witness the strange stuff going on in [nqpoly]..." Something like $@-4 would fulfill your case... General comment:Didn't we talk about abusing the comma atom for situations like this? So[myOSCabstraction selector1 foo bar, selector2 bing bang, selector3 something else] Then inside of that [loadbang]|[myArgParser selector2] <-- get the "selector2" part of the args |[list prepend set]|[list trim]|[oscformat] The benefit is that "selector2" is an arbitrary symbol in your own language that tells you and other users something about its data. $2, or even $@-2, only tells you where it came from, which is incidental and not as meaningful. I.e., compare: [unpack 0 0 0 0 0]|[$2 $1 $3 $4 $5]|[s voice3] to
[get note a d s r pitch]|[pack 0 0 0 0 0]| [s voice3] -Jonathan
Roman
On Mon, 2016-10-31 at 13:53 +0100, Roman Haefeli wrote:
How can Pure Data's capabilities for dealing with different data sets be extended? Does it make sense to adopt concepts from scripted languages to the dataflow paradigm? Examples: tuples, dictionaries, multi-dimensional arrays, [...]
PROPOSAL: Syntax for nesting lists so that lists can be organized in a hierarchical manner and sublists (as opposed to only atoms) can be access with dollargs.
Reserved symbol atoms '{' and '}' could be used to enclose sublists (Since those characters are forbidden now, introduction wouldn't break anything).
An example nested list containing two sublists:
'list { a b c } { 1 2 3 }'
The third element of the the first list would be accessed like this:
[list $1( <- returns 'list a b c'
[list $3( <- returns 'symbol c'
Dollargs would strip the encompassing curly braces and return only the content of the specified sublist:
[list $2( <- returns 'list 1 2 3'
To extract the second sublist without losing its encapsulation, one would use:
[list { $2 }( <- returns 'list { 1 2 3 }'
The same syntax can be used for dollargs used in arguments. This allows to pass a whole list or even a list of lists through a single dollarg:
[myabstraction { animal mammal cat }]
and inside this abstraction, we have:
[oscformat $1 miau] <- instantiates [oscformat animal mammal cat miau]
Whether to use curly braces or something different as list markup and whether to separate markup symbols with spaces or not is to be discussed. Also, the feasibility to implement the proposed idea would be an important discussion point, since the proposer only considered a user point-of-view.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2016-11-30 at 21:58 +0000, Jonathan Wilkes wrote:
Hey all
After watching "Future Pd Developments" round-table (thanks to
everyone involved for the effort to record/put online), I feel like poking some more into the structured list idea. Some of the conclusions that came up:
* Something like [list args] as a way to get all given arguments
as a list would be utterly helpful.
Please don't name it that. [list] objects currently operate on incoming lists or take an incoming symbol and output it as a list. In both cases the output is generated from the data arriving at the inlet (and in the latter case at least the name tells you exactly what kind of non-list data to feed it).
[list args] would instead operate on load time data associated with its parent glist. In the common case where a user creates it on a toplevel canvas, it also has the drawback of not outputting a sane default-- i.e., an outgoing "bang" doesn't give you any clue about what "args" refers to.
It was not my choice, but I find your points plausible.
General comment: Didn't we talk about abusing the comma atom for situations like this?
So [myOSCabstraction selector1 foo bar, selector2 bing bang, selector3 something else]
Then inside of that
[loadbang] | [myArgParser selector2] <-- get the "selector2" part of the args | [list prepend set] | [list trim] | [oscformat]
The benefit is that "selector2" is an arbitrary symbol in your own language that tells you and other users something about its data. $2, or even $@- 2, only tells you where it came from, which is incidental and not as meaningful. I.e., compare:
[unpack 0 0 0 0 0] | [$2 $1 $3 $4 $5] | [s voice3]
to
[get note a d s r pitch] | [pack 0 0 0 0 0] | [s voice3]
Oh, I like that!
Roman