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

Re: [Linuxsampler-devel] Re: Prgramming Languages

[Juan L. <co...@re...>]

On Tue, 29 Oct 2002 15:55:41 -0600
"Richard A. Smith" <rs...@bi...> wrote:

> Benno:
> 
> Good to see you back in business again.  I'm looking forward to
> burning up the free time I don't have messing with linuxsampler.
> 
> My vote on programming languages would be C++.  Really, if you code
> things in a modular and decoupled way like all the books preach then
> you C looks and acts like C++ anyway.  Unless you are really doing
> some fancy template run time typing stuff there is little difference
> between C and C++.
> 

I couldnt agree more! So I second that vote.

> In 90% of the code you _won't_ need the speed advantage that C
> offers.  Which is largely a myth anyway its more the programmer than
> the language.  Yes there are some run time issues with C++ but unless
> you are really carefull about how you code your C it probally won't
> be the language choice that slows things down.  GCC is amazingly good
> at optimizing things once you tweak the parameters right.

Such is true, I wouldnt care about optimization either since gcc does a fantastic work.
I wrote my tracker in C++, and the mixing is actually faster than mikmod (which is written in C).

> 
> I grew up learning C and that doing things via pointers was always
> faster than using arrays.  Yeah, 10 years ago this was true but GCC
> broke me of this.  My best attempt at stepper motor control algo I
> was working on was soundly stomped on by just using arrays and
> letting GCC optimize.  
> 

The same happened to me recently while doing ARM development.
If you do things the "normal" way (ie using indexes and stuff)
in most cases gcc will be able to optimize better than if you
do the optimization yourself. I've even seen many cases recently
of people who tried to write asm modules to optimize and ended up
frustrated that gcc optimized more than their asm code.

> 
> Oh and I like the socket interface for the GUI to engine
> communication.  This allows them to be on different machines or even
> different architectures which considering the Mac heavy world that
> most studios have is probally a good thing.
> 

Yeah, I had in mind that musicans could build
a linux box only to dedicate it to a sampler..
(in other words, building a cheap sampler box, since most commercial
ones are over 2k USD). This way frontends can be done natively in any
OS without having to resort to more complicated things such as
the X protocol/Xlib/etc and without the sampler needing to have
all those libs installed.

And it could also be good if, in a future, we want to profit from this
project by selling PCs specially built, configured and tuned in 
such a way that they cant be distinguished from a real hardware samplers :)

Cheers!
Juan Linietsky

[Linuxsampler-devel] .

[Juan L. <co...@re...>]

.

lets hope this time makes it thru

[Linuxsampler-devel] Re: Prgramming Languages

[Richard A. S. <rs...@bi...>]

Benno:

Good to see you back in business again.  I'm looking forward to
burning up the free time I don't have messing with linuxsampler.

My vote on programming languages would be C++.  Really, if you code
things in a modular and decoupled way like all the books preach then
you C looks and acts like C++ anyway.  Unless you are really doing
some fancy template run time typing stuff there is little difference
between C and C++.

In 90% of the code you _won't_ need the speed advantage that C
offers.  Which is largely a myth anyway its more the programmer than
the language.  Yes there are some run time issues with C++ but unless
you are really carefull about how you code your C it probally won't
be the language choice that slows things down.  GCC is amazingly good
at optimizing things once you tweak the parameters right.

One thing I've learned over the years is that you can't predict where
you wil _really_ need optimization, things are just too complex.  You
just have to code in the cleanest most maintainable way and then come
back and optimize.  If you try to always code-for-performance you
usually end up with just the opposite.

I grew up learning C and that doing things via pointers was always
faster than using arrays.  Yeah, 10 years ago this was true but GCC
broke me of this.  My best attempt at stepper motor control algo I
was working on was soundly stomped on by just using arrays and
letting GCC optimize.  

And really if you get _that_ concerned about performance then you
should probally use arch specific assembly and/or things like
MMX/3dNOW type stuff like all the current audio encodeing/decodeing
libraries do. 

The management and maintaince benefits of C++ seem to be a clear
winner for a project like this.

Oh and I like the socket interface for the GUI to engine
communication.  This allows them to be on different machines or even
different architectures which considering the Mac heavy world that
most studios have is probally a good thing.

If you use a shared memory setup they you also greatly add to the
work level needed to use other programming languages for the front
end GUI.  So like, if I wanted to use my new favorite language python
a set of bindings would have to be written first but if its just a
socket then it's easy.


--
Richard A. Smith                         Bitworks, Inc.               
rs...@bi...               479.846.5777 x104                        
Sr. Design Engineer        http://www.bitworks.com   

[Linuxsampler-devel] testing 1,2,3

