On Fri, 2007-03-16 at 08:26 +0000, padawan12 wrote:
On Thu, 15 Mar 2007 06:54:40 -0700 shift8 shift8@digitrash.com wrote:
what resources would you recommend that illustrate calculus as used for signal processing, but from a more functional point of view as opposed to a theoretical one.
I heartily recommend Steven W Smiths "Scientists and Engineers guide to DSP", before tackling Perry Cook, Eduardo Miranda and our own Miller Puckette. Calculus is only a small part of the picture, maybe you use the word too broadly because it's just a technique that helps understand certain equations. For calculus you needn't really go above A level, a little of that with a good grasp of algebra, trig and geometry are a solid enough basis. Linear algebra and matrices are some useful tricks to put in your bag, and you can get a long way by reading many of the tutorials for Octave.
this site rocks!
haven't seen this one - will check it out.
http://www.amazon.co.uk/Real-Sound-Synthesis-Interactive-Applications/dp/156...
As Chuckk and some of the other mathematicians have said here, some esoteric pure math like operator theory subsumes the whole subject, because sound is about changes and transformations, but I wonder what other peoples top 10 'must have' concepts are. I suppose it depends on your goals, for example a lot of composers learn a disproportionate amount of stats and distributions.
i have been playing around with those a bit from a very lay perspective
- mostly randomized scales w/ occasional octave shifting (random w/ %,
usually). i'm a fan of generative work, and hope to get better at it as time goes by and i better my skills.
i know there are dsp chip programming guides for engineering, but there seems to be only "how" and not the "why" in most cases there. too theoretical of descriptions makes it difficult for me to visualize the action or imagine the sonic implications of the theory being discussed.
personally, i find that the application of theories make much more sense than the abstract theories themselves. maybe it's brain damage, or perhaps plain 'ol ignorance.
but anyway, here's a simple example:
someone tells me an empirical definition of the nyquist theory, it's hard to get my head around. but if someone says "hey, you can't sample a frequency that is >= 1/2 of the sample rate, because the wavelength is too short in duration to fit sample boundaries, and it causes distortions that are related to the frequency being sampled." that totally makes sense. i can picture that from a functional point of view, and then have a much easier time with the math an theory of it.
I strongly agree with you about teaching theory in context. It is hard to pick good examples and write using only words so that the knowledge sticks. Sometimes symbolic representation is the only way to be unambiguous. That is why Puredata is a powerful teaching and exploration tool, the diagram is the program. We are also lucky to have people like Derek and Frank who write from a position of "least assumptions". I find a lot can be learned by just browsing the archives.
truly - i've learned so much from pd, the help docs (brilliantly implemented in pd themselves), and all of the rocking folks that share their ideas w/ the list so often. the pd archive is a super bad ass resource - one of the days i'm going to throw together a script that culls patches from the archives and makes the containing mail the readme.txt for them.
are there any resources, books, etc out that approach the subject of dsp in a style like this?
One of Eduardo Mirandas more gentle books "Computer Sound Design" gives a pretty broad read, it also has some fun Windows and Mac software on the CD ROM. And you can't go wrong reading classics like Roads.
that's like the 3rd recommendation for Rhoads - guess i'll be picking that one up :)
Perhaps it's important to know that classic DSP is only a part of synthesis and analysis. It's the "implementation" layer.
true - but i think the digital representation has a definite impact on technique.
Another area of wisdom to explore is physics. I like to start sound design lectures by explaining that sound is a branch of dynamics, particularly fluid dynamics. Physics really helps design realistic sound effects, to know about propagation, interference, reflection, damping, stress, elasticity and all that. Then you can make ballpark models of what sound waves are doing in an object of given materials and dimensions. There's a big section in the book I'm writing about knowledge, imperative, declarative and procedural, and how to move from a description to a model to a method. Really this is Software Engineering, but that's what we are doing at the end of the day.
software and systems arch is what i do for a living, and one of the big reasons why pd has such a draw to me. i'm much better at control-flow design then ssynthisys (hence my post i guess...)
others reasons for interest are a bit more abstract - the concept of dataflow languages in general, real-time feedback in the development process. it's like what uml should be (kinda:). other ideas that drive my interests here are developments like the "Seed" game prototype, the concept of synthesizing *anything* - generic "assemblers", a la the Diamond Age (you know, the non-apocalyptic kind :), moving away from static content in general, the basic sameness of images and audio in time and frequency space, etc etc.
physics has always held my interest (i grew up on a diet of omni magazine, popular mechanics, hard sci-fi, etc.) knowledge of basic physics tends it makes living in the material world a lot less stressful and danger-prone too :)
the only thing about physical modeling synthesis that gets me is the sheer amount of time it takes to model sounds based around the (often many!) physical properties of the instrument/object/machine etc being modeled. then again - that's one of the reasons i dig your work so much :)
Empirical knowledge is so important too ( I think you use that term a bit incorrectly above).\
sorry - i've been up all night. that's my exscuse, and i'm sticking to it. or somethin. heh - let's call it antonym-based dislexia. theoretical would have fit much better in that sentence for sure :)
All the good synthesists seem to learn by experience, lots of experience gained during thousands of hours of playing about with code. It's no discredit to people like Eno and Bristow that they probably don't know a Bessel function from an Aardvark, but are masters of FM because they simply know it inside out in a practical way. Many accomplished producers work this way, the theory follows later to connect the wealth of practical experience they gain in the studio. There's no "right" way to do it. However the sooner you have theory the better you will have consistent and reproducible results because you get why something works rather than just observing that it does.
that's kinda where i'm coming from i think - i love old analog gear (my favs being the ultra-simple mc202, the korg electribe analog modeled drum machine, synth seq and the like), and oddly, i think that's also what drives me to dig deeper into synthesis w/ pd and the like - technologies like OSC bring us back to something approximating the analog world (or can, i should say). i've always been a tinkerer, and have an innate desire to know how things work. more so for things that i really like.
thanks and high regards, star
Cheers, thanks for the encouragement dude, but I am not a Jedi yet ;) Not by a long way. The term that describes my situation is "Ronin".
so... a samurai w/ no master? :)
As for ninjas, I believe they are only mercenary assassins. They would be no match for Pirates. Yaaar. This Slashdot poll settles the matter once and for all :) http://slashdot.org/pollBooth.pl?qid=1396
hells yeah! pirates, hands down.
with respect, star
best, Andy
On Thu, 2007-03-15 at 15:24 +0000, padawan12 wrote:
[pow~] is from cyclone, I think in the case I used it (pow 2) you can replace it with an equivilent [expr~] expression or [*~]. I thought [lowpass] and [highpass] were vanilla. They are needed to set the coeffs for biquad~
On Wed, 14 Mar 2007 16:49:29 -0800 Josh Steiner josh@vitriolix.com wrote:
i seem to be missing:
lowpass, highpass and pow~
running 0.39.2-extended-test7 on winxp
-josh
padawan12 wrote:
Sorry Hardoff, scratch that last load of rubbish. The parasite synth is the wrong patch, and I thought I was talking about different oscillators, it should have been something more like the ones here. The oscillator is a dual-slope one in hoover-triangles.pd, much easier to pull out than the last mess.
Another take is the hoover-pwm.pd, which is a juno voice basically, it's much brighter and fizzy down low. It just depends what you want more in the low registers, up high theres not so much difference. One is pulse width mod of a square, the other is slope mod of a triangle, both have a bit of frequency lfo on too at about 5 Hz. A fat Juno hoover noise uses the fast chorus so there's one on both versions. Each has the same sequence so you can compare the sounds. All the hoover flavours have a different character, like a highpass resonant filter makes an interesting addition. But what they share in common is a busy sound made by having 3 or 4 detuned components. Juno is a pwm + saw + square mix, with the square an octave down.
On Mon, 12 Mar 2007 22:34:01 +0900 "hard off" hard.off@gmail.com wrote:
andy's tokyo techno one is cool.
but i want hoovers. i keep try to make them and they always suck. there must have been a secret ingredient that i am forgetting.
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
-- ________________________________________________________________ tasty electronic music vittles -- bluevitriol.com the only music blog you need -- playtherecords.com you are the dj. interactive music -- improbableorchestra.com random observations of the bizarre -- vitriolix.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Mechanize something idiosyncratic.