Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[hard off]

so are we going to go ahead with this?

does anyone want to volunteer to set up a wiki?  i'm terrible at any of that
sort of thing.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

Hallo,
Enrique Erne hat gesagt: // Enrique Erne wrote:

> could you explain the polyphony example?
>
> doesn't each voice have the same parameter, coming from the gui?

I might want to save settings even though I didn't use a GUI to set
them. Settings don't necessarily come from a GUI.

For example say I use an algorithm to generate settings, or I may
write my settings into a textfile or a message box - there also is no
GUI involved. Settings in Pd however all are manipulated by sending
messages, even GUIs are just a way to generate a message. So the way
to save state in Pd IMO is to intercept message, not to watch GUI
elements.

In regard to polyphony, it's pretty common to duplicate a synth voice
many times, manually or using e.g. polypoly or rjlib's u_makepoly.
There is no need to have a GUI in those hidden objects, but I still
need to access their parameters to set them. So what I need is a way
to peek into the abstraction and eavesdrop their messages. 

In rjlib that peeping hole is the rightmost inlet. [sssad] is used in
a wrapper u_dispatch at that inlet that also dispatches messages
coming in to local senders. So the abstractions all know their state
even though most of them don't have a GUI. If I want a GUI, I just
make one that produces messages for the control inlet.

Maybe some OO programming language experts can say smart things about
how this is related to a Model-View-Controller paradigm, where the GUI
elements constitute one of many possible Views, the [textfile] is a
Model and [sssad] is the controller but I'm not good at this stuff.

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Kyle Klipowicz]

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  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
>



-- 
-

    -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Andy Farnell]

On Tue, 17 Mar 2009 03:49:11 -0500
Luke Iannini  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.


-- 
Use the source

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Luke Iannini]

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  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
>

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Enrique Erne]

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

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Enrique Erne]

Frank Barknecht wrote:

Hallo,
danomatika hat gesagt: // danomatika wrote:


So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with
SSSAD.  So if you want SSSAD you use the gui.


I wouldn't put the sssad objects in the version with GUI. IMO It's more useful
to have them in the engine objects, e.g. for polyphony.


could you explain the polyphony example?

doesn't each voice have the same parameter, coming from the gui?

in my experience it's best to save the state right at the interface,
i don't see the point of saving state deep in the core.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

Hallo,
danomatika hat gesagt: // danomatika wrote:

> So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with
> SSSAD.  So if you want SSSAD you use the gui.

I wouldn't put the sssad objects in the version with GUI. IMO It's more useful
to have them in the engine objects, e.g. for polyphony.

Ciao
-- 
Frank

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[danomatika]

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.


This is where the pd-mtl convention makes so much sense ...

Core functionality is made into patches with an underscore at the end of
the name and the regular name is just
a gui wrapper around it.  I've started using the approach in the
rc-patches and, as Frank said before, it makes
building larger gui objects much simpler.  The right inlet takes all the
control whenever possible using name messages.

So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with
SSSAD.  So if you want SSSAD you use the gui.

---
Dan Wilcox
danomatika.com
robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[hard off]

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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Ed Kelly]

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  wrote:

> From: Frank Barknecht 
> Subject: Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th 
> deadline!
> To: pd-list@iem.at, "Kyle Klipowicz" 
> 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 "
> or "delay "
> or "note  ". 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 "
> and can be set with
> "freq " 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
> 


  

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Frank Barknecht]

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 " or "delay "
or "note  ". 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 " and can be set with
"freq " 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 BarknechtDo You RjDj.me?  _ __footils.org__

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[hard off]

>>But I think that we don't really know well enough how to do the whole
thing right<<


i have good experience in doing a library wrong. :)  i can at least point
out the flaws in that so they don't get repeated.

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.  netpd on the other
hand, everything has a gui, and it's all designed to work well as a part of
the netpd system.  but it's a little bit tricky to then use the netpd
patches outside of netpd.  not really spent too much time with pdmtl, but
that just seems like more of a collection of patches than an actual library.
s-abstractions and the diy library i did both fall down a bit for me because
they tie the functionality of the patches in too much with the gui and state
saving.

i think what hans is talking about and what we are discussing might be
completely different things though.  i think hans is talking about a truly
unified library to join together all the different pieces in pd-extended and
put them all together in a logical and user-friendly manner.  which would be
a pretty massive project, i admit.

i think though, what we're talking about here is more just like a collection
of tools to build synths, sequencers, effects, samplers, recorders,
soundfile players, etc etc etc.  most of the libraries already mentioned are
doing that.  but the problem is that there are no unified conventions for
patching, naming, licencing, etc.  and it would be nice to have all the best
and most useful bits of each library in one place, all working together, and
all very simply and easily ported into other pd projects.

