> > I've got problems tracing this one. Question: why all those #defines
> > in oscillator.cpp? Is there a reason you're not using inheritance or
> > function pointers?
> this is just for getting more optimized code. This way the static
> wave-shape-routines of oscillator-class can be really inlined.
> Function-pointers for such *really small* methods would cost way too
> much CPU-time. The same for inheritance, which is nice, but slow
> (because of vtables etc.!). The defines form the basic-code which is
> some kind of "specialized" by the parameters and can be optimized a
> lot as the compiler exactly knows, which wave-shape-routes is used in
> all places and therefore can speed up things a lot... I know that this
> isn't a really nice solution, but the oscillator-class and their
> methods probably contain the mostly executed code at all.
> Just think whats happening when the user plays let's say three notes
> with triple-oscillator with chord=octave and range=3, this makes 27
> oscillators for each channel -> 54 for stereo -> 54 * 44100 =
> 2.381.400 cycles per second in oscillator::updateX(...)-methods! And
> this is just one instrument!
I don't know... I get your point but I've always left those decisions
(inlining and such) to the compiler.
Anyway, oscillator's current implementation doesn't allow you to change
the waveform once started. That beats the kind of interaction I'm
> Everything clear? ;-) Actually we'd need some really fast inline
> MMX/SSE-asm-code on intel-platform...
No way. What would happen to all those shiny multiarch packages in Debian?
Have you thought about parallel computing? LAN synthesizer...
> > Also, as an example, it modifies the behaviour of the oscillator's
> > volume knob. When changing the value, sound gets modified
> > immediately.
> > I'd appreciate any feedback because I'm planning to extend this to
> > the rest of the knobs.
> hmm... this is quite a complicated question, as I originally wanted to
> do all that when adding automation-support (via LFOs, self-drawn
> wave-shapes etc.) which also includes live changes of sound according
> to knob-changes.
Like that well-known commercial application, yeah, that's my primary target.
> I already began with that by introducing class
> automatableObject which provides a generic way to modify an objects
> state. Now we would have to made up controllers for
> automatableObjects, e.g. a user-wave-controller, an
> LFO-controller etc. Now these controllers need a view to be
> controllable by the users, which should be separated from the
> controller (-> model/view-programming). But these are details which we
> can discuss later ;-)
Ok, later, but... for starters :)
should be converted to
<time pos="n1" value="XX1"/>
<time pos="n2" value="XX2"/>