Hallo, jared hat gesagt: // jared wrote:
I'm having problems getting PD running comfortably. The easiest way, in my opinion, for someone trying to learn PD is to open existing patches that are similar, or use the same objects, as the patch they are trying to build. I've been quite frustrated because it seems that most of the patches that I open won't work on my system. This is obviously my fault. I probably don't have files/patches/externals in their right places.
Not only probably, but for sure. Or maybe you have them, but you didn't tell Pd, where you have them with the File->Path rsp. File->Startup menu entries.
If you try to run patches that cannot create certain objects, you should probably contact the patch author, who should know, what objects are in use. Most of the objects are in the CVS at sourceforge. Even if you don't plan to compile anything, I would recommend to get hold of a complete checkout of the CVS, because you could search the directories for missing objects. vasp for example is part of the CVS.
I think the biggest obstacle, for beginners, is getting PD setup correctly and to get everything running smoothly.
No offense, but IMO a beginner should first get comfortable with the builtin objects. Setting up plain Pd should be easy.
As for example Andy's patches on obiwannabe.co.uk show, you can do amazing patches using no or just a small handful of externals. And then there are Miller's patches in doc/* that all run without any special setup required.
If the builtin objects are known a bit, work up your way through some common collections of externals. I would recommend to start with zexy. Learn how to load a library and/or how to setup the search patch in Pd to find single externals.
Zexy is very useful, well documented, available in pd-extended and also a good start when you happen to be interested in learning how to compile your own binaries of externals. Concentrating on first getting only one set of externals to run will teach you the basic principle of getting every external to run.
Frank Barknecht _ ______footils.org_ __goto10.org__
No offense, but IMO a beginner should first get comfortable with the builtin objects. Setting up plain Pd should be easy.
No offense taken. You're definitely right, especially if we're
talking about someone who doesn't have any patching experience with PD/Max. Personally though, I've spent the last year with Max/MSP on a master's course, so I'm not a complete beginner. I was under the assumption that PD and Max were very similar programs. There are obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start from square one with PD.
Thanks so much for the advice, Frank. Much appreciated!
Best,
Jared
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?
I learned PD by reproducing things which I understood already in stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the built-in examples, then I made simple things and basic utilities. After that I went back to the examples I skipped and figured out what I did wrong, and then I moved on to "porting" things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor instruments, various VSTs, etc). These kinds of exercises are the ones I think work best. Start from a point you know, and figure out how to do it with the most basic objects in PD. If core PD doesn't do it, then it's time to reach for an external.
best, d.
jared wrote:
obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start from square one with PD.
That's very sound advice, Darek! I followed(/am following) a very similar trajectory.
What I'd add to that:
Above all, don't think that you need to only use Pd for everything. It's a great tool, but can bog you down from truly creating things if you are stuck reinventing the wheel every time you get the time and urge to make music/art.
It's perfectly acceptible to use Pd for its strengths, but then another application when Pd is less-than-adequate (or requiring dozens of hours to make it adequate).
I recall a quote from Miller that paraphrased said something to the effect that Pd is like the bash shell in UNIX. You wouldn't write a word processor in a bash script, but it's great for rapidly prototyping a quick and useful solution.
~Kyle
On 2/20/07, Derek Holzer derek@umatic.nl wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?
I learned PD by reproducing things which I understood already in stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the built-in examples, then I made simple things and basic utilities. After that I went back to the examples I skipped and figured out what I did wrong, and then I moved on to "porting" things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor instruments, various VSTs, etc). These kinds of exercises are the ones I think work best. Start from a point you know, and figure out how to do it with the most basic objects in PD. If core PD doesn't do it, then it's time to reach for an external.
best, d.
jared wrote:
obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start from square one with PD.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 77: "Give way to your worst impulse"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Feb 20, 2007, at 9:14 PM, Derek Holzer wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible
for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?
Partially, I think this is due to lack of common practice in coding
style and things like that. Most languages, programming or other,
have a lot of standard practices when it comes to writing them done
in different contexts. For whatever reason, the Pd/Max world has not
developed many conventions, and I think that makes reading other
people's patches harder.
.hc
I learned PD by reproducing things which I understood already in
stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the
built-in examples, then I made simple things and basic utilities. After that I went back to the examples I skipped and figured out what I did wrong, and then I moved on to "porting" things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor
instruments, various VSTs, etc). These kinds of exercises are the ones I think work best. Start from a point you know, and figure out how to do it with
the most basic objects in PD. If core PD doesn't do it, then it's time to reach for an external.best, d.
jared wrote:
obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start
from square one with PD.-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 77: "Give way to your worst impulse"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Sun Feb 25, 2007 at 01:51:33AM -0500, Hans-Christoph Steiner wrote:
On Feb 20, 2007, at 9:14 PM, Derek Holzer wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible
for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?Partially, I think this is due to lack of common practice in coding
style and things like that. Most languages, programming or other,
have a lot of standard practices when it comes to writing them done
in different contexts. For whatever reason, the Pd/Max world has not
developed many conventions, and I think that makes reading other
people's patches harder.
it couldnt possibly be beacuse the whole point or essence of a patch is often sphaghetti, or that theres no way to zoom out to see all the subpatches and abstractions on a single window..
.hc
I learned PD by reproducing things which I understood already in
stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the
built-in examples, then I made simple things and basic utilities. After that I went back to the examples I skipped and figured out what I did wrong, and then I moved on to "porting" things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor
instruments, various VSTs, etc). These kinds of exercises are the ones I think work best. Start from a point you know, and figure out how to do it with
the most basic objects in PD. If core PD doesn't do it, then it's time to reach for an external.best, d.
jared wrote:
obvious similarities, but the more time I spend with PD the more they feel like different beasts. I will definitely go back and start
from square one with PD.-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 77: "Give way to your worst impulse"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2/25/07, carmen _@whats-your.name wrote:
On Sun Feb 25, 2007 at 01:51:33AM -0500, Hans-Christoph Steiner wrote:
On Feb 20, 2007, at 9:14 PM, Derek Holzer wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?
Partially, I think this is due to lack of common practice in coding style and things like that. Most languages, programming or other, have a lot of standard practices when it comes to writing them done in different contexts. For whatever reason, the Pd/Max world has not developed many conventions, and I think that makes reading other people's patches harder.
it couldnt possibly be beacuse the whole point or essence of a patch is often sphaghetti, or that theres no way to zoom out to see all the subpatches and abstractions on a single window..
Well there are text editors... This is an interesting idea, but even such a zooming feature couldn't show all the sends and receives or throw/catch pairs, could it?
-Chuckk
On Feb 25, 2007, at 3:01 AM, carmen wrote:
On Sun Feb 25, 2007 at 01:51:33AM -0500, Hans-Christoph Steiner wrote:
On Feb 20, 2007, at 9:14 PM, Derek Holzer wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished
patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you
start by reading Goethe?Partially, I think this is due to lack of common practice in coding style and things like that. Most languages, programming or other, have a lot of standard practices when it comes to writing them done in different contexts. For whatever reason, the Pd/Max world has not developed many conventions, and I think that makes reading other people's patches harder.
it couldnt possibly be beacuse the whole point or essence of a
patch is often sphaghetti, or that theres no way to zoom out to see
all the subpatches and abstractions on a single window..
Instead of zooming you can have subpatches of subpatches and
abstractions that use abstractions. Then you can have a complecated
system that fits on your screen. Some of my programs in Pd using 8
or more levels of abstraction.
.hc
.hc
I learned PD by reproducing things which I understood already in stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc. First I played around with the built-in examples, then I made simple things and basic utilities. After
that I went back to the examples I skipped and figured out what I did
wrong, and then I moved on to "porting" things from other apps I had used before and knew the structure of (AudioMulch units, Reaktor instruments, various VSTs, etc). These kinds of exercises are the ones I think
work best. Start from a point you know, and figure out how to do it with the most basic objects in PD. If core PD doesn't do it, then it's
time to reach for an external.best, d.
jared wrote:
obvious similarities, but the more time I spend with PD the more
they feel like different beasts. I will definitely go back and start from square one with PD.-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 77: "Give way to your worst impulse"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
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
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
On 2/20/07, Derek Holzer derek@umatic.nl wrote:
Hi Jared,
for what it's worth, I've been working with PD for years and I still can't read most other people's patches ;-)
Everybody has their own style, their own "handwriting", and some are more readable than others. Diving right into somebody's finished patch is pretty difficult for an experienced user, and almost impossible for a beginner, I'd say! If you were trying to learn German, would you start by reading Goethe?
Imagine learning English by reading Shakespeare. I tried German with Kafka, and, probably for the same reason I like reading him so much in English, it was impossible. Such long sentences. James Joyce learned Italian from Dante Alighieri, and supposedly caused a stir when he went to Italy talking like a medieval person. I obtained a book of Petrarch sonnets a few years ago, and half the words were nowhere in any Italian dictionary.
I learned PD by reproducing things which I understood already in stages, such as going from a quad-panner, a mixer, a sampler and a delay-network, to complex feedback-FM, a granular synthesizer and an algorithmic sequencer...etc etc.
I've found it impossible to make a granular synthesizer with Pd. I thought I tried everything. I've gone from Csound to Pd, and back to Csound, and found I understood Csound so much better for it. Vanilla Pd is so low-level it's like working on the microsound level the whole time. I don't know if it's because Pd is younger, or less popular, or just that it hasn't accepted many externs into the mainline (as Csound has ravenously), but unlike Max/MSP or even Csound, Pd has very few effects you can realize without knowing *exactly* how the DSP behind them works. FFT is about the highest-level thing, and even that has the bare minimum of automation. Ditto with the user-friendly filters. I don't feel like I'm even learning Pd anymore, so much as learning DSP. If I completely understand how some effect is created, it's no trick to realize it in Pd.
-Chuckk
On Sun, 25 Feb 2007 02:50:55 -0500 "Chuckk Hubbard" badmuthahubbard@gmail.com wrote:
Vanilla Pd is so low-level it's like working on the microsound level the whole time.
A good thing for a composer to experience I reckon, at least for a while. Improved understanding micro level gives an automatic useful improvement at macro structure thinking. Sure, learning DSP basics to get that insight is an expensive outlay of time, but worth the benefits because if your range of understanding goes from top to bottom you have a really open range of expression.
I don't know if it's because Pd is younger, or less popular, or just that it hasn't accepted many externs into the mainline (as Csound has ravenously), but unlike Max/MSP or even Csound, Pd has very few effects you can realize without knowing *exactly* how the DSP behind them works.
With Csound you get "medical student brain", loads of built in functions parameter lists memorised by rote. Pd is nice because you understand what's going on because it's right in front of you, or because you built it or can open it and see how someone else built it (abstractions). And you can also get stuck right in and bend it and change it, great learning value, a big benefit of open source. That and the help files. Pd has so many great well thought out help files. When I was a total noob realising you could just right click and get help was the fist major money shot. I now properly "get" the reasoning behind the very anorexic Pd core, with as much derived from as few objects as possible it becomes more portable. The more abstractions instead of externals the better in a way.
But it's not either/or with Pd cos it's also got a massive toybox of funky externals is there to play with in extended when you want to just have fun and not bother yourself with the exact gubbins of every object you use. I had so much joy discovering things like g-canvas, vdn~ and xplay~ , they really kept up interest and enthusiasm for the program.
On 27/02/2007, at 14.37, padawan12 wrote:
I had so much joy discovering things like g-canvas, vdn~ and xplay~
From where is vdn~ ? I can't just find it:
$ pwd /path/to/cvsroot/externals $ grep -iR vdn * Binary file dfx/original/polarizer-source.sit matches Binary file pmpd/doc/pmpd.pdf/pmpd.sxw matches Binary file pmpd/doc/pmpd.sxw matches $ find . -iname '*vdn*' $
Hallo, Steffen hat gesagt: // Steffen wrote:
On 27/02/2007, at 14.37, padawan12 wrote:
I had so much joy discovering things like g-canvas, vdn~ and xplay~
From where is vdn~ ? I can't just find it:
I guess it's a typo and Andy wanted to write [fdn~] from Creb.
Frank Barknecht _ ______footils.org_ __goto10.org__
On 27/02/2007, at 12.21, Frank Barknecht wrote:
Hallo, Steffen hat gesagt: // Steffen wrote:
On 27/02/2007, at 14.37, padawan12 wrote:
I had so much joy discovering things like g-canvas, vdn~ and xplay~
From where is vdn~ ? I can't just find it:
I guess it's a typo and Andy wanted to write [fdn~] from Creb.
Oh. Ok. Thanks for straightening it.
There's a lot of very useful stuff in the Xjimmies abstractions in terms of readymade utilities and effects for newbies to use/take apart/remodel/etc.
http://www.tot.sat.qc.ca/eng/nslam.html
And yes, [fdn~] is very cool too...
d.
padawan12 wrote:
But it's not either/or with Pd cos it's also got a massive toybox of funky externals is there to play with in extended when you want to just have fun and not bother yourself with the exact gubbins of every object you use. I had so much joy discovering things like g-canvas, vdn~ and xplay~ , they really kept up interest and enthusiasm for the program.
Ooh I have not seen this before, thanks for sharing!
~Kyle
On 2/27/07, Derek Holzer derek@umatic.nl wrote:
There's a lot of very useful stuff in the Xjimmies abstractions in terms of readymade utilities and effects for newbies to use/take apart/remodel/etc.
http://www.tot.sat.qc.ca/eng/nslam.html
And yes, [fdn~] is very cool too...
d.
padawan12 wrote:
But it's not either/or with Pd cos it's also got a massive toybox of funky externals is there to play with in extended when you want to just have fun and not bother yourself with the exact gubbins of every object you use. I had so much joy discovering things like g-canvas, vdn~ and xplay~ , they really kept up interest and enthusiasm for the program.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 100: "It is quite possible"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list