[Juan L. <co...@re...>]

just a test, excuse me.

[Linuxsampler-devel] Re: Linuxsampler-devel -- confirmation of subscription -- request 730633

[Juan L. <co...@re...>]

On Mon, 28 Oct 2002 14:26:55 -0800
lin...@li... wrote:

> Linuxsampler-devel -- confirmation of subscription -- request 730633
> 
> We have received a request from 24.232.150.110 for subscription of
> your email address, <co...@re...>, to the
> lin...@li... mailing list.  To confirm the
> request, please send a message to
> lin...@li..., and either:
> 
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
> 
> - or include the following line - and only the following line - in the
> message body: 
> 
> confirm 730633
> 
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
> 
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> lin...@li....
> 

Re: [Linuxsampler-devel] recompilation and inlining LADSPA speed issues, looping, enveloping

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

On Tue, Oct 29, 2002 at 07:50:32 +0100, Benno Senoner wrote:
> Ah interesting, so there are problems when the inner loop is getting to
> big.

Yes, mostly for the cache reasons you mentioned.

> Any ideas what the best compromise looks like (of course it depends from
> the cache size but it would be cool to have a method to figure it out).

I think it would be hard/bad to try. Refactoring C(++) code is really
hard, I think its best to leave it as atomic as the DSP programmer made
it. You wil be supprised how efficient it is, modern CPU are heavily
optimised for small loops.

> regarding the CV stuff. Is CV the ideal (and efficient) model to use in
> a sampler ? Excuse my ignorance but I have not a big familiarity with
> the CV paradigm (everything is a control value), any useful URLs that
>  handle his topic ?

Hard to say if its efficient. It's a tradeoff, it hadles some things very
well (ie. rapidy, unpredicatbly or continuously changing control values),
but it handles things that are mostly constant less efficiently than event
based systems.

I like it becasue it is easy to understand, model and process, and it has
good worst case performance.

I dont know of any resources, but the principal is very simple.
Frequencies are represented as an exponential scale of octaves, amplitudes
and time linearly. This covers everything and is very modular.

The obvious system for a sampler would be events for MIDI notes generating
sample buffer activity, and CV for internal parameter control. This should
get the best of both worlds. It is how SSM works, and that is very
efficient and versatile.

I am biased in favour of CV, so you should mayeb look for some oposing
arguments, I'm not aware of any ;)

- Steve

Re: [Linuxsampler-devel] recompilation and inlining LADSPA speed issues, looping, enveloping

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

Ah interesting, so there are problems when the inner loop is getting to
big.
Any ideas what the best compromise looks like (of course it depends from
the cache size but it would be cool to have a method to figure it out).
We could run some heurystics tha tries to break a large signal
processing chain into smaller loops till best performance is achieved.

regarding the CV stuff. Is CV the ideal (and efficient) model to use in
a sampler ? Excuse my ignorance but I have not a big familiarity with
the CV paradigm (everything is a control value), any useful URLs that
 handle his topic ?

cheers,
Benno


Steve wrote:

> in linuxsampler it would be better to process all in a single pass
> eg:

Not neccesarily, once the inner loop goes over a certain size it becomes
/very/ inneficient. Infact one of the common ways of optimising bigish
plugins is to break them into smaller passes.

Obviously you wont win every time, but I think inlined finction calls to
LADSPA run() routines will be faster on average.

