Re: A draft whitepaper of my parameterization idea
Posted: Wed Apr 02, 2008 12:31 pm
I will look into it as well. Just so you know you're not alone.
The LinuxSampler Postboard
He also says it's possible to interface with the parameters of the routine externally without a GUI:Yann Orlarey wrote:The 'compute(int count, float** inputs, float** outputs)' method computes 'count' samples at a time. This is why you have a 'for (int i=0; i<count; i++)' loop inside the compute method.
Albert Graef had this to add:Yann Orlarey wrote:Yes. The user interface don't have to be a GUI, it can be anything that implements the UI API. This implementation can just ignore the fact that a slider or a button is required and only keep track of the addresses of the float parameters used to communicate with the dsp. You can look at the CMDUI as an example of non graphic UI implementation (in architecture/sndfile.cpp).
I'll go take a look at those examples. I also have some example code I'm showing to my C++ prof today, to see if he can guide me. It doesn't sound like it would be too hard to do, and we can use the same template for any block written directly into C++ as well.Albert Graef wrote:Chances are that you'll have to write your own "architecture" (that's just a fancy name for the C++ template code needed to embed the signal processor in a given target application or system, into which the Faust compiler simply inserts the "naked" dsp code).
There's no HOWTO about that right now, but it's really simple, you just have to understand the interface of the dsp and UI classes and then derive from those classes and implement them in an appropriate manner. You can find lots of examples in the architecture folder in the Faust sources. For the puredata.cpp architecture file I started out by adding things to minimal.cpp, but you might also find some other more elaborate architecture file which is already closer to the application that you have in my mind.
To which Mr. Graef replied:Darren Landrum wrote:Okay, I took a look at the minimal.cpp code, and at some of the other examples, and I think I get how it works. Basically, the line <<includeclass>> is where the compiled FAUST class gets inserted, right? So everything else is basically just the code needed by whatever external programs are going to interface with the FAUST code. In our case, we'll be writing our own UI classes to interface with, as our UI is getting handled by a separate layer of our final application.
Apparently, that means I'm finally getting somewhere.Albert Graef wrote:Yes, exactly.