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. 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? So before you wrote your Email today, I was considering using 1) Bison as compiler compiler (for automatically translating the script language grammar definition into parser tables, which is done only when the sampler source code is compiled) and 2) using a custom parser skeleton C++ code (instead of Bison's default skeleton parser) which processes the Bison generated parser tables and would take care about real-time safe memory management etc. That might be faster to achieve than adjusting EEL, no? Do you see some drawback of this approach? If I got it correctly, in EEL you are using bytecode and an intermediate translation layer. Do you think that is necessary for the use case in the sampler? That would be an important issue to decide. The current use cases that come to my mind right now, are just rather simple scripts that are executed when a MIDI event arrives. I obviously haven't tested nor benchmarked it, but it could be possible that parsing a script on demand (without an intermediate layer), right on such events, could even be sufficient without encountering overall performance impacts. And in the instrument files it would probably even make sense to just store the scripts in the script language's source code form (instead of bytecode), in order to avoid problems with script engine backend changes as far as possible. > A traditional modular, or worse, hardwired design tends to call for > countless features - and you still keep running into things that are > awkward or impossible to do without adding even more features. I think > that's a dead end with the kind of complexity and dynamics we want > from synths and audio engines these days. IMHO, hardwired features are > for performance or convenience - not core functionality. Exactly. > The downside? Well, a scripting language isn't the best user interface > for non-programmers. One way to deal with that might be to think of > the scripting as an intermediate level, where scripted instruments and > the like come with GUIs, so ordinary users can just load them and use > them as you would with a more traditional solution. Right, but on the other hand, scripting comes into game only where rather complex features need to be created for the respective instrument. Trying to implement such rather complex tasks with a very ergonomic UI is extremely hard to achieve or almost impossible. As you said, trying to hardwire that (like Tascam tried in GSt4 to avoid scripting) easily brings you to restrictions. So I think if an already existing script language is taken as basis (i.e. Kontakt's one), plus a decent script editor in the instrument editor with syntax highlight and auto completion suggestion and builtin documentation, that might be a good basis for sophisticated instrument designers. CU Christian ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
