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

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

On Mon, Nov 04, 2002 at 06:42:38 +0100, Benno Senoner wrote:
> > I dont get the impression that DLS is anywhere near rich enough to do
> this
> > job, it would need to be something pretty expressive.
> 
> That's why I am against this one-size-fits-all sample format.
> At least if we keep the engines separate we do not risk making mistakes
> in designing
> a format that later tuns out to be a PITA because of design errors.

I agree, I just didn't want to be accused of proposing an enourmous task
;)
 
> Why am I in favour of a modular design (graphical signal editor etc)
> instead of
> hardcoding (as Juan L. proposed) popular engines ?
> 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.

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.

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.

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