New book on DSP and Plug-ins from Focal Press...

[wavepunk]

3) Just some mess (as with audio programming book (just my thought))

Do you mean "The Audio Programming Book" by Boulanger and Lazzarini? Overall I thought it was a good introduction to the topic, and I enjoyed reading it. It comes packed with tons of stuff that includes much supplementary material on the DVD.

It is frought with typos that caused me much confusion on several occasions though. Every coefficient formula for the Butterworth and LP/HP filters it gives are way off! I had to go to Dodge & Jerse to get the right ones.

Yep, about it.

What I didn't liked about it, is that the book:
1) Tries to tech you C language at the same time as you learn sound processing.
To me, learning 2 things at the same time is not a good idea, because it leads to bigger confusion at the beginning. They also build command line synth, which I think is not needed - what is needed is to demostrate audio concepts in easy manner (without additional and reduntant superstructure).

2) Not enought attention to audio things.

For example, chorus and flanger in the book are defined as: out(n) = in(n) + in(n - del), which, at the first glance, might be simple. But the actual implementation is left out, which might be essential, if you just begin.

Well, it's just me - my first impression on the book. I couldn't "read" the book. Maiby next time . But I must say that the book contains also usefull information. Personally I liked balance processor, a chapter about filters on CD and a referenced article about FFT. It also contains some stuff about algorithmic composition - should definitely try it some day.

[AdmiralQuality]

Sounds like total crap, I'd avoid this one folks. Shawn Cassidy poster or not!

[hibrasil]

lots more info about the book here and videos of the software he uses... http://www.willpirkle.com/rackafx/
A bit disappointing - however I think if the code examples and explanations are good it could still be useful.

[earlevel]

Seriously, the whole concept of "not theory-heavy" suggest a target audience in the "not going to get anywhere" group.

Still, wouldn't you say that when people complain about a book or paper being "theory heavy" in a negative way, they aren't complaining so much about the fact that there is a lot of theory explain, but maybe that it's explained in an arcane way, or that its overly abstract (would benefit from some practical advice or intuitive view)?

I had designed and built synthesizers own my own, then was employed doing the same three decades ago when I read my first proper DSP book (Rabiner & Gold). I understood it, mostly, but didn't gain much from it until I pulled out my old Hal Chamberlin book (first edition, autographed copy) and read the digital audio chapters more closely. That gave me the toe-hold I needed for R&G to make a lot more sense.

