Re: Swami as a LinuxSampler patch editor front end (was Re: [Linuxsampler-devel] RAM sampler module proposal)

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

On Sun, 2002-11-10 at 20:34, Josh Green wrote:
>
> > Of course swami needs a powerful playback engine in order to provide
> >  what you hear is what you get feel.
> > This means that ideally the instrument's editor and playback engine
> >  should go hand in hand so that the editor can match the engine's 
> > capabilities and viceversa.
> > 
> 
> I have been designing Swami with exactly this type of modularity in
> mind. I'm looking forward to working with the LinuxSampler project :) 

nice to have you on board !
Well basically I think your idea is very good but since I am not an
expert in terms of "live editing of samples" I have no clear idea
what the right solution looks like.

One of our problems is that some samples reside in ram and some are
streamed from disk with some caching.
This means that the editor must be aware about these issues.
These are dependent on the sample and engine format thus it is probably
wise to keep that kind of code (without duplicating it at editor level)
within the sampler.
As Juan L. suggested,when providing a GUI for the sampler it is probably
the best to control it through a TCP socket so that you can separate the
engine from the front end.
(eg controlling the sampler remotely on a separate machine , even a
windoze box that runs a ported gtk/qt/java GUI :-) ).

So if you were asking me I would apply the same paradigm to the 
instrument editor too.
By serializing the access via a socket you do not risk race conditions
and the thread that handles the parameter / instrument manipulation can
be optimized to not interfere with the real time engine.

I think remote editing will be advantageous for the future because it
could be that the studio professional might have an "audio processing
farm" which is networked with the front end machine which can control
each engine in real time.

What do you think ?
Josh can you briefly describe what a general instrument editor must
provide.
 (since I am not familiar with what capabilities an editor has to
provide )

(eg, manipulating the parameters, looping, assign samples to keymaps
etc)

Keep in mind that we are going to work with both in-ram and on-disk
samples possibly very very large libraries. (hundreds of MB / several
GB).

Plus there is the fact that we want a truly modular sampler where you
can wire together basic audio building blocks which represent the
 final instrument.
That means some kind of loader module (possibily save module too) needs
to be written in correspondence of each engine.
This may sound like sci-fi or some but it isn't and we plan to start
with very basic stuff (like a simple RAM sampler with only basic
modulation stuff). I think it will pay off to go that way because once
the concept is implemented very cool things can be done and I think that
stuff like building an efficient AKAI,GIG,SF2 etc sampler will advance 
very quickly.

Thoughts ?

Benno



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