[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linking libraries in machines.
From: |
luka |
Subject: |
Re: Linking libraries in machines. |
Date: |
Sat Mar 17 17:24:02 2001 |
good to see some debate on the question i ask myself every day about twenty
times:
what goes into gearlib? what stays out?
since i expect this debate to last, well, as long as gearlib remains in
development, i won't pretend to give any final answers right now. but i have
some thoughts and proposals... and here they are. first, a definiton:
Gearlib should provide functions most useful to the octal machine developer.
Its use should make machines easier to write and easier to understand. Code
should be general and portable, with optional specific optimizations for
certain popular hardware platforms. Machines that use gearlib should appear
consistent and robust to the octal user.
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, ...)
There are a lot of 'tricks' floating around the net, collected in various
cookbooks. We can tailor them for octal, and include them in gearlib so they
become easier for the developer to use and hopefully harder to misuse or plain
misunderstand. Some of them will fall in above categories, some won't - some
will actually be general, most will probably be tied to the way octal sets
things up. Many times more than the code it's important to have a good text
that explains where the algorithm is appropriate and when not so much...
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)
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.
> > On the other side, is reasonably to include whole FFTW in Gearlib?
maybe, if many machines use FFTW, we can make it a dependency and create a kind
of frontend. neil mentions performance problems with relying too much on FFT -
but as i understand FFT can be used for many things - like filter design and
power estimation, where there is less work 'per second'. Of course, you could
take a buffer, FFT it, manipulate the frequency-domain results and finally
inverse FFT it, creating a digital filter, but the big question is, how many
percent of a tipical octal users's cpu will one such machine eat? quite
possibly the answer is 'too many'. someone just has to try...
> > Should we include in Gearlib every posible code piece that a developer could
> > need and convert-it to "the mother of all sound libraries" ?
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.
whoa, what a novel... need a break now. :)
LF