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

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

On Mon, 4 Nov 2002 17:15:48 +0000, Steve Harris wrote:

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

It will follow the old 80-20 rule.  Probally only 80% of the feature
set will see any wide-spread use but implementing that final 20% will
take another 80% effort and usually complicates thing up quite a bit.

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

I agree.  Many a time I have designed what I thought to be the
perfect system for the task at hand.  Only to be blindsided by either
some nasty-real-world effect or some other part of the system that
can't really live up to its original design specs.

Most systems are just too complicated to be able to get a good handle
on all the possible input values.  

I would fully expect that several modules will need to be overhauled
somewhere after the first stable releases are available.  Now we seem
to have a wealth of experienced developers on this list and Benno has
already flushed out most of the issues with streaming from the disk
so I think things will be fairly well designed from the start but
there's always something lurking in a dark corner.
   
Small simple incremental goals seem to be a very good choice to me. 
And if we try to minimize the intermodule dependance what does need
to be overhauled shouldn't be too painfull.

Also the earlier some sort of engine exists the sooner UI
developement can progress.  The UI for this thing is one area where
we can really come up with some innovative stuff.  I personally don't
have  a whole lot of experience with samplers (disk or hardware) but
my studio friend Mike Bailey has bunches and he's got what I think
are some really good UI ideas with managing large sample sets and
studio type use.  Or at least I've listened to him pick apart the UI
for most of the commercial products.  I'd like to try and build him a
box that can take the place of his current GigiStudio setup.


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