A draft whitepaper of my parameterization idea

Everything and anything, but nothing about the LinuxSampler project.
Post Reply
User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Fri Mar 28, 2008 11:03 pm

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).
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 3:09 am

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. :)
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sat Mar 29, 2008 1:00 pm

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.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 2:26 pm

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.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sat Mar 29, 2008 2:42 pm

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. :mrgreen: )
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 3:00 pm

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.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sat Mar 29, 2008 3:11 pm

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.

Code: Select all

int main(int argc, const char** argv)
{
    print("Hello, %s!", argv[1]);
    return 0;
}
Above is the instructions. Data is supplied through argv.
Last edited by dahnielson on Sat Mar 29, 2008 3:28 pm, edited 1 time in total.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 3:25 pm

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.
Darren Landrum

User avatar
dahnielson
Moderator
Posts: 632
Joined: Wed Jan 23, 2008 11:25 pm
Location: Linköping / Tranås, Sweden
Contact:

Re: A draft whitepaper of my parameterization idea

Post by dahnielson » Sat Mar 29, 2008 3:37 pm

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, :mrgreen: ) 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.
Anders Dahnielson

Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux

User avatar
Consul
Moderator
Posts: 189
Joined: Wed Jan 23, 2008 11:19 pm
Location: Port Huron, Michigan, USA
Contact:

Re: A draft whitepaper of my parameterization idea

Post by Consul » Sat Mar 29, 2008 4:00 pm

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.
Darren Landrum

Post Reply