Back again...
I think those who are really interested in a library of objects, suitable for early users (I hate the term 'beginners') to explore acoustics, synthesis etc, will be interested in Metastudio 0.3, which will be released soon, with full help files for each object.
I'll SVN it when I have a candidate for release. I am really close to completion, and it's nicely deep! I mean it has usability for the early user and deep structure for the more adventurous type. I'm putting together my workshop proposal/paper/gig now. I'll email once I've finished that with some working examples.
Anything PD is just an abstraction. In theory, any group of abstractions can be built to teach or to play. The wonderful thing about PD is that teaching and playing are only a cut-and-paste away, or an abstraction call within a PD patch.
Well...I got work to do. ED
Lone Shark: Synchromatic: Out December 1st 2008 http://www.pyramidtransmissions.com/store Also available through the iTunes store
--- On Sun, 15/3/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline! To: pd-list@iem.at, "Kyle Klipowicz" kyleklip@gmail.com Date: Sunday, 15 March, 2009, 8:47 PM
-----Inline Attachment Follows-----
Hallo, hard off hat gesagt: // hard off wrote:
none of the libraries are very good general
all-purpose toolkits though, in
my opinion. i guess that's mainly because none
of them have really been
designed as general toolkits. there is heaps of
good stuff in rjdj, but
it's all for the phone, which has no pd GUI component.
Well, the RjDj patches (scenes) are written on a computer as well.
The focus on GUI-less objects so far is by design: I believe, that we need to have basic building blocks *without* GUI first (maybe you remember the list thread about a dsp or "tilde" library? That had an influence on the RjDj design). Later we can decorate any abstraction with GUIs, provided the basic block offer a standardized communication interface.
In RjDj the rightmost inlet in (most) abstractions is this interface: This inlet accepts tagged messages like "freq <num>" or "delay <num>" or "note <num> <num>". RjDjlib includes a handful of custom GUI elements which just are GOP wrappers around sliders, numbers etc. that automatically create these messages. For example you can create a [g_hsl freq 0 22050] to get a slider GUI, that will have a range of 0...22050 and outputs messages like "freq <value>" and can be set with "freq <val>" messages to its inlet.
The g_* abstractions in RjDj all can be chained:
[g_hsl pitch 0 127] | [g_hsl vel 0 127] | [g_hradio octave 4] | [mycoolsynthesiszer]
so GUIs can be built in a consistent way and they can even be reused in parts.
Having the GUI separate from the DSP abstraction also makes polyphony easy: You can use just one GUI to control many voices in a synth.
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
yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional abstractions. that was the big flaw of the DIY library i did, that the function of the abstractions was tied in with the gui component. i did it that way because i didn't want to clutter the namespace with too many abstractions, and the thought of one abstraction for function, and then a different one for GUI was not appealing at the time.
but now, i think that is the only way to go. like, as you said, for polyphony. and then also for the many many cases in which you'd want to build your own gui for custom control.
i do think you guys have got a really really strong system there with rjlib. but i was just saying that without the gui stuff, it doesn't exactly fit into being that 'all purpose building blocks' library that we are discussing.
Hallo, hard off hat gesagt: // hard off wrote:
yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional abstractions. that was the big flaw of the DIY library i did, that the function of the abstractions was tied in with the gui component. i did it that way because i didn't want to clutter the namespace with too many abstractions, and the thought of one abstraction for function, and then a different one for GUI was not appealing at the time.
but now, i think that is the only way to go. like, as you said, for polyphony. and then also for the many many cases in which you'd want to build your own gui for custom control.
Yeah, basically that was all I wanted to say as well. ;)
i do think you guys have got a really really strong system there with rjlib. but i was just saying that without the gui stuff, it doesn't exactly fit into being that 'all purpose building blocks' library that we are discussing.
Yes, that's true. rjlib has its focus on audio and control abstractions to be used on mobile devices with vanilla Pd. Some of this fits into a "all purpose" library, but a lot of it doesn't.
Ciao
Frank
i had a look at rjlib. it's a beautiful collection. i love the fact that it is not too big and not using any external.
though why is there a u_sssad.pd it seems the same as the original sssad.pd frank didn't you say once you would prefer that people don't include their own copy of sssad?
same with the new-fast list-drip in u_listdrip.. is it just for naming-convention that you renamed the abstraction?
the whole e_ and s_ part is fantastic there are some really powerful effects and filters in there. i looked more carefully and the only phone related one is m_touch2grid which could be useful without a phone too.
is this the correct url? http://svn.rjdj.me/scenes/trunk/rjlib/rj
hm... now i've seen http://svn.rjdj.me/scenes/trunk/rjlib/
this is ofcorse phone specific and what confuses me now is that there is a copy of sssad.pd
anyway rjlib/rj is just beautiful. what license is it released under? i couldn't find anything about that in the wiki.
eni
Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional abstractions. that was the big flaw of the DIY library i did, that the function of the abstractions was tied in with the gui component. i did it that way because i didn't want to clutter the namespace with too many abstractions, and the thought of one abstraction for function, and then a different one for GUI was not appealing at the time.
but now, i think that is the only way to go. like, as you said, for polyphony. and then also for the many many cases in which you'd want to build your own gui for custom control.
Yeah, basically that was all I wanted to say as well. ;)
i do think you guys have got a really really strong system there with rjlib. but i was just saying that without the gui stuff, it doesn't exactly fit into being that 'all purpose building blocks' library that we are discussing.
Yes, that's true. rjlib has its focus on audio and control abstractions to be used on mobile devices with vanilla Pd. Some of this fits into a "all purpose" library, but a lot of it doesn't.
Ciao
Yo! Sorry I have been absent, I've been at SXSW : ). You asked about the style guide in the other thread:
Amusingly I ground to a halt on it when I tried to figure out the different word-separators for hierarchies, spaces and OSC addresses : ). But! I've finally somehow spontaneously decided the most "Pd-like" specification is: "-" for hierarchies, as Miller and Frank and many others seem to do (e.g. $0-foobar-baz, and as part of pd itself: [s pd-mysubpatch]) "_" as "space", e.g. [receive a_certain_frob]
AFAICT this is pretty much what rjlib has settled on as well? (perhaps less deliberately)
SO! If you love consistency and interoperability, please now begin using this : ).
(I myself am now condemned to obsessively change hundreds of my patches, since I had personally settled on an inconsistent mess of "." and "/" for hierarchies and "-" for space :&.)
And, if anyone else cared about programmatically reconciling such names with OSC addresses, it's easy enough to just dynamically replace "-" with "/" where appropriate (using zexy or any2string or whatever).
I've resurrected the Style Guide here with this mandate ;) and will continue folding things into it from the previous discussions as well as those about to occur... http://puredata.info/docs/style-guide/StyleGuideDraft2
I'm very much in agreement with everything else being said about separation of gui and logic...
Best Luke
On Tue, Mar 17, 2009 at 3:14 AM, Enrique Erne enrique@netpd.org wrote:
i had a look at rjlib. it's a beautiful collection. i love the fact that it is not too big and not using any external.
though why is there a u_sssad.pd it seems the same as the original sssad.pd frank didn't you say once you would prefer that people don't include their own copy of sssad?
same with the new-fast list-drip in u_listdrip.. is it just for naming-convention that you renamed the abstraction?
the whole e_ and s_ part is fantastic there are some really powerful effects and filters in there. i looked more carefully and the only phone related one is m_touch2grid which could be useful without a phone too.
is this the correct url? http://svn.rjdj.me/scenes/trunk/rjlib/rj
hm... now i've seen http://svn.rjdj.me/scenes/trunk/rjlib/
this is ofcorse phone specific and what confuses me now is that there is a copy of sssad.pd
anyway rjlib/rj is just beautiful. what license is it released under? i couldn't find anything about that in the wiki.
eni
Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional abstractions. that was the big flaw of the DIY library i did, that the function of the abstractions was tied in with the gui component. i did it that way because i didn't want to clutter the namespace with too many abstractions, and the thought of one abstraction for function, and then a different one for GUI was not appealing at the time.
but now, i think that is the only way to go. like, as you said, for polyphony. and then also for the many many cases in which you'd want to build your own gui for custom control.
Yeah, basically that was all I wanted to say as well. ;)
i do think you guys have got a really really strong system there with rjlib. but i was just saying that without the gui stuff, it doesn't exactly fit into being that 'all purpose building blocks' library that we are discussing.
Yes, that's true. rjlib has its focus on audio and control abstractions to be used on mobile devices with vanilla Pd. Some of this fits into a "all purpose" library, but a lot of it doesn't. Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 17 Mar 2009 03:49:11 -0500 Luke Iannini lukexipd@gmail.com wrote:
"-" for hierarchies, as Miller and Frank and many others seem to do (e.g. $0-foobar-baz, and as part of pd itself: [s pd-mysubpatch]) "_" as "space", e.g. [receive a_certain_frob]
How do "we" feel about the use of actual whitespace, particularly in inlet and outlet boxes. I generally use - and _ as hierarchy and spacing delimiters as per convention, but when it comes to inlets and outlets I often say [outlet patch params] or something, thinking everything but 'patch' will be ignored.
Anyone else suspect this is storing up trouble for the future?
a.
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
How do "we" feel about the use of actual whitespace, particularly in inlet and outlet boxes. I generally use - and _ as hierarchy and spacing delimiters as per convention, but when it comes to inlets and outlets I often say [outlet patch params] or something, thinking everything but 'patch' will be ignored.
Anyone else suspect this is storing up trouble for the future?
With xlets, there still is the undecided question if the first argument should serve a different purpose than tooltips. It could be used to specify the order explicitly or to do reblocking etc. So even the use of inlet arguments to specify tooltips is unofficial.
It's probably to late already, but grabbing more arguments is a bit dangerous IMO (I don't even use the first arg so far, but I'm always a bit extracautious).
Ciao
Frank
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
i had a look at rjlib. it's a beautiful collection. i love the fact that
it is not too big and not using any external.though why is there a u_sssad.pd it seems the same as the original
sssad.pd frank didn't you say once you would prefer that people don't
include their own copy of sssad?
No, I'm fine with that - actually it's encouraged. sssad.pd is just a single file. But people should keep theire copy up to date. ;)
What I don't like is if people use [sssad/sssad] and expect it to work on everyone's system automatically.
same with the new-fast list-drip in u_listdrip.. is it just for
naming-convention that you renamed the abstraction?
Yes, it's just for the naming convention we use. While I don't want to duplicate other libraries, I also wanted to include a minimal set of useful list-handling-objects. IMO list-drip, list-map/reduce/filter, a list serializer and an index lookup are the core objects for list-operations in addition to the builtins.
the whole e_ and s_ part is fantastic there are some really powerful
effects and filters in there. i looked more carefully and the only phone
related one is m_touch2grid which could be useful without a phone too.is this the correct url? http://svn.rjdj.me/scenes/trunk/rjlib/rj
hm... now i've seen http://svn.rjdj.me/scenes/trunk/rjlib/
this is ofcorse phone specific and what confuses me now is that there is
a copy of sssad.pd
We include sssad as u_sssad because it's central to the saving system (as are the u_loader and u_dispatch objects) so including it lets people use it without having to fetch it from somewhere else first. Rjlib is pretty much self-contained.
anyway rjlib/rj is just beautiful. what license is it released under? i couldn't find anything about that in the wiki.
Ah, tagging all objects with licenses - that's something on my big TODO list. :(
rjlib is planned to be GPL v3 with some patches, like those that have been taken from the docs, under BSD. sssad or the list-stuff for example is still BSD.
Ciao
Frank
Yes! rjlib is really nice! I finally tried using svn, it's really simple...I guess I was intimidated by nothing.
svn checkout http://svn.rjdj.me/scenes/trunk/rjlib/
So simple!
But really, kudos on such a beautiful, minimal, functional, cohesive library.
~Kyle
On Tue, Mar 17, 2009 at 3:14 AM, Enrique Erne enrique@netpd.org wrote:
i had a look at rjlib. it's a beautiful collection. i love the fact that it is not too big and not using any external.
though why is there a u_sssad.pd it seems the same as the original sssad.pd frank didn't you say once you would prefer that people don't include their own copy of sssad?
same with the new-fast list-drip in u_listdrip.. is it just for naming-convention that you renamed the abstraction?
the whole e_ and s_ part is fantastic there are some really powerful effects and filters in there. i looked more carefully and the only phone related one is m_touch2grid which could be useful without a phone too.
is this the correct url? http://svn.rjdj.me/scenes/trunk/rjlib/rj
hm... now i've seen http://svn.rjdj.me/scenes/trunk/rjlib/
this is ofcorse phone specific and what confuses me now is that there is a copy of sssad.pd
anyway rjlib/rj is just beautiful. what license is it released under? i couldn't find anything about that in the wiki.
eni
Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
yeah sorry frank, i should have explained more clearly.
i also think that no GUI is the way to go for functional abstractions. that was the big flaw of the DIY library i did, that the function of the abstractions was tied in with the gui component. i did it that way because i didn't want to clutter the namespace with too many abstractions, and the thought of one abstraction for function, and then a different one for GUI was not appealing at the time.
but now, i think that is the only way to go. like, as you said, for polyphony. and then also for the many many cases in which you'd want to build your own gui for custom control.
Yeah, basically that was all I wanted to say as well. ;)
i do think you guys have got a really really strong system there with rjlib. but i was just saying that without the gui stuff, it doesn't exactly fit into being that 'all purpose building blocks' library that we are discussing.
Yes, that's true. rjlib has its focus on audio and control abstractions to be used on mobile devices with vanilla Pd. Some of this fits into a "all purpose" library, but a lot of it doesn't. Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Ed Kelly -
Enrique Erne -
Frank Barknecht -
hard off -
Kyle Klipowicz -
Luke Iannini