Page 1 of 1

A Modest Proposal...

Posted: Wed Sep 03, 2008 8:09 pm
by dahnielson
This is a proposal for a new custom LinuxSampler format that with little effort could make LinuxSampler even more flexible and attractive to create instruments for. But not as advanced as the Next Generation format that was discussed earlier in the year. It is instead a more pragmatic approach that make use of what we already have and can be implemented in a reasonable amount of time.

N.B.: I don't now what to call this format. But I will stick to "LS" for the purpose of this post and the Gigastudio format will be known as "GIG".

The goals are:
  • Store instruments in a human readable text based format like XML;
  • Reference samples as separate WAVE files;
  • Take advantage of the synthesis already implemented in the GIG engine;
  • Bundle together what used to be GIG instruments into larger LS instruments;
  • Add scriptable MIDI filtering in front of the "bundles".
Hopefully the result will be a competetive format that:
  • Can be comparable to Kontakt NKI at least to some degree;
  • Make distribution of converted commercial Kontakt/EXS24/Halion/SFZ libraries easier and legal (no samples need to be exchanged).
LS Group
The "LS Group" is what used to be called an "instrument" in the GIG format. A LS Group contain exactly the same programming as a GIG Instrument in terms of regions and dimensions. The big difference being that it is expressed in XML and samples are stored as separate WAVE files on disk.

LS Instrument
The "LS Instrument" is basically a bundle of LS Groups, and will contain at least one LS Group. This is similar to manually loading GIG Instruments into separate sample channels but treat them as a single instrument (e.g. crossfading between them).

The LS Instrument may contain an optional MIDI filter script. The filter script will receive the instruments MIDI events and decide what events is sent to what LS Groups in the instrument, it will also be able to generate new events. This is similar to what Kontakt scripting does or having a performance tool sitting between the sequencer and LinuxSampler. Lua could be used as the scripting engine (developers that for one reason or the other want to protect their scripts can pre-compile them with luac).

Re: A Modest Proposal...

Posted: Wed Sep 03, 2008 8:57 pm
by dahnielson
My thinking is that at least the "LS Group" part could be achieved by:
  • Create an XML+WAV reader for the new LS format that implement the same API as libgig;
  • Make a copy the code from the current GIG engine and just switch it to use the new reader instead of libgig.
And take it from there...

Re: A Modest Proposal...

Posted: Thu Sep 04, 2008 10:22 am
by dahnielson
I had another thunk...

What I envision could be split up in two independent tasks:
  • The so called "LS Group" task: Just as I described in the post above. Create a engine with the GIG synthesis that reads a text-based equivalent of the Gig3 format.
  • The so called "LS Instrument" task: Add MIDI scripting/filtering/routing to LinuxSampler itself (just like there is effect routing for audio) instead of a new engine.