linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

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

[Antti B. <ant...@mi...>]

Steve Harris wrote:
> For something like
> _______    ___________
> |_osc_| -> |         |      ______________
>            | ringmod | ---> |_compressor_| -> output
>   input -> |_________|
> 
> I would guess under two seconds to build the .c, compile it and dlload()
> it.

Seems fine. If it's not a Plain Stupid Idea (tm), compiling could be 
made in a different thread. OTOH, if you have the possibility to test 
your changes without compiling, a sip of coffee when it's all done is 
never a bad idea.

-a

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

[Steve H. <S.W...@ec...>]

On Tue, Oct 29, 2002 at 02:18:38 +0200, Antti Boman wrote:
> >Eg. If we support chains of plugins the user can mess about with these as
> >much as they like, then hit the compile button and a few seconds later
> >everything will get faster without changing the sound. Obviously plugins
> >that are only available in binary form wil still have to be called, but it
> >will still work.
> 
> This shows I still have to learn more, as I wouldn't have thought of 
> such ingenious way. Did you mean that compile button compiles them all 
> at the same time? How much time do you think it would take, for average 
> use? Ok, "define average use" ;)

I think the idea was Juan's.

For something like
_______    ___________
|_osc_| -> |         |      ______________
           | ringmod | ---> |_compressor_| -> output
  input -> |_________|

I would guess under two seconds to build the .c, compile it and dlload()
it.

- Steve

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

[Antti B. <ant...@mi...>]

Steve Harris wrote:
> An advantage to this is that we have have perfect symmetry between the
> backend, transparent dynamic compilation accleration and LADSPA plugins.
> 
> Eg. If we support chains of plugins the user can mess about with these as
> much as they like, then hit the compile button and a few seconds later
> everything will get faster without changing the sound. Obviously plugins
> that are only available in binary form wil still have to be called, but it
> will still work.

This shows I still have to learn more, as I wouldn't have thought of 
such ingenious way. Did you mean that compile button compiles them all 
at the same time? How much time do you think it would take, for average 
use? Ok, "define average use" ;)

-a

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

[Antti B. <ant...@mi...>]

This obviously didn't get to the list, so I'm forwarding:

Sebastien Metrot wrote:
> Hi all!
> 
> I think one would be a fool not to find C++ messy but most of the time you
> can get around the messy bit and build a very powerful engine. On the other
> way I think only the core engine (DSP stuff) should be in C/C++ with a good
> set of Python bindings for the GUI and general management stuff. What do you
> think guys?
> 
> Sebastien

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

[Antti B. <ant...@mi...>]

Benno Senoner wrote:
> 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++.

I have to choose the latter one. Or the main reason is that I don't 
master C++, so there's this huge step to code something into the code 
created by "a wizard", and have guts to send a patch which might be 
rejected. That's my problem, though, and I'm also willing to re-learn 
the language.

Also, there's this C-only area in your plans, and that might be the one 
where I could concentrate on.

> 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).

I understand that the OO paradigm works well here, it's just that a C++ 
novice like myself finds C++ a bit messy to manage ;)

> 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.

Sounds reasonable, even well-thought :)

I'll try to stuff myself in when it's time. I know I'm not qualified 
enough to do the most low-level hassle, as I'm still learning about the 
requirements for low latency.

-a

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

[Steve H. <S.W...@ec...>]

On Tue, Oct 29, 2002 at 12:06:31 +0100, Benno Senoner wrote:
> 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.

An advantage to this is that we have have perfect symmetry between the
backend, transparent dynamic compilation accleration and LADSPA plugins.

Eg. If we support chains of plugins the user can mess about with these as
much as they like, then hit the compile button and a few seconds later
everything will get faster without changing the sound. Obviously plugins
that are only available in binary form wil still have to be called, but it
will still work.

If we made the output(s) of the dynamic compilation valid LADSPA plugins
then we only need to deal with one DL binary type too.

> 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

This seems like a good policy.

- Steve

Re: [Linuxsampler-devel] Programming language

[Steve H. <S.W...@ec...>]

On Tue, Oct 29, 2002 at 11:15:10 +0200, 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.

I agree with this FWIW. I am willing to use c++, as long as we dont use
anything too hairy, but would rather not. I dont see any need for
templates or exceptions for example.

the only thing that looks like it should be a class are the ringbuffers,
and I've seen (and written) very clean C OO-style ringbuffers. People
sometimes get carried away with OO design.

Arguments in favour of C are the maximum compatibility with libraries and
stuff, and speed (arguably).

Arguments in favour of C++ are stronger typing.

- Steve

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

[Linuxsampler-devel] Programming language

[Antti B. <ant...@mi...>]

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

[Linuxsampler-devel] Uploaded diagram: streaming samples from disk

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

Hi,

Added a diagram that shows how LinuxSampler handles the streaming of
samples from disk.

http://linuxsampler.sourceforge.net/images/diagram1.png

The sample data of each active voice is passed from the disk thread to
the audio thread using lock-free ring buffers. This ensures that the
audio thread never blocks and gives the disk thread enough time to
refill the buffers associated to each voice.
The first part of each sample must be cached in RAM (not shown) in order
to allow low latency sample triggering.
The MIDI sensor thread issues commands to the audio thread (voice
start/stop commands) using an asynchronous (lock-free) queue.
In a similar way, the audio thread issues commands to the disk thread
which start/stop the streaming of voices from disk.

Benno