Re: [Linuxsampler-devel] Programming language & other issues

[Benno S. <be...@ga...>]

Hi,
I had a similar discussion on IRC with Steve Harris yesterday on the LAD
IRC channel.
Seems that many (even hardcore) developers prefer C over C++ or (like my
situation some time ago) are too lazy to experiment a bit with C++.
As you can look from my proof-of-concept code on the linuxsampler page, 
I used C++ and must say that I am quite satisfied with the resulting
speed and elegance of code.
I'm not a hardcore C++ user so I did not make use of advanced stuff
and even if I were, I woudn't use that kind of stuff since it could
potentially slow down execution speed.
What I did is basically wrapping C algorithm into C++ classes.
I made use of templates in the ringbuffer class (see ringbuffer.h file)
as suggested by Paul D. The resulting assembly code (of the templated
ringbuffer) is excellent and very fast and elegant.

I'm open to any suggestion regarding C vs C++ , but I guess an usable
and full fledged LinuxSampler will become quite a big beast so I fear
that a pure C solution will become a bit messy to manage. (IMHO).

OTOH we plan to use recompilation techniques in order to dynamically
generate almost arbitrary signal flow diagrams within the sampler.
This means that we will need to write sort of units (eg
adder,multiplier, N-pole etc etc) in source form that are assembled into
a C file which gets compiled and dynamically loaded at run time.
So I think most of the programming will be in C (algorithms, units etc)
while I would suggest for some basic infrastructure in C++. (opinions ?)
The goal is that once the basic infrastructure is in place we can fully
concentrate on writing new FXes, filters, algoritms, sample importers,
GUIs etc.
Steve even suggested to use his LADSPA XML templates that we could
inject in source form in order to generate (almost) arbitrary signal
flow structures that compiled are almost as fast as a hand coded version
 since all calls to the LADSPA API get eliminated due to code inlining.
In particular the speed difference is big when using very very small
 buffer sizes (like my tests that were performed with 3 x 32 sample
buffers).
My paranoid nature make me tend to design systems and apps that work in
 extreme conditions so I suggest to try to test and tune LinuxSampler
with 2-4msec latencies from the beginning. Of course if people want to
run it with 10-20msec latencies it will work even better. (higher
latencies means higher number of voices due to less overhead).

thoughts ?  
cheers,
Benno

On Tue, 2002-10-29 at 10:15, Antti Boman wrote:
> Hi,
> 
> I know you're in the design phase of LinuxSampler, but have you decided 
> the programming language yet? I suppose it's C or C++, but which one?
> 
> Why I'm asking this is that I'm much more familiar with plain C, and 
> thus much more willing to contribute my coding skills to the project if 
> plain C is used. OTOH, wouldn't be bad refreshing my C++ skills.
> 
> -a
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel