Hi everyone,
I'm looking self-contained DSP abstractions that only use Pd - no externals. Things like reverbs, different types of filters, delays, a pitch shifter, harmonizer -- a kind of basic 'FX' toolbox.
I'm thinking very much along the lines pdmtl/fx.* but without the external dependencies.
Thoughts I've had so far:
- Pull stuff out of the Pd help patches
- Pull stuff out of the list archives
- Remove the dependency requirements from pdmtl/fx.*
But, maybe someone has a nice 'set' of such abstractions sitting on their hard drive, that they wouldn't mind releasing into the public domain -- or under some permissive license.
TIA,
Jamie
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
http://www.netpd.org/eni/purepd/
good luck
eni
Jamie Bullock wrote:
Hi everyone,
I'm looking self-contained DSP abstractions that only use Pd - no externals. Things like reverbs, different types of filters, delays, a pitch shifter, harmonizer -- a kind of basic 'FX' toolbox.
I'm thinking very much along the lines pdmtl/fx.* but without the external dependencies.
Thoughts I've had so far:
- Pull stuff out of the Pd help patches
- Pull stuff out of the list archives
- Remove the dependency requirements from pdmtl/fx.*
But, maybe someone has a nice 'set' of such abstractions sitting on their hard drive, that they wouldn't mind releasing into the public domain -- or under some permissive license.
TIA,
Jamie
On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote:
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn?
Sorry if this has already come up...
Jamie
Jamie Bullock wrote:
On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote:
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn?
Sorry if this has already come up...
Jamie
feel free to use the abstractions. if i can help with purepd i will certainly do. maybe we could include the filter abstractions that came up a while ago on the pd-list?
eni
Quoting Jamie Bullock jamie@postlude.co.uk:
On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote:
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn?
just out of curiosity: >~.pd, <~.pd, sgn~ and what else in zexy are
already pd-vanilla abstractions (some of them are both abstractions
and externals for performance reasons); is there an advantage in
collecting these things in yet another arbitrary (as opposed to
grouped by functionality) library?
fgmasdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at wrote:
Quoting Jamie Bullock jamie@postlude.co.uk:
On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote:
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn?
just out of curiosity: >~.pd, <~.pd, sgn~ and what else in zexy are
already pd-vanilla abstractions (some of them are both abstractions
and externals for performance reasons); is there an advantage in
collecting these things in yet another arbitrary (as opposed to
grouped by functionality) library?
where are any abstractions/externals "grouped by functionality"? do you mean pdmtl?
just to be clear: the files netpd.org/eni/purepd/ are not collected as library, they are just there since i have no other place to put them and it could be useful for purepd reasons.
the svn purepd patches contain some abstractions that confuse me a bit. actually i would like to contribute to purepd. (i.e. why is there moses and clip?)
maybe we should define a purepd styleguide too. the any_argument abstraction bothers me. i belive the patches could work without them and i would prefer to keep it super simple.
my diy library (work in progress) is not all pure pd, but fair chunks of it are. it shouldn't be too hard to rip the dsp guts out of some abstractions for your purposes.
or
http://puredata.hurleur.com/sujet-1982-diy2-effects-sample-players-synths-so...
On Tue, 2008-08-26 at 10:37 +0300, hard off wrote:
my diy library (work in progress) is not all pure pd, but fair chunks of it are. it shouldn't be too hard to rip the dsp guts out of some abstractions for your purposes.
or
http://puredata.hurleur.com/sujet-1982-diy2-effects-sample-players-synths-so...
Wow! That's really impressive -- just what I was looking for. Looks like a lot of work has gone into it. Do you have any licensing requirements, or is it provided as-is for people to hack up and do what they want with?
Jamie
On Tue, 2008-08-26 at 02:52 -0400, Enrique Erne wrote:
<snip> > the svn purepd patches contain some abstractions that confuse me a bit. > actually i would like to contribute to purepd. (i.e. why is there moses > and clip?)
Yes, me too! Maybe H-C intends it to be a 'turtles all the way down' Pd implementation?
maybe we should define a purepd styleguide too. the any_argument abstraction bothers me. i belive the patches could work without them and i would prefer to keep it super simple.
simple++
Jamie
Enrique Erne wrote:
just out of curiosity: >~.pd, <~.pd, sgn~ and what else in zexy are
already pd-vanilla abstractions (some of them are both abstractions
and externals for performance reasons); is there an advantage in
collecting these things in yet another arbitrary (as opposed to
grouped by functionality) library?where are any abstractions/externals "grouped by functionality"? do you mean pdmtl?
i didn't mean any special library; it was rather a comment on the absence of "grouped by functionality" libs.
just to be clear: the files netpd.org/eni/purepd/ are not collected as library, they are just there since i have no other place to put them and it could be useful for purepd reasons.
i did not want to offend you for pointing to your files.
the thing i was asking about was, whether these objects should be added to another arbitrary library in svn (a request for which i paranoidedly sensed), without any benefit.
the svn purepd patches contain some abstractions that confuse me a bit. actually i would like to contribute to purepd. (i.e. why is there moses and clip?)
well, it proves hat you don't need an external to use them :-) i guess it is rather didactic, but i don't see any harm in having them there.
fgmadsr IOhannes
On Tue, 2008-08-26 at 03:29 +0200, zmoelnig@iem.at wrote:
Quoting Jamie Bullock jamie@postlude.co.uk:
On Sun, 2008-08-24 at 09:54 -0400, Enrique Erne wrote:
Hi Jamie
It's not much but might be helpful to port other stuff to purepd.
you'll find gt~.pd (>~) lt~.pd (<~) sgn~.pd
That's great actually, and I'd love to contribute back into this. However, if I'm not mistaked aren't there two purepd projects netpd/purepd and Hans's purepd in pd svn? Would it be worth feeding your patches into Hans's, and then any other abstractions I make/find I can also feed into svn?
just out of curiosity: >~.pd, <~.pd, sgn~ and what else in zexy are
already pd-vanilla abstractions (some of them are both abstractions
and externals for performance reasons); is there an advantage in
collecting these things in yet another arbitrary (as opposed to
grouped by functionality) library?
I think I kind of addressed this in my reply to Patrick, but I find the current situation with libraries of abstractions and externals a bit unsatisfactory. It would really be better if we separated out the storage layout (svn) and the user presentation bit, so that users could group externals/pathches by tag, or some othe non-hierarchical/non-exclusive grouping.
Jamie
On Sun, Aug 24, 2008 at 08:42:29AM +0100, Jamie Bullock wrote:
I'm looking self-contained DSP abstractions that only use Pd - no externals. Things like reverbs, different types of filters, delays, a pitch shifter, harmonizer -- a kind of basic 'FX' toolbox.
I'm thinking very much along the lines pdmtl/fx.* but without the external dependencies.
Thoughts I've had so far:
- Pull stuff out of the Pd help patches
- Pull stuff out of the list archives
- Remove the dependency requirements from pdmtl/fx.*
But, maybe someone has a nice 'set' of such abstractions sitting on their hard drive, that they wouldn't mind releasing into the public domain -- or under some permissive license.
Hi Jamie,
This has been sitting in my inbox for ages, sorry I never replied to it. My s-abstractions collection is just such a set of abstractions that you describe, with no external dependencies. Much of it was made by stealing Miller's help patches and turning them into nice little guis, and lots of other people's work too. I'm trying to bulk it up a bit at the moment with the great plate reverb that Anton Hornquist posted here a while back, and then I'm going to try and make a good, intuitive compressor after that. If you do a pitch shifter or harmonizer, please let me know so I can steal them for my collection, with your consent obviously! :)
http://mccormick.cx/projects/s-abstractions
After I get back to London next week I'm going to try and tidy the collection up a bit and get the latest version into pd-extended. I think the version that is in there at the moment is pretty outdated.
Chris.
On Mon, 2008-10-20 at 03:19 +0800, Chris McCormick wrote:
<snip>
This has been sitting in my inbox for ages, sorry I never replied to it. My s-abstractions collection is just such a set of abstractions that you describe, with no external dependencies. Much of it was made by stealing Miller's help patches and turning them into nice little guis, and lots of other people's work too. I'm trying to bulk it up a bit at the moment with the great plate reverb that Anton Hornquist posted here a while back, and then I'm going to try and make a good, intuitive compressor after that. If you do a pitch shifter or harmonizer, please let me know so I can steal them for my collection, with your consent obviously! :)
http://mccormick.cx/projects/s-abstractions
After I get back to London next week I'm going to try and tidy the collection up a bit and get the latest version into pd-extended. I think the version that is in there at the moment is pretty outdated.
Thanks Chris. I was already aware of s-abstractions, and I think they're fantastic. I didn't realise that they were pure Pd, so that's good to know.
best,
Jamie
-
Chris McCormick -
Enrique Erne -
hard off -
IOhannes m zmölnig -
Jamie Bullock -
Jamie Bullock -
zmoelnig＠iem.at