This sounds like its going to be cool as once it stabilizes and sfz support
gets added.
Thanks for the update Christian!
On Mon, Jun 9, 2014 at 8:35 PM, Christian Schoenebeck <
schoeneb...@linuxsampler.org> wrote:
> Hi there!
>
> Some progress on the real-time instrument script front:
>
>
> http://download.linuxsampler.org/pix/screenshots/gigedit_script_3b.jpg
>
> The first instruments scripts are finally running with the gig format
> sampler
> engine. In the screenshot you see an example script with gigedit's new
> script
> editor which fires new notes (with different samples than the main notes
> were)
> if the player exceeds a certain channel aftertouch limit.
>
> Current state:
>
> - The script language: if you worked with Kontakt before, then you
> should be familiar with this script language right away. If not,
> you
> can have a look at the source directory src/scriptvm/examples
> for some
> basic core language script examples. The language is really easy.
>
> - Scripting feature is currently only working with the gig format
> yet. I
> added a LinuxSampler specific extension to the original Gig file
> format
> for storing instrument scripts to .gig files by using gigedit.
> Obviously if you store scripts to gig files, they will not load
> with
> the original GigaStudio 4 software of course.
>
> - Adding scripting to the SFZ engine is easy. Involves probably
> only
> adding 10 lines of code or so. It probably just requires a new
> opcode
> for referencing script files. Since I am no expert regarding the
> SFZ
> format, I wait for others to come up with comments how to extend
> the
> SFZ file format with a new opcode. Or maybe some company already
> introduced a scripting opcode, no idea.
>
> - gigedit does not yet transfer scripts to the sampler in
> live-mode. That
> is, each time you alter a script with gigedit, you have to force
> the
> sampler to reload the instrument with the new version of the
> script.
>
> - gigedit's script editor is yet very very primitive. It has some
> basic
> keyword syntax highlighting, but that's pretty much it. My plan
> was to
> hook the editor up with the sampler's internal script parser, so
> that
> i.e. parser warnings, parser errors, keywords, variables,
> built-in
> variables and built-in functions are always marked up in the
> editor
> correctly (similar like today's C++ IDEs are hooked up with
> clang).
> Updating this with the sampler parser could be done in real-time
> while
> typing, because it parses instrument scripts in few milliseconds.
>
> - Scripts are handled with the gig format now similar to samples.
> That is
> scripts are stored in file global space, and you can then
> reference
> individual scripts from gig instruments. You do that by right
> clicking
> on an instrument in gigedit's instrument tree tab, then select
> "Edit
> script slots..." and drag a script from the new script tree tab
> to the
> script slots window of the instrument. Note that even though you
> can
> already create more than one script slot per instrument,
> LinuxSampler
> will currently only execute the 1st script slot of each
> instrument yet.
> If you create more than one slot, the sampler will show you a
> warning
> on the console when you load the scripted instrument.
>
> - Script suspension: the ScriptVM engine suspends your script from
> execution if you call the buit-in "wait()" function. This
> function
> takes one argument which defines the sleep time in microseconds.
> However the latter is not yet implemented in the sampler. The
> script
> will simply be resumed in the next audio cycle for now.
>
> Then scripts should be suspended automatically by the sampler if
> they
> executed too long and would thus threaten the sampler's real-time
> requirements. I haven't implemented that either yet. The
> question is
> how should that decision be made exactly? Counting ScriptVM
> instructions? Comparing real time stamps? Having said that, be
> careful
> when you write while loops in your scripts. If you write an
> endless
> loop in you script without wait() call, the sampler will
> currently
> hang forever.
>
> - String type variables in scripts: all string type operations are
> *NOT*
> real-time safe ATM! Use string variables and operations like
> string
> concatenation, cast from int to string and message() function
> calls
> just for debugging purposes of your script. Otherwise you might
> get
> dropouts. You can use the preprocessor feature to switch your
> scripts
> from debug to normal mode. So if you pack your string variables
> and
> operations into appropriate preprocessor statements, you can
> enable/disable all of them at any time by changing just one line.
>
> I wonder how Kontakt addresses strings. Whether they are
> real-time
> safe? Not sure if its worth it to address this issue at all.
>
> - Built-in script functions and variables: The plan is to
> implement all
> functions and variables regarding MIDI processing which you might
> already know from the mentioned sampler. I am personally not
> interested
> in implementing the ui_* set of functions right now.
>
> I made some of the functions not as strict as in Kontakt. That
> is, many
> functions will accept a variable amount of arguments. For example
> you can also use the play_note() function with only two
> arguments. For
> the remaining arguments, the sampler will simply used default
> values
> (if it makes sense, depends on the function of course).
>
> Additionally I started to add the first gig format specific
> variables
> and functions, which you can also find in the screenshot. They
> are
> required to deal with the special features of the gig format by
> script.
>
> - ls_instr_script: This is a new command line tool. I basically
> used it
> for debugging the parser. You can pipe in instrument scripts
> (or copy
> paste it), it will parse them, show you any parser errors,
> warnings in
> ... now hold your breath ... *in* *color* ... wooow ;-).
>
> And if you are running the tool in "core" language mode, you can
> even
> execute the scripts from the command line. You might use this
> probably
> sometimes until i.e. gigedit script editor is hooked up with the
> samplers script parser one day. Or maybe not ;-) Thats up to you.
>
> If it it's not yet clear to you already: this is *bloody* *bleeding* *edge*
> yet. Backup your files, expect crashes, grab you life vest, etc.
>
> David, sorry that I decided for another route. But Andreas had already some
> basic KSP Bison parser hanging around on his disk, so it was too tempting
> to
> pickup his Bison approach for this scripting feature. ;-)
>
> Questions, comments?
>
> CU
> Christian
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Linuxsampler-devel mailing list
> Linuxsampler-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
