Hi List, I'd like to try a method of getting paid for doing Pd work which I will call a "Reverse" Kickstarter". Basically I'll work on the aspects of Pd I'm currently working on through the month of May, full time, then at the beginning of June if anyone wants to pay me for the work I finish up to that point I'll do another month's work, full time, if a particular goal is reached. This way the Pd community will end up with the benefit of my work at the beginning of June at no risk/cost, and I'll do a lot of the work I would have done anyway (though devoting more time to it than I would have otherwise). I call it a "Reverse Kickstarter" for this reason-- if the work I complete in May is enough for someone to donate X amound of money, then even if I fail to produce anything of value in June the donor still got something of value for their donation. Of course I plan on continuing to develop and hopefully getting better at it as I learn, but the point is instead of trying to garner a buzz around potential development (and most Kickstarter projects fail, so its risky), I instead garner a buzz around actual development for which potential donors can reward me, use as a gauge for what my future development will be, or both.
Here's what I'm currently working on:
And some future stuff:
All of my work will hopefully follow these guidelines:
I'll look at the easiest ways to get the process rolling. I really like Paul Davis' donation "progress bar" on the Ardour website, so I might try getting something like that on my website.
Furthermore, if anyone has some general features they think are missing from Pd and want to donate specifically for them, I'd be happy to look at those too. But for May at least I'd like to try to focus on what I'm currently working on.
I still need to figure out a good target to start out with and the easiest payment system to use. So suggestions are certainly welcome about that or anything else. :)
-Jonathan
Reverse Kickstarter?
Sounds like some sinister extortion racket. We pay you money _not_ to do some really bad stuff.
Hey, how about Firestarter!? We send you money for a brick for Apple's window, or you get your dog to take a dump on their lawn.
I'm in for $20
a.
On Mon, May 13, 2013 at 02:26:13PM -0700, Jonathan Wilkes wrote:
Hi List,     I'd like to try a method of getting paid for doing Pd work which I will call a "Reverse" Kickstarter". Basically I'll work on the aspects of Pd I'm currently working on through the month of May, full time, then at the beginning of June if anyone wants to pay me for the work I finish up to that point I'll do another month's work, full time, if a particular goal is reached. This way the Pd community will end up with the benefit of my work at the beginning of June at no risk/cost, and I'll do a lot of the work I would have done anyway (though devoting more time to it than I would have otherwise).     I call it a "Reverse Kickstarter" for this reason-- if the work I complete in May is enough for someone to donate X amound of money, then even if I fail to produce anything of value in June the donor still got something of value for their donation. Of course I plan on continuing to develop and hopefully getting better at it as I learn, but the point is instead of trying to garner a buzz around potential development (and most Kickstarter projects fail, so its risky), I instead garner a buzz around actual development for which potential donors can reward me, use as a gauge for what my future development will be, or both.
Here's what I'm currently working on:
- [canvasinfo], [pdinfo], and [classinfo] objects to streamline getting information about parts of Pd that do not have xlets for messages: implemented, but does not include all pd attributes yet (like audio/midi devices)
- jump-on-click and bar graph style options for "Put" menu arrays: implemented, but I need to do more testing and make it possible to change the baseline for data structure arrays based on quanta values
- centralized "Preferences" dialog with tabs for General, Audio, Midi, GUI, and possibly some others: just started implementing it, will work on it for the next few days
- improve tooltips: show tip next to mouse location, and have separate canvas tip for stuff like pddplink to show firefox-style link address. add xlet descriptions, so you can get one or two word description of what the xlet does in addition to its method (handy for objects like [vcf~], [tabread], etc.)
- use libname-meta.pd file to find aliases for objects with a creator name that cannot be a c function name (like ">~")
And some future stuff:
- use Xapian for better search-plugin speed and functionality
- [drawimage] for data structures
- building Pd using MinGW from GNU/Linux: unless someone already has this working...
- gui-plugin to export pd patch to svg
- way to embed pd source in svg, or use <g> to group things per object
- adding a function to make it easy to parse comma-separated A_GIMME args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named args.
All of my work will hopefully follow these guidelines:
- does not break patches. Question: while all changes I'm making will let old Pd files run on revised Pd, do the files written by revised Pd have to run on old Pd?
- preference given to generally useful development. (maybe [drawimage] is an exception since few people use data structures, so I'll put that one last.)
- preference given to development that makes Pd more accessible to new users.
I'll look at the easiest ways to get the process rolling. I really like Paul Davis' donation "progress bar" on the Ardour website, so I might try getting something like that on my website.
Furthermore, if anyone has some general features they think are missing from Pd and want to donate specifically for them, I'd be happy to look at those too. But for May at least I'd like to try to focus on what I'm currently working on.
I still need to figure out a good target to start out with and the easiest payment system to use. So suggestions are certainly welcome about that or anything else. :)
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Andy Farnell padawan12@obiwannabe.co.uk
To: Jonathan Wilkes jancsika@yahoo.com Cc: pd list pd-list@iem.at Sent: Monday, May 13, 2013 5:45 PM Subject: Re: [PD] Pd Development "Reverse Kickstarter"
Reverse Kickstarter?
Sounds like some sinister extortion racket. We pay you money _not_ to do some really bad stuff.
Hehe. I think there's a South American country that did something like that wrt the rain forest, like you could invest in a fund for them _not_ to develop certain regions.
Hey, how about Firestarter!? We send you money for a brick for Apple's window,
or you get your dog to take a dump on their lawn.
I'm in for $20
Thanks!
-Jonathan
a.
On Mon, May 13, 2013 at 02:26:13PM -0700, Jonathan Wilkes wrote:
Hi List, I'd like to try a method of getting paid for doing Pd work which I will call a "Reverse" Kickstarter". Basically I'll work on the aspects of Pd I'm currently working on through the month of May, full time, then at the beginning of June if anyone wants to pay me for the work I finish up to that point I'll do another month's work, full time, if a particular goal is reached. This way the Pd community will end up with the benefit of my work at the beginning of June at no risk/cost, and I'll do a lot of the work I would have done anyway (though devoting more time to it than I would have otherwise). I call it a "Reverse Kickstarter" for this reason-- if the work I complete in May is enough for someone to donate X amound of money, then even if I fail to produce anything of value in June the donor still got something of value for their donation. Of course I plan on continuing to develop and hopefully getting better at it as I learn, but the point is instead of trying to garner a buzz around potential development (and most Kickstarter projects fail, so its risky), I instead garner a buzz around actual development for which potential donors can reward me, use as a gauge for what my future development will be, or both.
Here's what I'm currently working on:
- [canvasinfo], [pdinfo], and [classinfo] objects to streamline getting information about parts of Pd that do not have xlets for messages: implemented, but does not include all pd attributes yet (like audio/midi devices)
- jump-on-click and bar graph style options for "Put" menu arrays: implemented, but I need to do more testing and make it possible to change the baseline for data structure arrays based on quanta values
- centralized "Preferences" dialog with tabs for General, Audio, Midi, GUI, and possibly some others: just started implementing it, will work on it for the next few days
- improve tooltips: show tip next to mouse location, and have separate canvas tip for stuff like pddplink to show firefox-style link address. add xlet descriptions, so you can get one or two word description of what the xlet does in addition to its method (handy for objects like [vcf~], [tabread], etc.)
- use libname-meta.pd file to find aliases for objects with a creator name that cannot be a c function name (like ">~")
And some future stuff:
- use Xapian for better search-plugin speed and functionality
- [drawimage] for data structures
- building Pd using MinGW from GNU/Linux: unless someone already has this working...
- gui-plugin to export pd patch to svg
- way to embed pd source in svg, or use <g> to group things per object
- adding a function to make it easy to parse comma-separated A_GIMME args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named args.
All of my work will hopefully follow these guidelines:
- does not break patches. Question: while all changes I'm making will let old Pd files run on revised Pd, do the files written by revised Pd have to run on old Pd?
- preference given to generally useful development. (maybe [drawimage] is an exception since few people use data structures, so I'll put that one last.)
- preference given to development that makes Pd more accessible to new users.
I'll look at the easiest ways to get the process rolling. I really like Paul Davis' donation "progress bar" on the Ardour website, so I might try getting something like that on my website.
Furthermore, if anyone has some general features they think are missing from Pd and want to donate specifically for them, I'd be happy to look at those too. But for May at least I'd like to try to focus on what I'm currently working on.
I still need to figure out a good target to start out with and the easiest payment system to use. So suggestions are certainly welcome about that or anything else. :)
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi jonathan,
great ideas!
On 2013-05-13 23:26, Jonathan Wilkes wrote:
- adding a function to make it easy to parse comma-separated
A_GIMME args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named
personally i would go for something much simpler when using comma-args: [someobject foo 1 2 3, bar 42] would translate to something like
[preinitbang] | [bar 42( | [someobject foo 1 2 3]
with [preinitbang] being executed immediately after the instantiation of [someobject], so it's guaranteed that [someobject] is not connected to anything yet (kind of the opposite of [loadbang]). [preinitbang] is only here for illustrative purposes, and shouldn't exist.
it all boils down to sending initialization messages to an object right after it was created.
the nice thing about this is, that it doesn't require *any* changes on the object's side in order to be able to use it out of the box in *most* cases.
i've been thinking about implementing this for some time now (though i never found any time to do it)...i just wanted to through it into discussion before there are several competing uses of comma-separated A_GIMME args.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14/05/13 08:47, IOhannes m zmoelnig wrote:
On 2013-05-13 23:26, Jonathan Wilkes wrote:
- adding a function to make it easy to parse comma-separated
A_GIMME args to an object as named args.
[snip]
personally i would go for something much simpler when using comma-args:
[snip]
it all boils down to sending initialization messages to an object right after it was created.
the nice thing about this is, that it doesn't require *any* changes on the object's side in order to be able to use it out of the box in *most* cases.
Yes, I really like this syntax and having it as standard would be really very nice.
i've been thinking about implementing this for some time now (though i never found any time to do it)...i just wanted to through it into discussion before there are several competing uses of comma-separated A_GIMME args.
GridFlow has this syntax already for all its C++ classes (not sure about [#expr], actually), and maybe the [args] object in GridFlow supports it too for abstractions:
[object some arguments, message to object, another message]
However, this will conflict with:
[expr],[expr~],[fexpr~] [lexpr] (expr that can change expression on the fly; pdlua example)
I think it would be best if typed creators and A_GIMME supported it (so most classes would get this bonus feature automatically), if you need the commas explicitly as arguments then perhaps A_GIMME_MORE could be defined with the current behaviour, so fixing externals that need it (a tiny minority?) would be a 5-character change.
Claude
On 05/14/2013 10:34 AM, Claude Heiland-Allen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14/05/13 08:47, IOhannes m zmoelnig wrote:
On 2013-05-13 23:26, Jonathan Wilkes wrote:
- adding a function to make it easy to parse comma-separated
A_GIMME args to an object as named args.
[snip]
personally i would go for something much simpler when using comma-args:
[snip]
it all boils down to sending initialization messages to an object right after it was created.
the nice thing about this is, that it doesn't require *any* changes on the object's side in order to be able to use it out of the box in *most* cases.
Yes, I really like this syntax and having it as standard would be really very nice.
i've been thinking about implementing this for some time now (though i never found any time to do it)...i just wanted to through it into discussion before there are several competing uses of comma-separated A_GIMME args.
GridFlow has this syntax already for all its C++ classes (not sure about [#expr], actually), and maybe the [args] object in GridFlow supports it too for abstractions:
[object some arguments, message to object, another message]
However, this will conflict with:
[expr],[expr~],[fexpr~] [lexpr] (expr that can change expression on the fly; pdlua example)
Plus [list], [sel], and probably lots of others. Commas get sent as symbols to all those objects, so it's possible someone (like me) used that as a way to parse messages in Pd. (I don't make use of those methods anymore, but maybe other people do.)
-Jonathan
I think it would be best if typed creators and A_GIMME supported it (so most classes would get this bonus feature automatically), if you need the commas explicitly as arguments then perhaps A_GIMME_MORE could be defined with the current behaviour, so fixing externals that need it (a tiny minority?) would be a 5-character change.
Claude
http://mathr.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJRkktfAAoJEHZDo4jueIiWUZQIAJiYr+K5EfpicgJ1XHAoq0FT cXepRLWx7AvpEAJ5W2iAHpsASm/WycL4h+z/NmqCumFeUEFxoeoVxZVsf3ugRoiK gMH+VtVnJttFLEmhGRTlAsyc+uKdrU018WvHBBSlsM7P4HAiZfl7W/wyzr9sxLTx DdqIi48r7bknBoo97iyR9xUwSw3InLEl/0qaXBiFQhmcSE6+wzPuJMVp5/8fo2sL EtwUadxN/1lUja5FR1GjCyT/XMkGt+pgile5qZwuLTuFBcA+SWMY9PPgb4TZK1z+ TElJ9Dt62ZZdMy7btdtkiVPhCCNVol6fXrRVznBQiru/KVZnJ6ALgtUhNSIa7mE= =Zn/0 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/14/2013 03:47 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi jonathan,
great ideas!
On 2013-05-13 23:26, Jonathan Wilkes wrote:
- adding a function to make it easy to parse comma-separated
A_GIMME args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named
personally i would go for something much simpler when using comma-args: [someobject foo 1 2 3, bar 42] would translate to something like
[preinitbang] | [bar 42( | [someobject foo 1 2 3]
Yes, that would definitely make it a lot easier.
Two initial reactions:
broken object. But sending comma separated args would not.
such a change will simply refuse to accept any args at all.
Using your example:
the first arg of the A_GIMME against "foo", "bar", and "blah". (I assume ",bar 42" isn't part of argv.) 3) Dev already wrote that code in someobject_foo 4) Dev is lazy. 5) Dev is clever. 6) Dev accepts no args and tells users to just put a comma after the object name if they want args:
Thus: [someobject, foo 1 2 3 4, bar 42]
will be the de facto standard for setting args in the new way. (Unless it's trivial like [float].)
I think [sigmund~] would have looked like that if it used comma-separated args. Plus all the iemguis.
It's not terrible, but it's a little odd. [someobject foo 1 2 3 4, bar 42] looks to a user like [I_get_your_args "here is an arg," "here is another"] where [someobject, foo 1 2, bar 3 4] looks like [object1, object2 arg arg, object3 arg arg].
Of course I could be misunderstanding what you wrote. Maybe you mean that "foo 1 2 3 4" are the positional args, and they always come right after the object name as they do now. Either way [creatorname, method arg, method arg arg] would be a common sight.
-Jonathan
with [preinitbang] being executed immediately after the instantiation of [someobject], so it's guaranteed that [someobject] is not connected to anything yet (kind of the opposite of [loadbang]). [preinitbang] is only here for illustrative purposes, and shouldn't exist.
it all boils down to sending initialization messages to an object right after it was created.
the nice thing about this is, that it doesn't require *any* changes on the object's side in order to be able to use it out of the box in *most* cases.
i've been thinking about implementing this for some time now (though i never found any time to do it)...i just wanted to through it into discussion before there are several competing uses of comma-separated A_GIMME args.
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlGR7BAACgkQkX2Xpv6ydvTOrgCdES/Zb8By5xaHwMC9lTCsN350 SIwAoNeupdYrV4mKwfBmqFM7z+UPGfh4 =36tV -----END PGP SIGNATURE-----
Interesting idea. I agree that a non-lazy dev could just make argument strings serve the same function (and sometimes it's good to see all the args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs) catch and use mesages separated by commas? There are lots of things abstractions can't do cleanly (like have variable numbers of inlets/outlets) and perhaps it could be helpful to use after-creation messages somehow for this. (I've always been nervous about the widespread use of self-modifying patches to fill this need :)
cheers Miller
On Tue, May 14, 2013 at 12:57:07PM -0400, Jonathan Wilkes wrote:
On 05/14/2013 03:47 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi jonathan,
great ideas!
On 2013-05-13 23:26, Jonathan Wilkes wrote:
- adding a function to make it easy to parse comma-separated
A_GIMME args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named
personally i would go for something much simpler when using comma-args: [someobject foo 1 2 3, bar 42] would translate to something like
[preinitbang] | [bar 42( | [someobject foo 1 2 3]
Yes, that would definitely make it a lot easier.
Two initial reactions:
- in the current implementation, sending bad args to an object ends
in a broken object. But sending comma separated args would not.
- the law of clever laziness dictates that any external developed
after such a change will simply refuse to accept any args at all.
Using your example:
- Dev makes methods someobject_foo, someobject_bar, someobject_blah.
- Dev starts to code someobject_new and realizes he/she needs to
check the first arg of the A_GIMME against "foo", "bar", and "blah". (I assume ",bar 42" isn't part of argv.) 3) Dev already wrote that code in someobject_foo 4) Dev is lazy. 5) Dev is clever. 6) Dev accepts no args and tells users to just put a comma after the object name if they want args:
Thus: [someobject, foo 1 2 3 4, bar 42]
will be the de facto standard for setting args in the new way. (Unless it's trivial like [float].)
I think [sigmund~] would have looked like that if it used comma-separated args. Plus all the iemguis.
It's not terrible, but it's a little odd. [someobject foo 1 2 3 4, bar 42] looks to a user like [I_get_your_args "here is an arg," "here is another"] where [someobject, foo 1 2, bar 3 4] looks like [object1, object2 arg arg, object3 arg arg].
Of course I could be misunderstanding what you wrote. Maybe you mean that "foo 1 2 3 4" are the positional args, and they always come right after the object name as they do now. Either way [creatorname, method arg, method arg arg] would be a common sight.
-Jonathan
with [preinitbang] being executed immediately after the instantiation of [someobject], so it's guaranteed that [someobject] is not connected to anything yet (kind of the opposite of [loadbang]). [preinitbang] is only here for illustrative purposes, and shouldn't exist.
it all boils down to sending initialization messages to an object right after it was created.
the nice thing about this is, that it doesn't require *any* changes on the object's side in order to be able to use it out of the box in *most* cases.
i've been thinking about implementing this for some time now (though i never found any time to do it)...i just wanted to through it into discussion before there are several competing uses of comma-separated A_GIMME args.
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlGR7BAACgkQkX2Xpv6ydvTOrgCdES/Zb8By5xaHwMC9lTCsN350 SIwAoNeupdYrV4mKwfBmqFM7z+UPGfh4 =36tV -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/14/2013 02:49 PM, Miller Puckette wrote:
Interesting idea. I agree that a non-lazy dev could just make argument strings serve the same function (and sometimes it's good to see all the args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs) catch and use mesages separated by commas? There are lots of things abstractions can't do cleanly (like have variable numbers of inlets/outlets) and perhaps it could be helpful to use after-creation messages somehow for this. (I've always been nervous about the widespread use of self-modifying patches to fill this need :)
cheers Miller
This may be a totally stupid idea but here it goes anyhow... What about creating a special nlet object that can dynamically change the number of nlets (in or out depending on a flag given) and issue command to gop object to redraw itself upon update? Doesn't seem to hard to implement but it does seem a bit unconventional, if you like...
On Wed, May 15, 2013 at 03:15:53PM -0400, Ivica Ico Bukvic wrote:
On 05/14/2013 02:49 PM, Miller Puckette wrote:
Interesting idea. I agree that a non-lazy dev could just make argument strings serve the same function (and sometimes it's good to see all the args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs) catch and use mesages separated by commas? There are lots of things abstractions can't do cleanly (like have variable numbers of inlets/outlets) and perhaps it could be helpful to use after-creation messages somehow for this. (I've always been nervous about the widespread use of self-modifying patches to fill this need :)
cheers Miller
This may be a totally stupid idea but here it goes anyhow... What about creating a special nlet object that can dynamically change the number of nlets (in or out depending on a flag given) and issue command to gop object to redraw itself upon update? Doesn't seem to hard to implement but it does seem a bit unconventional, if you like...
hmm... you'd also want some convenient way to empower people to do something with audio and/or messages going in and out. A similar possibliity might be to make a voicebank object that allocates n copies of an abstraction and makes all their nlets appear on the containing patch somehow.
-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This may be a totally stupid idea but here it goes anyhow... What about creating a special nlet object that can dynamically change the number of nlets (in or out depending on a flag given) and issue command to gop object to redraw itself upon update? Doesn't seem to hard to implement but it does seem a bit unconventional, if you like...
hmm... you'd also want some convenient way to empower people to do something with audio and/or messages going in and out. A similar possibliity might be to make a voicebank object that allocates n copies of an abstraction
and
makes all their nlets appear on the containing patch somehow.
I was thinking something along the lines that receives are created for each nlet as those are created so that way you could route things within the patch without resorting to scripted patching. E.g. multioutlet is created with optional arguments blah 1 4. Blah is its context, 0/1 is whether it is inlets or outlets, and last is the number of nlets (4). Now this object is set up to receive blah_0, blah_1, etc. and they are being routed to respective outlets. There could be another signal based nlet or one that can do both (with more optional arguments or messages passed into it). At any rate, you get the idea--it's not that great the more I think about it but it does potentially solve a few issues...
On 05/15/2013 03:15 PM, Ivica Ico Bukvic wrote:
On 05/14/2013 02:49 PM, Miller Puckette wrote:
Interesting idea. I agree that a non-lazy dev could just make argument strings serve the same function (and sometimes it's good to see all the args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs) catch and use mesages separated by commas? There are lots of things abstractions can't do cleanly (like have variable numbers of inlets/outlets) and perhaps it could be helpful to use after-creation messages somehow for this. (I've always been nervous about the widespread use of self-modifying patches to fill this need :)
[args( | [canvasinfo] |
That is, whatever mechanism is used to parse the arguments to an object
box would be the same used by the "args" method of [canvasinfo]. So
you'd get an initial list of args to the outlet followed by a subsequent
message to the outlet for each comma separated message. (I suppose
"rawargs" would be a desirable method to add as well.) I need to look
back at Gridflow, because matju already implemented comma separated
syntax. All I remember is that he had an object which would send the
comma separated messages to the leftmost [inlet] which I didn't like.
But I don't know how it worked in object boxes, so I'll have a look.
As for "after-creation" as a general issue-- I'm sorry but it requires [initbang]. There's just no way around it. You can call it a different name, or you can hide it in args of a revised [loadbang] or implement it in whatever manner you want but that is the solution, it's been implemented, and it works.
Moreover, we cannot assume that every "after-creation" job which needs to happen inside abstraction can be triggered by a user-specified, comma-separated message. Easy example: imagine an object that sprouts an extra inlet depending on whether or not an argument was actually provided (like [select]). You don't want to force the user to type [someobject, I don't have any args].
I'm sure there are other examples that don't even have to do with arguments at all-- IOhannes has written about them somewhere on the list. The point is that you cannot restrict "after-creation" message-passing functionality to the domain of comma-separated arguments. You simply need a _general_ way to output a bang after all the objects inside the abstraction have been created. Though comma-separated messages to abstractions depend on that, they are themselves a separate issue.
-Jonathan
cheers Miller
This may be a totally stupid idea but here it goes anyhow... What about creating a special nlet object that can dynamically change the number of nlets (in or out depending on a flag given) and issue command to gop object to redraw itself upon update? Doesn't seem to hard to implement but it does seem a bit unconventional, if you like...
Well to be honest if you don't want to dynamically instantiate objects, then what other way is there aside from this approach?
I find it a nice idea. Some ideas:
structures, although that's a niche. Either by improving existing objects (like the array "change" pointer, and I have a list of other wishes somewhere), or by adding new methods or objects that make things easier. It's still amazing at how much work is necessary to perform simple operations.
(used in gui objects) on data structures? that wouldn't break the existing one, and would add an rgb reference, which makes much more sense than the current "logic"
impossible task, but do you mind just having a look to see if there's "a new hope"? As I recall, the main problem was the GUI implementation.
"play x [to] y" function
does [readany] really work? how about adding flac to it?
at some point I posted a bug in pd-dev about big arrays not displaying
anything after 2000(?) points. Improving on this might be good
properties and user interaction?
depending on the question above, is there any working mp3 object in pd?
since [soundfiler] has to read a sound file's information, how about it
also dumps out the general parameters given by [wavinfo], [tof/sample_unpack], [soundfile_info]? this one isn't really an emergency, but it's a bit strange to be doubling the amount of objects.
You should not just put something about your idea in your website, but also in the puredata.info wiki. Maybe there are other persons that would like to contribute or to help with the programming.
João
Hi List, I'd like to try a method of getting paid for doing Pd work which I
will call a "Reverse" Kickstarter". Basically I'll work on the aspects
of Pd I'm currently working on through the month of May, full time, then
at the beginning of June if anyone wants to pay me for the work I finish
up to that point I'll do another month's work, full time, if a
particular goal is reached. This way the Pd community will end up with
the benefit of my work at the beginning of June at no risk/cost, and
I'll do a lot of the work I would have done anyway (though devoting more
time to it than I would have otherwise). I call it a "Reverse Kickstarter" for this reason-- if the work I
complete in May is enough for someone to donate X amound of money, then
even if I fail to produce anything of value in June the donor still got
something of value for their donation. Of course I plan on continuing
to develop and hopefully getting better at it as I learn, but the point
is instead of trying to garner a buzz around potential development (and
most Kickstarter projects fail, so its risky), I instead garner a buzz
around actual development for which potential donors can reward me, use
as a gauge for what my future development will be, or both.Here's what I'm currently working on:
- [canvasinfo], [pdinfo], and [classinfo] objects to streamline getting
information about parts of Pd that do not have xlets for messages:
implemented, but does not include all pd attributes yet (like audio/midi
devices)
- jump-on-click and bar graph style options for "Put" menu arrays:
implemented, but I need to do more testing and make it possible to
change the baseline for data structure arrays based on quanta values
- centralized "Preferences" dialog with tabs for General, Audio, Midi,
GUI, and possibly some others: just started implementing it, will work
on it for the next few days
- improve tooltips: show tip next to mouse location, and have separate
canvas tip for stuff like pddplink to show firefox-style link address.
add xlet descriptions, so you can get one or two word description of
what the xlet does in addition to its method (handy for objects like
[vcf~], [tabread], etc.)
- use libname-meta.pd file to find aliases for objects with a creator
name that cannot be a c function name (like ">~")
And some future stuff:
- use Xapian for better search-plugin speed and functionality
- [drawimage] for data structures
- building Pd using MinGW from GNU/Linux: unless someone already has
this working...
- gui-plugin to export pd patch to svg
- way to embed pd source in svg, or use <g> to group things per object
- adding a function to make it easy to parse comma-separated A_GIMME
args to an object as named args. Thus for [someobject foo 1 2 3, bar 1
2 3 4, blah bee], there should be a function that can be used inside of
someobject_new for which the author can ask for the "foo" args and
retrieve "1 2 3" (maybe by returning the indices to the first and last
arg of "foo"). That will match the syntax of message boxes and give
external developers an easy and consistent way to do named args.All of my work will hopefully follow these guidelines:
- does not break patches. Question: while all changes I'm making will
let old Pd files run on revised Pd, do the files written by revised Pd
have to run on old Pd?
- preference given to generally useful development. (maybe [drawimage]
is an exception since few people use data structures, so I'll put that
one last.)
- preference given to development that makes Pd more accessible to new
users.
I'll look at the easiest ways to get the process rolling. I really like
Paul Davis' donation "progress bar" on the Ardour website, so I might
try getting something like that on my website.Furthermore, if anyone has some general features they think are missing
from Pd and want to donate specifically for them, I'd be happy to look
at those too. But for May at least I'd like to try to focus on what I'm
currently working on.I still need to figure out a good target to start out with and the
easiest payment system to use. So suggestions are certainly welcome
about that or anything else. :)-Jonathan
On 05/15/2013 02:12 PM, João Pais wrote:
I find it a nice idea. Some ideas:
- I myself am very interested in anything that will improve on data
structures, although that's a niche. Either by improving existing objects (like the array "change" pointer, and I have a list of other wishes somewhere), or by adding new methods or objects that make things easier. It's still amazing at how much work is necessary to perform simple operations.
It's kind of a chicken and egg problem. Data structures are a fringe feature (outside of their relationship to "Put" menu arrays). To make them into a more accessible feature would require a lot of work. I think there are more important changes that should come first, and some of those changes may make data structures easier to improve in the future.
- a specific question: does it make sense to use the -xxxxx color scheme
(used in gui objects) on data structures? that wouldn't break the existing one, and would add an rgb reference, which makes much more sense than the current "logic"
I think symbolic colors like #ff0000 are more widely accepted/understood.
Inside [plot] I just added two symbol arguments for such colors (fill and outline color). It's ugly because now there are three places to specify color: the original 3-digit ds color code, then the last two arguments that are symbolic colors. But objects like [plot] that have a bunch of positional arguments are already ugly. This is where named arguments (like a comma separated list) are very appealing-- then we could just have a fillcolor method to set the fill color, and that method could take either a single symbolic argument like #ff0000, or three floats for rgb which would be more suitable or "Pd-ish" for programmatically changing the color.
- at some point I spoke with IOhannes about porting FTM to Pd. It
seems an impossible task, but do you mind just having a look to see if there's "a new hope"? As I recall, the main problem was the GUI implementation.
Do you have a link to the some info on it? Or a demo on vimeo or youtube?
- let [readsf~] keep files open after playing once, and add a "seek" or
"play x [to] y" function
I think there was a thread about readsf~ recently. I'll go back and have a look.
- does [readany] really work? how about adding flac to it?
[readanysf~]?
- at some point I posted a bug in pd-dev about big arrays not
displaying anything after 2000(?) points. Improving on this might be good
- for an array [foo], [r foo] would spew details like changes in
properties and user interaction?
In Pd-l2ork, an array named "array1" has a receiver [array1_changed] that sends a bang when an element is changed.
Can you point me to the bug you posted?
- depending on the question above, is there any working mp3 object in pd?
I think [readanysf~] supports mp3
- since [soundfiler] has to read a sound file's information, how about it
also dumps out the general parameters given by [wavinfo], [tof/sample_unpack], [soundfile_info]? this one isn't really an emergency, but it's a bit strange to be doubling the amount of objects.
That's something I've wanted for a long time as well. Unfortunately Pd is no stranger to doubling objects:
cyclone/abs~ markex/abs~ creb/abs~ zexy/abs~
One of these does optimization for blocksizes that are multiples of 8, one does optimization using simd instructions, one doesn't do any optimization, and one looks like it was planned to selectively compiled based on whether or not any of the others already exist!
Not to mention abs~ now in Pd Vanilla. If Pd-extended/Pd-l2ork does not want to break patches they would technically need to keep every single one of them forever (because of namespace prefixes).
You should not just put something about your idea in your website, but also in the puredata.info wiki. Maybe there are other persons that would like to contribute or to help with the programming.
This is the only place I've put information so far.
-Jonathan
João
Hi List, I'd like to try a method of getting paid for doing Pd work which I will call a "Reverse" Kickstarter". Basically I'll work on the aspects of Pd I'm currently working on through the month of May, full time, then at the beginning of June if anyone wants to pay me for the work I finish up to that point I'll do another month's work, full time, if a particular goal is reached. This way the Pd community will end up with the benefit of my work at the beginning of June at no risk/cost, and I'll do a lot of the work I would have done anyway (though devoting more time to it than I would have otherwise). I call it a "Reverse Kickstarter" for this reason-- if the work I complete in May is enough for someone to donate X amound of money, then even if I fail to produce anything of value in June the donor still got something of value for their donation. Of course I plan on continuing to develop and hopefully getting better at it as I learn, but the point is instead of trying to garner a buzz around potential development (and most Kickstarter projects fail, so its risky), I instead garner a buzz around actual development for which potential donors can reward me, use as a gauge for what my future development will be, or both.
Here's what I'm currently working on:
- [canvasinfo], [pdinfo], and [classinfo] objects to streamline
getting information about parts of Pd that do not have xlets for messages: implemented, but does not include all pd attributes yet (like audio/midi devices)
- jump-on-click and bar graph style options for "Put" menu arrays:
implemented, but I need to do more testing and make it possible to change the baseline for data structure arrays based on quanta values
- centralized "Preferences" dialog with tabs for General, Audio,
Midi, GUI, and possibly some others: just started implementing it, will work on it for the next few days
- improve tooltips: show tip next to mouse location, and have
separate canvas tip for stuff like pddplink to show firefox-style link address. add xlet descriptions, so you can get one or two word description of what the xlet does in addition to its method (handy for objects like [vcf~], [tabread], etc.)
- use libname-meta.pd file to find aliases for objects with a creator
name that cannot be a c function name (like ">~")
And some future stuff:
- use Xapian for better search-plugin speed and functionality
- [drawimage] for data structures
- building Pd using MinGW from GNU/Linux: unless someone already has
this working...
- gui-plugin to export pd patch to svg
- way to embed pd source in svg, or use <g> to group things per object
- adding a function to make it easy to parse comma-separated A_GIMME
args to an object as named args. Thus for [someobject foo 1 2 3, bar 1 2 3 4, blah bee], there should be a function that can be used inside of someobject_new for which the author can ask for the "foo" args and retrieve "1 2 3" (maybe by returning the indices to the first and last arg of "foo"). That will match the syntax of message boxes and give external developers an easy and consistent way to do named args.
All of my work will hopefully follow these guidelines:
- does not break patches. Question: while all changes I'm making
will let old Pd files run on revised Pd, do the files written by revised Pd have to run on old Pd?
- preference given to generally useful development. (maybe
[drawimage] is an exception since few people use data structures, so I'll put that one last.)
- preference given to development that makes Pd more accessible to
new users.
I'll look at the easiest ways to get the process rolling. I really like Paul Davis' donation "progress bar" on the Ardour website, so I might try getting something like that on my website.
Furthermore, if anyone has some general features they think are missing from Pd and want to donate specifically for them, I'd be happy to look at those too. But for May at least I'd like to try to focus on what I'm currently working on.
I still need to figure out a good target to start out with and the easiest payment system to use. So suggestions are certainly welcome about that or anything else. :)
-Jonathan