RE: Linkging libraries in machines.

[Jared]

        Firstly, I would like to say that a lot of people got carried away
with the specific example of the FFTW library that I gave.  Say I had
super optimized kick-ass fast library x and I wanted to use it? The same
prblems present themselves.

> few categories i see:
>       machine parameter bookkeeping (reporting and updating)
>       fast waveform generators (oscillators) 
>       envelopes and lfos 
>       wavetable helpers (pitch shifting, scaling,...)
>       channel functions (poliphony)
>       fast trigonometric functions    
>       fast filters and (sometimes not so fast) filter design routines 
>       unit conversion routines (dB <-> amp, ...)
>       music theory functions (scales, rhytms, chords, ...)

        I think this is the point I ask Dave "Please can we have more
widgets?". And not just widgets for when the machine is going.  For filter
design routines, you are going to need a relatively large set of complex
design tools (graphs, envelop editors etc...) at startup, but once this is
done, you'll just want to use the filter with, say, amplitude control.

<snip>

> 
> Accuracy in gearlib will be often traded in for speed. Maybe we can
> implement some concepts which let the machine coder, the host
> application or even user choose between different approaches to doing
> the same thing (depending on available cpu power or mode of operation
> - real time vs. offline rendering)

        Does/Will Octal have the ability to do offline rendering? That
would make it really cooooool. A tracker, and with the right
machines/generators you get a sound editor for free.

> 
> about libraries: don't be afraid to use any library besides gearlib in
> your machines! if you think FFTW (or foobarlib) is the right choice
> for your machine, use it! those users who can't compile or install a
> library will get your machine anyway trough binary releases. a bigger
> problem is portability - some libraries are not available on a lot of
> platforms. if you want your machine to live a longer and wi(l)der
> life, choose wisely.

        This, I feel, is starting to get dangerous. Unless I build and
release fat statically linked machines, we are going to need some form
of dependancy checker.  I smell rpm/dpkg/your package manager of
choice....

> i think not. we want to collect good (best) solutions particularly for
> our problem, ie generating or processing sound buffers fast (and
> reasonably accurately), plus dealing with the octal api and other
> issues specific to unit generators. we also want scenarios where
> adding some code to gearlib would expand the capabilities or increase
> performance of all conforming machines. we want to work as closely as
> possible with machine developers and core developers, but as these
> groups all overlap this communication shouldn't be too hard.

        Maybe we should put together a list of basic machines/routines to
kick gearlib off?  Maybe using the sourceforge set up, people could ask
for or be assigned tasks?
J