Please bear in mind that, regarding this discussion, my focus is mostly on sample-based simulation of acoustic instruments.
> Sure there were tons of samplers around too, so why start working on LS in > the first place ? Not comparable. The only sampler worth mentioning (i.e., had a number of useful libraries available) was fluid and it had serious performance issues. The SMS (software modular synth) field is much, much deeper. CSound, SuperCollider or Gem/Pd, for naming a few, are used worldwide. > there are some modular synths around for linux but they are not good enough > to allow you to construct > an efficient and flexible sample engine which can compete with hardcoded > designs. Should they? The problem with sampling technology lies more in the libraries than in the engine. Lots of uber-kool commercial engines have failed for lack of actual content. You need a stable engine and a good editor in order to develop good libraries for it, then musicians can take advantage of them. > The idea is to really natively compile an engine after it has been created or > edited within such a module editor. So the editor would act as a A big problem I see with that approach is one of interactivity, which happens in other SMS too. The response time of such a system may be important. Having to wait more than a couple of seconds to hear the results every time you add or remove a new module is not for everyone. How RT responsive do you want the design process to be? > being faster at runtime. Plus everybody could conviniently toy around with > compiler flags in the editor for getting the maximum of performance out of > his box, just by adjusting the flags in the editor and pressing on > the "build" button. I don't know if that's a very strong argument, anyone who cares about performance enough to consider tweaking compiler flags can build her own monolithic package or just run Gentoo. > The randomizing capability already exists in the gig engine as a "Random Yup, not very hot, IMO. I am thinking more of slightly randomizing pitch, vibrato, filtering, etc. You can of course use midi controllers for this. I think the VSO library provides a midi filter to enliven performances by cleverly inserting cc messages in the original midi stream before it reaches Giga. But it would be convenient if the randomizer was integrated in the sample engine (i.e., the cutoff frequency of the LPF is not constant, but is generated randomly according to a certain statistical distribution within bounds.) I think Kontakt has good capabilities in this respect. But the ability to randomly switch samples ala Giga is also interesting, without any doubt. Luis ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
