Re: [Linuxsampler-devel] script support

[David O. <da...@ol...>]

On Wed, May 21, 2014 at 4:43 PM, Christian Schoenebeck
<sch...@li...> wrote:
> On Wednesday 21 May 2014 15:05:53 David Olofson wrote:
>> Well, having written two scripting engines for realtime applications,
>> one of which evolved as part of an audio engine:
>>
>> http://eelang.org
>> http://audiality.org
[...]
>
> Yes, we talked about this issue years ago, since you already had that in
> place. Using your EEL as basis for a script language might be an interesting
> option.
>
> So far I considered taking Kontakt's script language as basis for the actual
> language (with minor adjustments/extensions here and there that might be
> necessary for the GIG format for example). Which would bring the advantage
> that users could recycle their scripts from Kontakt instruments. Kontakt's
> script language also seems to have an overall reasonable set of
> functionalities that could be sufficient even for very sophisticated purposes.
> That would mean however that a lot of stuff would need to be adjusted in EEL.

Compatibility would of course be very nice in this case. Not really
familiar with the Kontakt scripting language, so I can't tell how much
work it would be to write a parser for it - but that's basically how
to go about it; write an alternative compiler that issues bytecode for
an existing VM. A VM like this is basically just a high level virtual
CPU, and not really tied to any specific language.


> Or does anybody have another good suggestion for an existing script language
> that might be used as basis for such a language for the sampler except of
> Kontakt's one?

EEL exists mostly because I couldn't find anything like it. I looked
into subverting Lua to suit my needs (replacing the GC, most
critically), but the Lua community showed virtually no interest in it
(not really needed, even for <100 Hz game scripting), so I would have
been completely on my own with it - and I'd rather be in that
situation with code that I know inside out.

For something really simple, you could look at the Audiality 2
scripting engine (not physically related to EEL), but that's a small,
domain specific language that's somewhat tied to the design of the
audio engine. Apart from being massively microthreaded with message
passing, it's a really small and simple language.


> [...Bison and stuff...]

Not sure about parser and lexer generators, really... These tools only
solve a small, simple part of the problem - and they're not even
particularly good at dealing with some types of languages. I prefer
just coding it all in plain C. Fewer tools to depend on, which is
particularly nice when porting and cross-compiling! :-)


> If I got it correctly, in EEL you are using bytecode and an intermediate
> translation layer.

Sort of... EEL compiles to bytecode, which runs on a custom VM - just
like Lua. The compiler is included with the VM.

The EEL VM can be compiled with a traditional switch() dispatcher, or
computed gotos (switch() results in ~99% mispredictions on most CPUs),
but there's no JIT or native compiler - yet. (I'm looking into using
LLVM to generate native code, asm.js and whatnot, both "live" and
build time.)


> Do you think that is necessary for the use case in the sampler?

Not strictly, but even disregarding raw speed, interpreting a proper
scripting language from source in a realtime safe manner is going to
be hairy. The normal, easy way of coding a parser involves deeply
recursive code, associative arrays and other nasty things that are
hard to do right in a realtime system.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'