bb.linuxsampler.org

One question: Will Omnibus be constructing the networks (hey, let's call 'em "circuits" instead!) at run-time or compile-time in your opinion? I would vote for compile time. The user edit the circuit and then need to "freeze" it (gets compiled in some way in the background) before playing the virtual instrument. (Or maybe something in between with JIT compilation using GNU lightning.)

About libsigc++ and RT performance, I honestly don't know. But I can't imagine that there are any blocking code in the library and it all comes down to how you use it. My hunch is that the complexity is O(N).

Circuits it is!

So, compile-time vs. runtime. Well, for making an instrument, we can certainly go for compile-time, but the ability to create sound designs (I hate the term patches here, because it's too easily confused with code patches) should be doable at runtime. So, thinking in Reaktor-like terms, the Ensemble is compiled, but the programs for the Ensemble (or the sound designs or the patches) would work like any other synth or sampler. So, to us, a "Circuit" is what they call an Ensemble. Works for me!

Two possibilities are opened up, now.

One, that the application can be designed to accept audio inputs from the outside, and thus not only make synths and sequencers, but effects as well.

Second, well, opens up the possibility that systems of equations can be used to describe components of the synth, which can then be compiled into a set of equations that can describe both linear and non-linear behavior of a model. I guess I'm thinking in a SPICE-like way, but without the generalization (optimized purely for audio). This might be a flight of fancy, but this is brainstorming, after all.

On compile-time vs. run-time: why not make Omnibus a continuous integration environment? No need to double up the work, just make the compile-time behavior act as run-time with an implicit "freeze" each time the circuit is edited.

Hrm, a Google search for "continuous integration environment" turns up a definition about a software engineering practice, with stuff like automated nightly builds, automated unit testing, and the like. I can kinda see how that might apply here, but I have a feeling when you say "continuous integration", you mean it in a mathematical sense. You might have to explain that one to me, as Google is yielding zero results, returning nothing but eXtreme Programming sites.

No, I mean it in the software engineering sense. Whenever you edit the circuit it gets compiled and reloaded.

If you compile each "block" ("component"?) as separate object files and the circuit as another object file, it would be possible to cache the result. That is, when you only change the circuit, say add an component, only that component and the circuit need to be rebuilt making the "freeze" even quicker.

(And if you already couldn't tell, I'm very agile when it comes to programming. )

This is where I show my fundamental lack of knowledge in how this level of math works.

Does a Spice (actually, I'll say "Spice-like" for the purposes of this discussion) network need to be recompiled for any and every change made, or is it only if a routing or component type changes? If it's the latter, we can make it work. If it's the former, well, that would mean changing the value of a resistor means recompiling the entire network. If that's the case, then changing the cutoff of a filter with the mod wheel would mean recompiling the entire network for each sample.

There might come a point where we'll have to write code just to try some things out to see what happens. We could probably use Python for that, since we don't really need RT safety just to test some algorithms.

Consul wrote:Does a Spice (actually, I'll say "Spice-like" for the purposes of this discussion) network need to be recompiled for any and every change made, or is it only if a routing or component type changes? If it's the latter, we can make it work. If it's the former, well, that would mean changing the value of a resistor means recompiling the entire network. If that's the case, then changing the cutoff of a filter with the mod wheel would mean recompiling the entire network for each sample.

The cutoff parameter to the filter is data. The filter is instructions. Only instructions need to be compiled.
Above is the instructions. Data is supplied through argv.

That's true for your basic diff-EQ based DSP filter, yes. In hardware, the filter cutoff (we're only using cutoff as an example, keep in mind) is controlled by changing a resistance value in the circuit network. This is the part I don't know, unfortunately: If you compile a circuit model to a set of differential equations, are component values available as changeable parameters? Probably, yes.

The problem with that is that standard methods of modeling circuits with differential equations (the Laplace transform) lose the non-linear behavior of the circuit. As far as I can tell based upon what little I can find, Spice gets around this by doing one transform for the linear, and then some form of transform for the non-linear which is piecewise-approximated and involves the Newton-Raphson algorithm. I wish I could find more than that, but I'm stumbling around in the dark in a way that would make the Spice experts out there laugh at me. I can't afford $150 for a used copy of some book, though.

I don't know about a differential solver (to solve the equations) performing RT. An integrator, e.g. fourth-order Runge-Kutta, for integration yes.

The blocks (aka "component") are just small functions (just like the main function in the "parametrized Hello, World! example" above, ) or objects with inputs and outputs that can be compiled, that can be considered black box' from the outside. The circuit editor is just an Visual Programing Language tool.

As you can probably guess by now, I care as much (if not, more) about the non-linear characteristics of the circuit than the linear. Simulating the linear properties is well-established and a lot of documentation exists on how to do it. Nailing the linear and non-linear at the same time, that's the interesting problem that will result in a final program above and beyond what's been done before. Runge-Kutta, again, looks like a method that solves only for linear behavior. The thing is, Spice does know how to do both at the same time, and I really would like to know how, so that we could then possibly make our own optimized version for real-time audio.