Obviously, things like mixers should be native, but not for eg. ringmods
(multipliers), a decent ringmod has antialiasing code in (though mine
doesn't, yet).

> An additional issue about LADSPA is that it is only suitable for audio
> processing but not for midi (or event)-triggered audio generation.

No, its not suitable for MIDI, but it can certainly do unit generation,
infact AFAIK the only bandlimited oscilators for Linux are LADSPA
plugins.
You just the the CV model for triggering.

- Steve

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

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

Steve Harris wrote:
> On Tue, Oct 29, 2002 at 02:52:45 +0200, Antti Boman wrote:
>>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 
> 
> I think ti would have to be a different process. If you exec() gcc it will
> take over the current process.

Ah, of course, didn't think of it well enough. fork() or rather not.

-a

Re: [Linuxsampler-devel] recompilation and inlining LADSPA speed issues, looping, enveloping

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

On Tue, Oct 29, 2002 at 04:25:41 +0100, Benno Senoner wrote:
> The process() code of LADSPA usually does
> 
> for(i=0;i< numsamples; i++) {
>   sample[i]=.....
> }
...
> in linuxsampler it would be better to process all in a single pass
> eg:

Not neccesarily, once the inner loop goes over a certain size it becomes
/very/ inneficient. Infact one of the common ways of optimising bigish
plugins is to break them into smaller passes.

Obviously you wont win every time, but I think inlined finction calls to
LADSPA run() routines will be faster on average.

Obviously, things like mixers should be native, but not for eg. ringmods
(multipliers), a decent ringmod has antialiasing code in (though mine
doesn't, yet).

> An additional issue about LADSPA is that it is only suitable for audio
> processing but not for midi (or event)-triggered audio generation.

No, its not suitable for MIDI, but it can certainly do unit generation,
infact AFAIK the only bandlimited oscilators for Linux are LADSPA plugins.
You just the the CV model for triggering.

- Steve

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

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

On Tue, Oct 29, 2002 at 02:52:45 +0200, Antti Boman wrote:
> 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 

I think ti would have to be a different process. If you exec() gcc it will
take over the current process.

- Steve

Re: [Linuxsampler-devel] recompilation and inlining LADSPA speed issues, looping, enveloping

[Phil K. <phi...@el...>]

Hi,

UDP would probably be better than TCP for GUI control, it's easier and
faster to implement.  From the remote control work I've done I've tried
to keep the mappings as close to MIDI as possible as this allows remote
MIDI hardware to interface easier, but this does mean a decision whether
to use MIDI's 7 bit resolution or to move up to a higher resolution. A
lot of performers like to 'twiddle knobs' so sticking with MIDI is a
plus side.

Using a networked interface also allows you to mix and match what
toolkits for the GUI.  QT is nice and fast and the signal and slot
mechanism is really easy, even for a C developer.  The QT Designer can
rapidly put together a basic interface.  GTK is another good choice.

Phil

On Tue, 2002-10-29 at 15:25, Benno Senoner wrote:
> Hi,
> I thought about using "interpreted" LADSPA as a preview and 
> subsequent compilation of the code.
> 
> Well, I do not see major hurdles to do this, but inlining LADSPA code, 
> even it results in faster code than calling a chain of LADSPA plugins,
> it is still suboptimal especially with very small buffer sizes.
> 
> The process() code of LADSPA usually does
> 
> for(i=0;i< numsamples; i++) {
>   sample[i]=.....
> }
> 
> this means that chaining (at source level) two LADSPA plugins it results
> in:
> 
> for(i=0;i< numsamples; i++) {
>   sample[i]=.... (DSP algorithm 1)  
> }
> for(i=0;i< numsamples; i++) {
>   sample[i]=..... (DSP algoritm 2)
> }
> 
> in linuxsampler it would be better to process all in a single pass
> eg:
> 
> for(i=0;i< numsamples; i++) {
>   sample[i]=.... (DSP algorithm 1)  
>   sample[i]=..... (DSP algoritm 2)
> }
> 
> So while being able to chain LADSPA plugs at source level is still very
> useful, I would opt to provide "native" signal processing units like
> adders, multipliers, filters etc too because they can be inlined without
>  requiring to loop again over the whole buffer.
> 
> I think sample-by-sample inlining increases the performance quite a bit
> in the case of very small buffer sizes (my usual 32 sample buffer test
> case).
> What do you think ?
> How about caching isssues ? From the point of view of the cache is
>  sample-by-sample inlining preferable over ladspa-style chaining ?
> 
> An additional issue about LADSPA is that it is only suitable for audio
> processing but not for midi (or event)-triggered audio generation.
> This means we need internal audio unit generators anyway.
> It would be cool to modularize everything and let almost all the audio
> rendering code stay in the audio unit source files.
> This means that as an advanced audio hacker you can easily fire up your
> favorite editor and tweak the modules (or copy and modify them) to suit
> your needs.
> 
> The only thing that is IMHO tied to the disk streaming engine is the
> sample looping part since both the audio and the disk thread need to be
> aware of looping information. 
> I'm not a big hardware sampler expert but since we want flexibility I
> thought about using a linked list of loop points in order to allow
> arbitrary looping.
> eg a list of   startpoint, endpoint  where the single looped parts of
> the sample do not need to be interconnected each other.
> (with this kind of looping you could even load one single sample that
> contains the sounds of a drumset and trigger them in such a way to form
> a drumloop :-) )
> 
> Regarding the enveloping I made some tests and I think I'd opt for the
> same principle as the looping stuff: a list of linear or second order
> segments with a starting point and a dx  value(or in the 2nd order case
> an additional ddx value).
> This would allow to apply arbitrary envelope curves to parameters
> (volume, filter freqs) with low CPU and memory usage.
> Of course if you want to provide only simple ADSR support you can easily
> generate an appropriate envelope table for it.
> 
> Since a sample is comprised of attack, looped (in our case we can have
> many looping segments) and release phase, we could have different
> enveloping curves for each phase.
> This would mean that the enveloping tables get switched when we go from
> one phase to the next one.
> This could be useful for thing like vibrato effects where the vibrato is
> applied only during loop and release phase but not in the attack phase.
> (same applies to filter freqs, pitch etc ... I think one could create
> pretty cool sounds with these things alone).
> 
> Regarding GUIs: I agree with Juan that we need to decouple the sampler
> and the GUI completely (he even proposed using a TCP socket so that you
> can remote control the sampler form another machine).
> I'd go with shared mem/local IPC but if you say TCP has advantages so
> let's go for it.
> 
> I think over the long term the GUI is important especially when support
> for what you hear is what you get is implemented, aka where you can edit
> samples and sounds without resorting to an external editor that saves
> the sample to file which the sampler is forced to reload into mem.
> 
> Here I guess that Josh Green (the author of smurf/swami) would be very
> helpful in that area.
> 
> cheers,
> Benno
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] recompilation and inlining LADSPA speed issues, looping, enveloping

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

