Re: [Linuxsampler-devel] Re: GUI screenshot , Linuxsampler status,thoughts etc (long)

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

Hi Florian, I fully agree what you said.
Know what ? I too do not love modular synths too much
since often (if you are not a good user of modular synths)
you end up wasting your time trying to compose cool sounds instead of
making real music.

BUT....

This modular GUI is only to compose the "load&play" engines.
Yes it seems a bit strange approach and many suggested "why not 
write a hardcoded load&play sampler engine instead to go through this
 painful modular route" ?

Well, the goal is to have a sampler that eats any format and implements
as many engines as possible.
But hardcoding multiple engines like AKAI, GIG , SF2 is a bit of a PITA
and you end up writing duplicate code, algorithms etc not to mention
that once the engine it coded it is painful to add new functionality.

The first milestone is to implement enough basic building blocks
(modules) so that you can build an AKAI S1000/2000 load and play engine.

Once the dsp network is assembled you can just forget about the modules
etc. The downcompiler will produce an akaiengine.so DLL.
Now to complete your load&play sampler you just
need to write an associated GUI that exports only the stuff you like.
Eg you can load an arbitrary number of intruments (eg via a file dialog)
assign them to the desired MIDI port/channel, tweak the instrument's parameters
(filter values, envelope data etc).
At this point the load&play sampler is done.
The difference between a hardcoded load&play sampler and that one is almost
zero.
But we have the advantage that we can add new file formats and new engines
(good .GIG playback is one of the most important goal after AKAI support
will be complete).

As said the modular GUI will be here only for experts or for those that
liek to experiment with building new sounds, but the majority of the userbase
will probably just use the load&play sampler.

I think this will satisfy everyone hopefully you too ;-)

Why I started with the coding of the modular GUI ? 
Simple: it is needed for building the load&play engines.

basically the roadmap is the following:

finishing the modular GUI
implementing the downcompiler (takes the module description and generates
an executable sampler engine as .so (DLL).
implementing sample library loader modules (akai format, gig format etc).
GUIs for the various engines.

To produce quicker results I'd suggest to leave out the more complex stuff
 for now like disk based sampling (thus the gig format etc) while trying
to get a good working AKAI engine.

For Steve H.: I thought about your method of pasting sources:

for(i=0;i<samples_per_block;i++) {

  do_amplitude_modulator(input, tmp);
  do_filter(tmp, output);
... etc ...
}

That way we could even create low latency (1 sample) feedback loops 
without much effort (since we operate "blockless" within the loop).

I fear LS wil get many modular synth capabilities for free ;-)
(not a bad thing for those that want such stuff, but the goal
will always be sampler engines)

cheers,
Benno





Scrive Florian Berger <fl...@ar...>:

> Hi everybody,
> 

> 
> First I should tell some things about me and my motivation: I´m a
> musician, not a programmer, and I want to use Free Software for my
> music. I was pointed to this project while looking for a Linux Sampler
> at the LAU list. I need a (virtual) sampler which is almost "invisible"
> in the process of creating music, e.g. which is easy and
> straightforward to use, relieable and fast.
> 
> Well, Benno, thanks for your work, but in my mind this starts to look
> like just _another_ virtual modular thing. There is already some stuff
> like this walking around in the Linux Audio world, as far as I know.
> 
> I used to hope (and I still do :-) ) that Linuxsampler would more look
> like that:
> 
> http://www.creamware.de/de/products/Volkszampler/defaultpics.asp
> 
> http://www.creamware.de/de/products/Volkszampler/default.asp
> (this one in German, sorry)
> 
> I think in the "where should it go"-discussion you just missed the
> point which role Linuxsampler should play in the creative action.
> A modular system where the artist has to build the instruments/patches
> "from the bone" naturally consumes more time and power but leaves room
> for very individual sounds and experimenting.
> A sampler more dedicated to a "load&play"-philosophy lacks this kind of
> freedom, but the artist can start composing immediately (which I
> prefer).
> 
> Well. It´s up to you programmers, and this is just my humble opinion
> :-). Maybe both ways will be possible in the final GUI. Thanks for your
> work so far and keep it up!
> 
> Regards,
> 
>      Florian Berger, Leipzig, Germany
> 
> 


-------------------------------------------------
This mail sent through http://www.gardena.net