On Friday 23 May 2014 10:54:50 David Olofson 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?
Yeah, I also though about named arguments for function calls. But I decided to completely stick with Kontakt's KSP language now (plus some additional builtin functions we need), since I also haven't heard any complaints here about my suggestion to make it based on Kontakt's KSP language. I found the compatibility aspect much more important than personal opinions about the precise "look" of the script language. So I will start by implementing the MIDI processing part of the KSP language. The UI part of the language are not so important for me ATM, so I will skip them for now. > > 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. Regarding memory management, I planned to do the same, that is allocating all data when the script is loaded. For the "polyphonic" variables I will probably allocate and stick the memory to the respective LS internal Event object. But also done at load time. For RT safety reasons I simply want to avoid any memory allocation while actually playing the instrument. > 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... Yes. Memory allocation at runtime is always a threat to RT stability. LS is also allocating a fixed amount of voices. You can adjust that amount of voices of course at any time, but unless the user change the amount explicitly, they will be constant at a certain value. So memory allocation and its RT stability danger is one reason for that, and the other reason is of course that you have limited set of resources on you system (CPU power, HD speed, ..). So once that user defined voice limit is reached the voice stealing algorithm kicks in to keep the side effect of limited voices to a minimum. You might let the sampler auto detect some kind of maximum amount of voices, however sometimes you also want to leave some head room for other applications, which the sampler would not be able to understand on its own of course. > 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 Well, the main use case for this script languages are not die hard coders, but rather sound designers. Many if not most of them are not too keen to deal with scripts at all, but expecting them to learn yet another language is probably too much expected. At least Kontakt's script language is well known to anybody who works with samplers and there are already plenty of easy to understand video tutorials, written howtos, free scripts on the net (and commercial script packages to be purchased) ready to be used. So better we stick with that now. So if somebody has some doubts, complaints, other suggestions, better raise your word now, before it will be too late! ;-) 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
