On Thu, May 22, 2014 at 8:21 PM, Christian Schoenebeck
<schoeneb...@linuxsampler.org> wrote:
[...]
> One thing I find suboptimal with KSP is that it is very focused on using
> function calls all over the place.
[...]
Yeah, functions with umpteen arguments get old... Then again, I'm not
generally a big fan of overly verbose code either. Named arguments? An
editor that automatically shows the argument names of the function at
hand in the status bar or similar?
> would probably be more intuitive and easier to remember. Modifying incoming
> MIDI events is also a bit odd, with KSP it is like this:
>
> on note
> if ($EVENT_VELOCITY > 100)
> ignore_event($EVENT)
> else
> change_note($EVENT, $EVENT_NOTE + 12)
> change_velo($EVENT, $EVENT_VELOCITY / 2)
> end if
> end
>
> which IMO I would found more intuitive like:
>
> on note
> if ($NOTE.velocity > 100)
> $NOTE.ignore()
> else
> $NOTE.note += 12
> $NOTE.velocity /= 2
> end if
> end
[...]
The latter needs either a proper type system with structs, classes or
similar, or run-time indexing by "name" (typically immutable strings),
both of which are quite complicated to do well with good performance.
This suggests that they took the easy route with KSP and just made
"everything a variable," resolved at compile time (performance is not
critical) by means of a one-dimensional non-nested symbol table.
So, the latter is much nicer, but TANSTAAFL. :-)
[...]
> In this case such a "polyphonic" variable is not shared, it is bound to the
> event which triggered the callback function. So no other instance of the same
> callback can modify variable $i in between, preventing you from any trouble.
> However from memory management point of view this case is a bit problematic.
> Because you have no information at parse time how many instances of the
> callback might be triggered in parallel. I am not sure what the best solution
> would be to implement this case (from memory management POV). Do you have a
> solid idea?
This is where realtime programming gets real hairy... Again, it would
seem like the "easy" route was taken with KSP, and it's not truly
dynamic (that is, all structures, variables etc are allocated and
initialized as an instrument is loaded), except that the 'polyphonic'
keyword somehow sets up pools or arrays of "sufficient" size for
polyphonic action.
In hardware synths, there's usually a fixed number of voices,
traditionally because the voices were physically built into the
hardware, and in more recent designs, because of (relatively speaking)
very tight CPU power and memory budgets. In some cases (like the old
JV-1080), you can manually split the voice pool across parts to manage
voice stealing issues, but with a soft synth/sampler these days, you
can probably get away with just pre-allocating a few hundred voices,
with polyphonic variables and whatnot that goes with them, and be done
with it. I've noticed proprietary software synths and samplers still
tend to have hard limits on channels, voices etc, and this might be
the main reason for that...
With EEL, I decided to go fully dynamic, so there are no special cases
for things like this. There are static variables (allocated per
module, and shared within the module instance) and local (VM stack)
variables that work like stack variables in C. If you want per-channel
or per-note data, you just design your objects like that, OOP style.
(EEL is really a generic programming language, not designed for any
specific type of applications, apart from the requirement of being
"realtime safe".)
So, there is full dynamic memory management in the core of the
language (call stack, arrays, tables, custom classes etc), and if you
want it all hard realtime, you should plug in a suitable memory
manager instead of malloc()/realloc()/free(), like TLSF:
http://www.gii.upv.es/tlsf/
It has crossed my mind to hardwire TLSF or similar into EEL, but there
are downsides to a realtime memory manager when you don't really need
one, and existing realtime OSes and application often have their own
custom memory managers already, so it might be better to plug into
those.
>> 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.
>
> Probably, but in fact I would like to avoid opening the door for numerous
> flavors of high level script languages used in the sampler right now. Because
> it might create confusion among users when learning scripting with the sampler
> and/or by reading scripts of other people, if everybody is using a different
> language on top that is. So I would prefer to pick one single language flavor
> that should remain alone in this flavor (for quite some time at least).
Yes... Choice is good - but most people don't know what to choose, or why. :-D
>> 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.
>
> Yes, I saw you went a bit deeper with EEL than what we probably need to
> achieve right now. From what you saw above, the typical use case for the
> script language in a sampler is event handling once in a while. Not at high
> frequencies. You are even defining tight DSP stuff with EEL if I saw it
> correctly. That's already beyond the scope what we need right now.
Well, I've tried to make EEL about as fast as possible without (so
far) compiling to native code - but that's more or less unrelated to
the realtime aspect. As long as you run scripts in the audio thread, a
scripting engine that occasionally does a GC cycle, rebuilds large
structures or hits unsafe system calls is going to cause trouble. Even
if you only use it once during a whole gig, that's one chance of it
causing an audio drop-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.
>
> Why is it called "Extensible" by the way? What is the particular extensible
> aspect of EEL?
Host applications and native modules can inject custom classes that
work just like the built-in high level types; string, array, table
etc. Other than that, it's just the usual modular stuff that any real
programming language has these days. :-)
It's crossed my mind to support "plugins" of some sort in the
compiler, to support custom syntax extensions, but I'm not sure that's
a great idea... I'd rather just add nice, generally useful features to
the official language as needed instead - though I'm trying to keep
that to a minimum as well. Inspired by the Lua philosophy, that is,
but EEL is slightly less minimalistic.
--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
------------------------------------------------------------------------------
"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
