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
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 danomatika@gmail.com 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 http://www.robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 danomatika@gmail.com
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
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.
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__
-
danomatika -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
Kyle Klipowicz