Re: [Linuxsampler-devel] Supporting various sample library formats

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

Steve wrote:
> > Well assume you write a GIG loader and engine. But now you discover
the
> > giga engine is
> > too limited. Fire up the signal editor enhance the signal
> > routing/processing features of the engine,
> >  compile and play your .GIG files with the new enhanced engine.
>
> Thats very compelling, but my feeling is that its better to support
> features like that in principle, but target a more reasonable feature
set
> for an initial release. My experience of large projects with big
ambitions
> is that people loose interest and they never get finished.

I agree that about the unfinished projects I tend to loose interest too,
but
this time I will concentrate only on this project since it would be very
nice
 of being able to deliver something that is usable in the real world.

Regarding the recompiler a too big task:
I would not say that: the streaming engine is more or less ready, just
take the
routines and algorithms and encapsulate them into a cleaner framework.
For the signal  processing part we have most stuff ready to use
(reverb,filters,ladspa plugs) and I don't think that writing a framework
that
is able to build simple signal networks is such a big task.
Speaking of GIG I think it will take a bit of time to figure out all
params embedded in the
file (although Ruben van Royen  and Paul K. have already done some work
in this field)
 and map them correctly to the engine. (correct emulation of envelopes,
filters ecc).

>
> If you set a reasonable target for a first release (but still with a
> good, extensible API), you will get there quicker, you will get users
for
> testing earlier, and the devleopers will be more motivated.

not sure if this will bring us more long-term advantages ... what do
others say ?
As said for the beginning the recompiler can be very simple since we can
extend it later
without needing to introduce radical changes).

>
> OK, you will have to throw away some code when you want to generalise
the
> engine, but I think this is very mworth it. Espcially as you will
learn
> things from the first (or in Benno's case second :) implementation.
>
> I would like to see a first milestone of a realtime, jacked sampler
that
> can receive midi and play a subset of GIG samples fomr disk, with a
clean
> and extensible deisgn.

The problem is this clean and extensible design ... personally I think
it is represented
 by the recompiler. Perhaps I am wrong , that's why we are discussing
these issues on the list here.

> PS I'm not sure that I agree with supporting OSS, it imposes design
> decisions that don't make much sense in the long term.

> - Steve

Juan says when using JACK, instead of exporting only the stereo output
we should export each
MIDI channel (so that we can route instruments to arbitrary
destinations). This is ok for JACK and
 introduces flexiblity but I do notsee supporting  OSS as a problem:
just export the stereo output
and use a simple OSS backend that simulates callback:

while(1) {
  data=audio_call_back();
  output_oss(data);
}

The prefered method will be of course JACK but I think for testing,
debugging and tuning purposes
 OSS and ALSA are ok. (plus in case you want to dedicate a machine only
for sampling you can work
 without jack).

Regarding JACK we will probably need to use the in-process model (which
is actually not used much AFAIK)
 in order to achieve latencies at par with direct output so this needs
further research.
My tests with direct OSS output show that it is possibile to achieve
3msec latency on a PII+ with the sampler so
 we want to get out these numbers from jack too so we need to test it
first in a direct output enviroment and then
in conjunction with jack (or better implement both backends from the
beginning and allow you to switch it via cmdline).

regarding the AKAI samples: Steve says akai samplers were quite limited
in terms or RAM availabilty (32-64MB)
 and since akai samplers allow some funny stuff like modulating the loop
points I was wondering what you thing about not
using disk streaming for this format.
How about the s5000/6000 series ? what is the maximum RAM configuration
? Do they allow nasty loop point modulation too ?

And since we speak about looping  I was wondering how looping is handled
in most hardware and software samplers:

do most of them use loop-until-release (eg looping part is looped and
after release the sample gets played as it was not looped)

or infinite looping: when you release the loop is still played but the
volume fades to zero within a certain time. (release part not used)

When implementing these kind of looping techniques in a disk streaming
sampler, the first looping technique requires caching a region (let's
say 64k samples)
past the final loop point in order to give the engine the time to refill
the ring buffers from disk. This means the memory consumption almost
doubles
for looped samples over oneshot samples. With very large sample
libraries this could mean that RAM can become scarce. (but I am not sure
if large
libraries of looped samples exist).

The second looping method is easy to implement since you can let the
disk thread refill re ringbuffers with the looped areas and then when
you release
the key the volume simply fades to zero within a certain amount of time.

Anyway it is not hard to implement loop-until-release and the engine can
easily be designed to support both in order to give the user the best of
both
 worlds.

If you have experience with hardware or software samplers please share
your thoughts on the issues I mentioned on the list.
thanks,
Benno

--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.