i think it's well within our reach to do that at the moment.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Hans-Christoph Steiner]

There are lots of great ideas in all of those libraries, and I think  
Pd would be really well served having a big grand unified collection  
of libraries.  But I think that we don't really know well enough how  
to do the whole thing right.  So we really should think of this as  
some stepping stones.  That is why I have been advocating for people  
to take on specific libraries first, like a filter lib, or a midi lib,  
or a mapping lib, etc.  Then in thru that process we can both figure  
out how to build the whole grand unified scheme, and build up the  
chunks while we are at it.


.hc

On Mar 15, 2009, at 4:05 AM, Kyle Klipowicz wrote:

Maybe take a vote and see what convention is most popular: pdmtl, s- 
abstractions, rjlib, netpd, or others I am not remembering.


Then, figure out which items from other libraries should be ported  
first to this convention.


Next, give this library a special status within Pd-extended so that  
people know they can go to it very easily, rather than getting mired  
down in the list of funny names that is currently the examples folder.


A wiki is a good idea for the API f'sho. I am thinking pdmtl right  
now, but have not looked at s-abs or rjlib very closely. Netpd is  
very nice too, just needs to be categorized like pdmtl.


~Kyle

On Sat, Mar 14, 2009 at 10:28 PM, danomatika   
wrote:
Count me in ... I think we just need to make a wiki page and all  
agree on patching conventions as well as who can/should do what ...  
oh and mailing lists?


My patches are focused on allowing me to playback midi files to run  
a drum machine, live effects for guitar and vocals, generative or  
sequenced analog style bass/lead synths, and easy mixing/bussing  
etc.  I do not have a dsp/digital approach to Pd, but I'm sure  
there's plenty who do ... this could be a good collaborative project  
for sure.


i think this idea of making a unified library of patches is  
fantastic.  but

i don't think it should be a project given to a student with little
experience in pd.

i'd be more than happy to help out.

what would be the best way to set up communications between us, if  
we take

this on?  that would be the first step i guess.
---
Dan Wilcox
danomatika.com
robotcowboy.com

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




--
-

    -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list






Computer science is no more related to the computer than astronomy is  
related to the telescope.  -Edsger Dykstra



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[Kyle Klipowicz]

Maybe take a vote and see what convention is most popular: pdmtl,
s-abstractions, rjlib, netpd, or others I am not remembering.
Then, figure out which items from other libraries should be ported first to
this convention.

Next, give this library a special status within Pd-extended so that people
know they can go to it very easily, rather than getting mired down in the
list of funny names that is currently the examples folder.

A wiki is a good idea for the API f'sho. I am thinking pdmtl right now, but
have not looked at s-abs or rjlib very closely. Netpd is very nice too, just
needs to be categorized like pdmtl.

~Kyle

On Sat, Mar 14, 2009 at 10:28 PM, danomatika  wrote:

>  Count me in ... I think we just need to make a wiki page and all agree on
> patching conventions as well as who can/should do what ... oh and mailing
> lists?
>
> My patches are focused on allowing me to playback midi files to run a drum
> machine, live effects for guitar and vocals, generative or sequenced analog
> style bass/lead synths, and easy mixing/bussing etc.  I do not have a
> dsp/digital approach to Pd, but I'm sure there's plenty who do ... this
> could be a good collaborative project for sure.
>
>  i think this idea of making a unified library of patches is fantastic.
> but
> i don't think it should be a project given to a student with little
> experience in pd.
>
> i'd be more than happy to help out.
>
> what would be the best way to set up communications between us, if we take
> this on?  that would be the first step i guess.
>
>   ---
> Dan Wilcox
> danomatika.com
> robotcowboy.com 
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
-

    -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

[danomatika]

Count me in ... I think we just need to make a wiki page and all agree
on patching conventions as well as who can/should do what ... oh and
mailing lists?

My patches are focused on allowing me to playback midi files to run a
drum machine, live effects for guitar and vocals, generative or
sequenced analog style bass/lead synths, and easy mixing/bussing etc.  I
do not have a dsp/digital approach to Pd, but I'm sure there's plenty
who do ... this could be a good collaborative project for sure.


i think this idea of making a unified library of patches is
fantastic.  but
i don't think it should be a project given to a student with
little
experience in pd.

i'd be more than happy to help out.

what would be the best way to set up communications between us,
if we take
this on?  that would be the first step i guess.

---
Dan Wilcox
danomatika.com
robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list