About three years, ago, I got a call from Japan; I recognized the name of caller immediately—a visionary in the musical instrument and recording industries. He was very excited about reading my blog—he asked if he could pay me to tutor him (I said I'd be happy to just get together and chat, no charge). This is a guy who designed a popular DSP chip dedicated to reverb and effects, ASICs in popular synths, etc. He was excited because he couldn't stand the rigor yet lack of practical information in most DSP texts. (He died before his time and before we could get together, a couple of years ago, but most people here would immediately recognize his companies and his ground-breaking products if not his name.)

For example, the FFT is a very simple and basic thing. But I think that most people who read the usual mathematical explanation come away with only vague understanding. Another is that every A-Z DSP book explains FIRs, IIRs, and a few ways to calculate the coefficients for them, but rarely gives a clue as to the good points and bad points and where you might use each type. About the most practical thing they tell you is that it's a good idea to build up high-order IIRs from lower order sections due to practical considerations. (Then we learn later that all the filters shown mostly suck

Sorry for being long-winded—my point is that I think a lot of people benefit from gaining some basics given in terms they can understand (which needn't exclude the heavy theory) and build from there.

[valhallasound]

About three years, ago, I got a call from Japan; I recognized the name of caller immediately—a visionary in the musical instrument and recording industries. He was very excited about reading my blog—he asked if he could pay me to tutor him (I said I'd be happy to just get together and chat, no charge). This is a guy who designed a popular DSP chip dedicated to reverb and effects, ASICs in popular synths, etc. He was excited because he couldn't stand the rigor yet lack of practical information in most DSP texts. (He died before his time and before we could get together, a couple of years ago, but most people here would immediately recognize his companies and his ground-breaking products if not his name.)

OK, now I'm just sad. I had some communication with Keith as well, along similar lines. It was amazing that a guy that I learned so much from (via his very useful DSP tutorials on the Spin Semiconductor site), who had been innovating since the early 1970s, still had such enthusiasm for learning new techniques. I gave him a quick overview of feedback delay networks, and learned a lot of great tricks about allpass loops via our email exchange.

Sorry for being long-winded—my point is that I think a lot of people benefit from gaining some basics given in terms they can understand (which needn't exclude the heavy theory) and build from there.

The Hal Chamberlin book you mentioned is still amazingly useful, as is Dodge and Jerse. I've seen a few 1st editions of Dodge/Jerse at used bookstores for fairly cheap, and would recommend this to people starting out, as the Fortran code in that book is easy to translate into C.

Sean Costello

[mystran]

Seriously, the whole concept of "not theory-heavy" suggest a target audience in the "not going to get anywhere" group.

Still, wouldn't you say that when people complain about a book or paper being "theory heavy" in a negative way, they aren't complaining so much about the fact that there is a lot of theory explain, but maybe that it's explained in an arcane way, or that its overly abstract (would benefit from some practical advice or intuitive view)?

I don't know. I often find that much of the "theory heavy" stuff tends to suffer from the same hand-waving as much of the "practical" stuff (which I don't find very "practical" in practice; see below), leaving out critical stuff that, or explaining some concepts in prose and others in math, barely bridging the two.

Basically, I find that usually the most "theory heavy" stuff is the most "practical" because if you rigorously prove that your ring-buffer is correct and that your filter structure corresponds to the coefficient formulas as derived from the analog transfer by the Möbius tranform that is BLT... and so on and on.. by the end of the book, if you managed to actually process it, you do have all the practical information!

But yes, "theory heavy" books are just as guilty of "skipping details" and just taking some magical formulas out of their magic hats.. and then everyone is using the same direct forms and Chamberlin, because the average text-book author either doesn't know, or doesn't bother to try to explain, how to actually design filters (and not just filter transfer functions!).

[earlevel]

OK, now I'm just sad. I had some communication with Keith as well, along similar lines.

Well, maybe I made that too obvious, but I was afraid that if I said it too briefly, it would sound like I was talking about Bob Moog—LOL...yes, Keith...thought I did a fair amounting of consulting for Alesis back then, I never managed to meet him in person.

The Hal Chamberlin book you mentioned is still amazingly useful, as is Dodge and Jerse.

I've never read Dodge & Jerse...the reaction of my first read of Chamberlin was...throw up the hands and think, dammit, where was this a few years ago—I had already figured out the minutia of CMOS and polystrene caps and such to run my analog creations from a 6502 on my own. The second read for the DSP stuff was more appreciated—he explained the FFT in a way I understood, and gave me more confidence to tackle the dryer texts that had left me with too many questions.

BTW, bought Valhallaroom recently—very nice, thanks.

[earlevel]

I don't know. I often find that much of the "theory heavy" stuff tends to suffer from the same hand-waving as much of the "practical" stuff...

Agreed. I didn't intend to paint all "theory heavy" or all "practical" material with a broad brush, and certainly if I have anything again the theory-heavy stuff, it's because *some* of it is written by people who either lack writing skills, or (especially in the case of technical papers) people who think that they need to write in the same passive and detached, theoretical manner as other papers they've read, in order to be taken seriously. Have you ever read technical paper on a product (maybe a programmable chip) that was of the form, "The blah feature may be modified to do blah blah..." that left you wondering, by whom? the end user?, the developer? the vendor? Active voice can be wonderful thing ("You can modify the blah to do blah by setting the blah bit in the blah register").

Again, my point was that I think that when people complain about texts being "theory heavy", they are often complaining about the arcane presentation and lack of practical information, not that the text is rigorous.

But yes, "theory heavy" books are just as guilty of "skipping details" and just taking some magical formulas out of their magic hats.. and then everyone is using the same direct forms and Chamberlin, because the average text-book author either doesn't know, or doesn't bother to try to explain, how to actually design filters (and not just filter transfer functions!).

Well said.

[DougCox]

I just got the book Designing Audio Effect Plug-ins in C++, and have spent about an hour going through it. It's very impressive. The ratio of words to diagrams/graphs/math formulas seems to be about 50/50. It's not for the beginner. I know the basics of what it's dealing with, but I have to say that I think it's pointed toward brilliant readers, and not people like me. I'm reminded of my college experience (I went to a college with a lot of brilliant students), where I understood what the professor was saying, but the brilliant students understood what he was TRYING to say. This book is for that kind of person (or the person who already knows almost everything about DSP and is looking for something he might have missed). It's definitely graduate level stuff.

[Music Engineer]

I just got the book Designing Audio Effect Plug-ins in C++, and have spent about an hour going through it. It's very impressive. [...]

can you tell us a bit more now, what this mysterious Windows®-PlugIn and Socket® stuff is about?

i'm also interested in how detailed chapter 14 is (commerical Plugin APIs) is. i mean, does it cover VST and/or AU in decent detail? what about other formats like LADSPA, AAX, etc.?

actually, i'm typically more interested in DSP related topics, but to that end, the TOC looks like there's probably a lot of overlap with DAFX, which i already have on my shelf (1st edition).

...hmm...so, if the non-DSP chapters are relevant to me (and the DSP-chapters hopefully add something here or there, which is missing in DAFX), i'd be inclined to order it.

[Music Engineer]

lots more info about the book here and videos of the software he uses... http://www.willpirkle.com/rackafx/
A bit disappointing - however I think if the code examples and explanations are good it could still be useful.

the dsp algorithms seem to be all very basic. in the code examples from the website, i see brute-force convolution (in a plugin, called "Convolver" - where i hoped some full-blown zero-latency-FFT-convolution), wavetable-oscillators without any mip-mapping, the simplest possible ladder-filter, a waveshaper without any oversampling, etc. all in all, i have the impression that this book should be seen as an introductory text.

[DougCox]

can you tell us a bit more now, what this mysterious Windows®-PlugIn and Socket® stuff is about?

I'm pretty sure he's just referring to VST Plugins in a Windows environment. And sockets are a way to communicate. I use them in my FTP program to send and receive data with the Internet.

i'm also interested in how detailed chapter 14 is (commerical Plugin APIs) is. i mean, does it cover VST and/or AU in decent detail? what about other formats like LADSPA, AAX, etc.?

No, chapter 14 is actually titled Miscellaneous Plug-Ins. It includes a tremolo/panning plugin, a ring modulator plugin, and a wave shaper plugin. He mentions AU in a paragraph and VST in a sentence somewhere.

actually, i'm typically more interested in DSP related topics, but to that end, the TOC looks like there's probably a lot of overlap with DAFX, which i already have on my shelf (1st edition).

arakula's table of contents isn't exactly right. Chapter 2 is Anatomy of a Plug-In, which looks a LOT simpler to me than the chapter 1, which is too sketchy for people like me. Chapter 3 is Writing Plug-Ins with RackAFX (the author's program which is probably an excellent way to play with his C++ plug-in examples). And the rest is heavy DSP stuff (heavy for me). I actually only just copied a few Low Pass Filter equations to use with SoundFonts a couple of years ago.

...hmm...so, if the non-DSP chapters are relevant to me (and the DSP-chapters hopefully add something here or there, which is missing in DAFX), i'd be inclined to order it.

I'm guessing it would be "right up your alley" because of the primary focus on DSP theory. Since he teaches at the University of Miami, the book is heavy on theory but includes RackAFX as a simple way to get "hands-on".

[arakula]

And sockets are a way to communicate. I use them in my FTP program to send and receive data with the Internet.

Funny. But surely not what's meant here.

arakula's table of contents isn't exactly right.

Copied verbatim from the book's web site...

[mystran]

can you tell us a bit more now, what this mysterious Windows®-PlugIn and Socket® stuff is about?

I'm pretty sure he's just referring to VST Plugins in a Windows environment. And sockets are a way to communicate. I use them in my FTP program to send and receive data with the Internet.

I'm pretty sure Robin knows "relatively exactly" what (TCP/IP) sockets are. I'm also pretty sure that's why he's wondering, because there isn't any sane reason to use (TCP/IP) sockets in a typical plugin... unless you're trying to implement some fancy network related functionality, but that would have very little to do with DSP.

[Music Engineer]

I'm pretty sure Robin knows "relatively exactly" what (TCP/IP) sockets are. I'm also pretty sure that's why he's wondering, because there isn't any sane reason to use (TCP/IP) sockets in a typical plugin... unless you're trying to implement some fancy network related functionality, but that would have very little to do with DSP.

i don't do any network programming, so i only know vaguely what this stuff is about. but you are right - knowing this (if only vaguely) makes me wonder because it doesn't seem to make much sense in this context.

on the dsp side, hmm - if the code examples from the website are representative for the depth of the book, then i may not need it. as said above - the algorithms i looked at, seem to be all rather basic.