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
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
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
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?
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
On Tue, 17 Mar 2009 03:49:11 -0500
Luke Iannini lukex...@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
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
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,
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
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
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
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.
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,
: Synchromatic: Out December 1st 2008
http://www.pyramidtransmissions.com/store
Also available through the iTunes store
--- On Sun, 15/3/09, Frank Barknecht f...@footils.org wrote:
From: Frank Barknecht f...@footils.org
Subject: Re: [PD] Unified Library was Re: Call for GSoC mentors! March 9th
deadline
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
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
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
17 matches
Mail list logo
