<div class="gmail_quote">On Sat, Jan 15, 2011 at 6:35 PM, linuxdsp <span dir="ltr"><<a href="mailto:mike@linuxdsp.co.uk">mike@linuxdsp.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>
2) Blindly using the 'black box' approach to constructing complex DSP processing can have its pitfalls if you don't have a grasp of (at least the theory) of what is going on inside the boxes - for example in synthedit you might wire up a bunch of filters (say to make a multiband compressor) without a clue about the correct way to manage the phase alignment of the filters with the result that your great new plugin actually has huge deep notches in the frequency response when it should sum back to flat (Note: this is also a problem with just re-using plugins and libraries in other ways - my recent tests using JAMIN suggest exactly this problem happens when using the IIR multiband)<br>
</blockquote><div><br></div><div>Well, saying there are pitfalls to blind black box dsp development begs the question - where does one gain the basic knowledge as to eliminate some of this blindness? I'd hazard a guess and say that there are quite a few people here who are to some extent autodidacts, and who often learn from experience. A well documented and precise example developed in a graphical development environment would go much farther than a DSP textbook in this case. I have a great deal of respect for the training and skill of a good DSP programmer, but in reality, there are not that many of them, and most of them are busy trying to eek out a living to pay for the knowledge that was so hard gained. For the rest of us, we either have to wait for the gurus to release stuff, or learn by experimenting. A GUI toolkit lowers the barrier to entry significantly. Or to put it another way, given a choice between having to learn DSP theory plus C/C++ or DSP theory through documented visual examples in the same toolkit that will produce plugins, I'd choose the latter given my time constraints, and given the fact that I find it much easier to "read" the logic of visual patching than I do text based code.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3) Synthedit's ability to just churn out a finished .dll meant that everyone could start making plugins without any programming knowledge and superficially, out of the resulting thousands of free plugins, you wouldn't know the good from the bad (although if you look in your vst_plugins folder after / while using a synthedit plugin you will normally find the tell-tale signs of it dumping its little .dat files and modules out all over the place)<br>
</blockquote><div><br></div><div>Fully acknowledged, and many of them were/are CPU hogs to boot.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
All of this is not to say that the tools should not be available to do such things, but perhaps people need to be aware of the potential problems, and to appreciate that although such tools make DSP seem easy, it most definitely is NOT and requires a great amount of knowledge and experience to do (and understand) properly (and even then its easy to get caught out!)</blockquote>
<div><br></div><div>I don't think there needs to be such a hard divide between users and developers (though of course I've got nothing to lose and no frustration to gain from cowboys riding into this particular town, mostly because it's not my town). Even among amateurs, there will always be good amateurs and not so good amateurs. The value of community is that people share not just the plugins but their opinions about them. Among the synthedit users/developers, certain of them gained a reputation based on the quality of their output. And that quality was no doubt dependent on DSP skills and knowledge. Again, I personally fully appreciate that DSP is not easy. But I do believe it can be more fun and more accessible. For most people, it seems having fun is more important than being exact, and may actually help them learn to be more exact in the process.</div>
<div><br></div><div>All that being said, I have to admit to a certain degree of devil's advocacy. I actually agree with Dave that even given the current set of existing linux audio tools, one is only limited by one's imagination. The tools that are out there now are more than technically capable of spurring my imagination. The question is open as to how enjoyable that spurring might be in the implementation.</div>
<div><br></div><div>-michael</div></div>