Hi,
I thought about using "interpreted" LADSPA as a preview and 
subsequent compilation of the code.

Well, I do not see major hurdles to do this, but inlining LADSPA code, 
even it results in faster code than calling a chain of LADSPA plugins,
it is still suboptimal especially with very small buffer sizes.

The process() code of LADSPA usually does

for(i=0;i< numsamples; i++) {
  sample[i]=.....
}

this means that chaining (at source level) two LADSPA plugins it results
in:

for(i=0;i< numsamples; i++) {
  sample[i]=.... (DSP algorithm 1)  
}
for(i=0;i< numsamples; i++) {
  sample[i]=..... (DSP algoritm 2)
}

in linuxsampler it would be better to process all in a single pass
eg:

for(i=0;i< numsamples; i++) {
  sample[i]=.... (DSP algorithm 1)  
  sample[i]=..... (DSP algoritm 2)
}

So while being able to chain LADSPA plugs at source level is still very
useful, I would opt to provide "native" signal processing units like
adders, multipliers, filters etc too because they can be inlined without
 requiring to loop again over the whole buffer.

I think sample-by-sample inlining increases the performance quite a bit
in the case of very small buffer sizes (my usual 32 sample buffer test
case).
What do you think ?
How about caching isssues ? From the point of view of the cache is
 sample-by-sample inlining preferable over ladspa-style chaining ?

An additional issue about LADSPA is that it is only suitable for audio
processing but not for midi (or event)-triggered audio generation.
This means we need internal audio unit generators anyway.
It would be cool to modularize everything and let almost all the audio
rendering code stay in the audio unit source files.
This means that as an advanced audio hacker you can easily fire up your
favorite editor and tweak the modules (or copy and modify them) to suit
your needs.

The only thing that is IMHO tied to the disk streaming engine is the
sample looping part since both the audio and the disk thread need to be
aware of looping information. 
I'm not a big hardware sampler expert but since we want flexibility I
thought about using a linked list of loop points in order to allow
arbitrary looping.
eg a list of   startpoint, endpoint  where the single looped parts of
the sample do not need to be interconnected each other.
(with this kind of looping you could even load one single sample that
contains the sounds of a drumset and trigger them in such a way to form
a drumloop :-) )

Regarding the enveloping I made some tests and I think I'd opt for the
same principle as the looping stuff: a list of linear or second order
segments with a starting point and a dx  value(or in the 2nd order case
an additional ddx value).
This would allow to apply arbitrary envelope curves to parameters
(volume, filter freqs) with low CPU and memory usage.
Of course if you want to provide only simple ADSR support you can easily
generate an appropriate envelope table for it.

Since a sample is comprised of attack, looped (in our case we can have
many looping segments) and release phase, we could have different
enveloping curves for each phase.
This would mean that the enveloping tables get switched when we go from
one phase to the next one.
This could be useful for thing like vibrato effects where the vibrato is
applied only during loop and release phase but not in the attack phase.
(same applies to filter freqs, pitch etc ... I think one could create
pretty cool sounds with these things alone).

Regarding GUIs: I agree with Juan that we need to decouple the sampler
and the GUI completely (he even proposed using a TCP socket so that you
can remote control the sampler form another machine).
I'd go with shared mem/local IPC but if you say TCP has advantages so
let's go for it.

I think over the long term the GUI is important especially when support
for what you hear is what you get is implemented, aka where you can edit
samples and sounds without resorting to an external editor that saves
the sample to file which the sampler is forced to reload into mem.

Here I guess that Josh Green (the author of smurf/swami) would be very
helpful in that area.

cheers,
Benno

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