octal-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]