# KSP is hard



## NormkbPlayer (Nov 13, 2019)

KSP is harder than I Expected. 

I've come across two Manuals 

One that is Koala KSP. 
I thought it was easy as copy and Paste. 
Sadly no. 

Also is it possible to create something as big as damage, Session Strings. Via KSP?
Or is it too much. 

Does KSP have any Limit to Creativity.


----------



## EvilDragon (Nov 13, 2019)

NormkbPlayer said:


> Also is it possible to create something as big as damage, Session Strings. Via KSP?



They *were* done with KSP...?


----------



## d.healey (Nov 13, 2019)

There are lots of tutorials on YouTube, I also sell a complete scripting course for beginners on my website.


----------



## NormkbPlayer (Nov 13, 2019)

"done with KSP



The GUI
Of the Instruments , big Libraries like the Ones in Native Instruments. 

Session Strings, 

Can we create the User Interface via KSP or is it possible only by Native Instruments.


----------



## j_kranz (Nov 13, 2019)

NormkbPlayer said:


> The GUI
> Of the Instruments , big Libraries like the Ones in Native Instruments.
> 
> Session Strings,
> ...



The graphic assets typically are done by a graphic designer (whether NI are anyone else), but yes they are implemented via KSP. Native Instruments uses the same KSP within Kontakt as everyone else.


----------



## Dewdman42 (Nov 13, 2019)

I've been curious about KSP for a long time, but I have no idea where to find information about it. Is there an official manual of some kind? Unofficial? Free resources for information other then you tube?


----------



## d.healey (Nov 13, 2019)

Dewdman42 said:


> I've been curious about KSP for a long time, but I have no idea where to find information about it. Is there an official manual of some kind? Unofficial? Free resources for information other then you tube?


Kontakt comes with the KSP scripting manual. Just go to the help menu and look in the manuals sub-menu. Once you really start getting into KSP you'll want to use the extended language pioneered by Nils Liberg and you'll use Sublime Text and the SublimeKSP addon to write your scripts. Nils has a good beginner tutorial on his site.


----------



## Dewdman42 (Nov 13, 2019)

extended language. Is that some kind of extra extension that has to be installed somehow to work within Kontakt?


----------



## d.healey (Nov 13, 2019)

Dewdman42 said:


> extended language. Is that some kind of extra extension that has to be installed somehow to work within Kontakt?


KSP is a crappy language and it's awful for writing large scripts. So Nils created what we call the extended language which is basically syntactic sugar that compiles to regular KSP that Kontakt can understand. To use the extended language you need a compiler, Nils built one into his custom editor which you can download from his site and he made a version that runs in Sublime Text 3. This is now very out of date and is not recommended for new scripts, however Nils code was forked and improved upon by a few other people and this fork, Sublime KSP, is what you should use to write anything other than the most simple scripts.

I have a tutorial on my YouTube channel for how to set this up, I think Mike Greene also made a tutorial and I'm sure there are others too.


----------



## d.healey (Nov 13, 2019)

If you're planning to make virtual instruments commercially then I wouldn't consider using Kontakt unless you need some specific feature. I'd recommend HISE instead. The documentation for HISE is far more comprehensive than Kontakt's and there are lots of tutorials on YouTube.


----------



## Dewdman42 (Nov 14, 2019)

Thanks for that overview about KSP and the Nils stuff. I didn't realize that KSP was so low level in nature that a higher level language and compiler had been created for it, etc. Do NI staff tend to use Nils compiler too? Just curious.

Well I am not interested in developing any sample libs, for me its more about just learning a bit to write some multi-script for processing midi before hitting the libs I already have in Kontakt. Minimal need actually, and sounds like a steep learning curve...so might not happen.

But anyway thanks for the overview...


----------



## EvilDragon (Nov 14, 2019)

Dewdman42 said:


> Do NI staff tend to use Nils compiler too?



Not all of them, no. Nikolas Jeroma famously only uses vanilla KSP (he did all the Discovery Series instruments except Balinese Gamelan which is Soniccouture). However the likes of Frank Elting (Straylight) uses SublimeKSP to great effect.


Also, KSP is not exactly low-level (by definition scripting languages are high-level). It's just not a nice syntax.


----------



## polypx (Nov 14, 2019)

Vanilla KSP is fine if you're being paid by the hour.


----------



## EvilDragon (Nov 15, 2019)

And if you have Xanax at hand...


----------



## paoling (Nov 16, 2019)

You can certainly script in KSP with no prior programming experience. But in general having an understanding about how to organize code and other languages as well helps a lot. From my experience there's a certain "logic mindset" that forms through years of coding.
I personally found that knowing Java, Pascal, Python, C++ has been really helpful to create my own naming conventions in KSP, my little re-usable snippets of code, my own elegant-solutions to certain problems. Also by studying how VSTs work, you can infer how Kontakt handles certain things so you try to can make the most out of it. I think that what I'm saying applies to any skilled scripter/programmer here.
Writing good code helps to develop more complex stuff, but this is a constantly improving process and we can just be better at it by continuing to do it.


----------



## Fredeke (Nov 19, 2019)

KSP is a rather tedious language because it was devised with real time efficiency in mind, rather than convenience.

However, several free 3rd party projects merged into SublimeKSP, a KSP pre-compiler plugin for Sublime Text Editor (of which the free demo is fully workable). It adds a lot of useful features to the language, like real functions, _for_ loops, multi-dimensional arrays, macros, syntax highlighting, etc.

The doc for it is is fragmented all over the internet, but I've compiled a list of all resources I could find here: https://vi-control.net/community/threads/heres-all-the-doc-i-could-find-about-sublimeksp.77885/

Of course, this assumes you're familiar with at least one programming language already. Otherwise, I would start with programming starter kits for kids (try _Scratch_ ). There are also various (generic or KSP-specific) programming tutorials on youtube and across the web, of various quality and skill levels.

I hope this helps.


----------



## d.healey (Nov 19, 2019)

Fredeke said:


> KSP is a rather tedious language because it was devised with real time efficiency in mind, rather than convenience.


Real-time does not mean inconvenient. HISE Script is realtime and is very convenient.

C++ is also used for realtime and is pretty convenient.


----------



## Fredeke (Nov 19, 2019)

d.healey said:


> Real-time does not mean inconvenient. HISE Script is realtime and is very convenient.
> 
> C++ is also used for realtime and is pretty convenient.


Indeed.

But C++ is working at a much lower (almost machine) level, which makes the comparison unfair. And while more elegant, it is at least as unforgiving as KSP.

Javascipt (used in HISE) is intended for high-level real time applications (originally web apps), so yes, you're right on this.

Nevertheless, realtime constraints are the only excuse I can find for KSP


----------



## d.healey (Nov 19, 2019)

Fredeke said:


> Nevertheless, realtime constraints are the only excuse I can find for KSP


They could have used Lua too which is a little nicer. I think the main reason KSP is cumbersome is because it was based on Pascal and so inherited its quirks. I also think the original implementation was intended for simple MIDI manipulation tasks and basic GUIs rather than the much more sophisticated applications it has come to be used for. I didn't get into KSP until Kontakt 4 so I'm not too familiar with its history before that.


----------



## Fredeke (Nov 19, 2019)

d.healey said:


> They could have used Lua too which is a little nicer.


They should have. I suppose they originally didn't intend it to grow so much.



d.healey said:


> I think the main reason KSP is cumbersome is because it was based on Pascal and so inherited its quirks


That's what feels familiar about it !
God I hate Pascal. The rigor of C combined with the power of Basic


----------



## NormkbPlayer (Nov 19, 2019)

Can't they make KSP generator?
We can custom build with Default Presents. 

And when we need the Code 
Just Export it. ?

Am I thinking way too Ahead?? ,,🙈


----------



## EvilDragon (Nov 19, 2019)

It ain't simple as that. There's any number of ways you can use the available KSP commands, you cannot cover all the possible usecases with such a generator.


----------



## NormkbPlayer (Nov 19, 2019)

Wish I understood KSP just like you do. 
:(


----------



## Fredeke (Nov 19, 2019)

NormkbPlayer said:


> Can't they make KSP generator?
> We can custom build with Default Presents.
> 
> And when we need the Code
> ...



There's a commercial Kontakt GUI Editor (I think that's what it's called) that will take care of generating the code for the controls (knobs, buttons, etc.), from a graphical drawing board. I suppose it saves time.
But as for the actual performance handling, KSP exists exactly for what can't be programmed any other way than by coding. If the kind of generator you suggest were possible, then there would be no reason for KSP to exist.
(Oh, sure, there are a few things for which KSP is required that could have been directly accessible from a graphical interface, but Kontakt's GUI is quite extensive yet, and at some point, coding would be necessary anyway. There are just too many conditions to handle, and code is the most efficient way of handling conditions.)

[EDIT: Basically I said the same thing as EvilDragon, in many more words :-/ ]


----------



## EvilDragon (Nov 19, 2019)

NormkbPlayer said:


> Wish I understood KSP just like you do.
> :(



I've been doing it for 10 years. It's just applying effort into it, just like any other thing you want to be good at


----------



## NormkbPlayer (Nov 19, 2019)

EvilDragon said:


> I've been doing it for 10 years. It's just applying effort into it, just like any other thing you want to be good at


I've just got into KSP maybe less than 10 days. 
Compared to 10 Years. 
Lol.


----------



## storyteller (Nov 19, 2019)

I found the yummybeats tutorials to be a great resource when I dove into KSP. As others have said, knowing other programming languages will certainly help you. I think KSP would be pretty gnarly if it were a “first language” to learn. YummyBeats blog here: https://blog.yummybeats.com/ksp-kontakt-scripting/


----------



## neblix (Nov 19, 2019)

Productivity tools and quality of life for programmers in any other industry is miles beyond the experience KSP developers get. SublimeKSP is a small band-aid. The insistence on a proprietary scripting language disables developers from taking advantage of IDE's, which have been a staple in professional programming for decades now. Imagine being able to compile your multi-file project without tabbing to the right file that needs to be compiled, imagine global paths for re-usable modules, imagine sample library project templates available at the click of a button, imagine refactoring code frequently and painlessly without tripping on regex gymnastics, imagine live syntax checks (not compile-time syntax checks, causing 20 minutes of compiling repeatedly to iron out every typo in your code), imagine breakpoint code debugging and monitoring, the list goes on...


----------



## Lindon (Nov 19, 2019)

Fredeke said:


> They should have. I suppose they originally didn't intend it to grow so much.
> 
> 
> That's what feels familiar about it !
> God I hate Pascal. The rigor of C combined with the power of Basic


LUA wasnt even an option when they started. Tho' Pascal was (and is) a questionable choice. The real crime is that they havent bitten the bullet and removed KSP and replaced it with something easier to use like LUA or Javascript, and with better functionality.
.


----------



## Fredeke (Nov 19, 2019)

Lindon said:


> LUA wasnt even an option when they started. Tho' Pascal was (and is) a questionable choice. The real crime is that they havent bitten the bullet and removed KSP and replaced it with something easier to use like LUA or Javascript, and with better functionality.
> .


I suppose that would require a deep redesign, and they're probably not gonna do that as long as they lead the market.
(Maybe we should all move to HISE, as a message ?) 
Also, they would (preferably) need to address backward compatibility.


----------



## Lindon (Nov 19, 2019)

Actually KSP's limitations would be its friend here, basically every call to the underlying engine already has a parameterised approach - so it'd be not toooooo difficult to do. Its laziness - and being the market leader isnt helping you are right.


----------



## Fredeke (Nov 19, 2019)

Lindon said:


> Actually KSP's limitations would be its friend here, basically every call to the underlying engine already has a parameterised approach - so it'd be not toooooo difficult to do. Its laziness - and being the market leader isnt helping you are right.


Yeah, maybe they could even program a KSP emulator in Lua . Just kidding, that would be messy.
But some professional applications accept more than one scripting languages: Photoshop, Reaper, ...
So, if you're right, I suppose KSP could cohabit with a more modern language?
If the OP has to learn to code, it would be nice if he could at least learn some decent language. 
Me I don't mind, I fiddle with several already.


----------



## EvilDragon (Nov 19, 2019)

NormkbPlayer said:


> I've just got into KSP maybe less than 10 days.



Then it's maybe premature to cry? Especially if you didn't have any previous programming experience - almost any programming language could be considered hard then.




Lindon said:


> Its laziness



It's not that. It's just that there are much bigger problems in Kontakt that have precedence over everything else - and KSP works and serves its purpose. It's prioritizing that bigger fish that needs to be fried.




Fredeke said:


> So, if you're right, I suppose KSP could cohabit with a more modern language?



Of course it could, it's a matter of prioritization really. And available manpower. Kontakt team is not 50 developers.


----------



## NormkbPlayer (Nov 19, 2019)

EvilDragon said:


> Then it's maybe premature to cry? Especially if you didn't have any previous programming experience - almost any programming language could be considered hard then.



I learnt C++ at one point. 
But it was too basic. 

Now I don't even know what the Commands means. 

I'll give it a go.


----------



## Fredeke (Nov 19, 2019)

NormkbPlayer said:


> I learnt C++ at one point.
> But it was too basic.
> 
> Now I don't even know what the Commands means.
> ...


You should be fine then. Just apply yourself and be patient. KSP is tedious, but not complicated. (Actually it is pretty basic, you just need to lay down everything at length, exactly because of that.)

And this community is a great resource. Don't hesitate to ask questions as you go. (I personally owe much, especially to EvilDragon and d.haley) [EDIT: and P.N.]


----------



## Joakim (Nov 19, 2019)

Why exactly are you using Kontakt instead of HISE?

Javascript is a lot more beginner friendly and powerful and has much better learning resources. Not to mention it has a proper WYSIWYG GUI editor and debugging tools.

And if you eventually want to script for kontakt the APIs are similar enough that you would benefit greatly from the previous HISE knowledge.


----------



## EvilDragon (Nov 19, 2019)

Apart from the fact that Kontakt is everywhere, its stability and performance are established?


----------



## Joakim (Nov 19, 2019)

EvilDragon said:


> Apart from the fact that Kontakt is everywhere, its stability and performance are established?



This might be anecdotal (same library implemented in both) but in my tests the performance has been within margin of error between the platforms. And I've probably had Kontakt crash more often than a compiled HISE plugin.

Kontakt might be more mainstream and "everywhere" but it has a paywall for your users unless you make a player library which then costs YOU money 🤔

And as a developer I'd prefer the tools to work with me and not against me. That we even have to recommend a third party intermediate language is laughable in my opinion.

The only real reason I can think of for using Kontakt at this point is if you really have to use some of the built in effects that HISE doesn't have, or time stretching.


----------



## EvilDragon (Nov 19, 2019)

And also don't forget that for many, many, *many *people, Kontakt acts as a hub to all their sample library. Simply because there's so many libraries available for it. Every new HISE library is a separate plugin (to my understanding - do correct me if I'm wrong), which eventually would (and I assume will) bloat everyone's plugin lists in DAWs, etc...

Also, try doing bigger libraries (dozens of thousands of samples in a single instrument, lots of groups, modulation and FX going on), then tell me how HISE fares. 



Joakim said:


> Not to mention it has a proper WYSIWYG GUI editor and debugging tools.



Kontakt also has debugging tools (Creator Tools).



Joakim said:


> Kontakt might be more mainstream



"Might"? It has a huge number of unique installs in the world. People love buying Komplete because of all the goodies, and all the extra available 3rd party stuff for Kontakt doesn't hurt. 



Joakim said:


> if you really have to use some of the built in effects that HISE doesn't have, or time stretching.



Or some of the actual KSP functionality, like the recently added user zones and drag&drop samples directly on the GUI, MIR functions, XY pads, dynamically reordering FX without needing to resort to C++ (according to documentation I found you have to do this if you want that in your library?)... etc. Or use LFOs that go above 10 Hz without resorting to the source code of the sampler or scripting your own, heh...


Yeah, I know I'm biased. I have every right to be.


----------



## d.healey (Nov 19, 2019)

Joakim said:


> Kontakt might be more mainstream and "everywhere" but it has a paywall for your users unless you make a player library which then costs YOU money 🤔


If you're developing a non-free plugin (closed source) with HISE then it will also cost you money. Although it's less overall than a Kontakt player license from what I understand.


----------



## Joakim (Nov 19, 2019)

Well we obviously have different views when it comes to this and I am not going to argue it any further. 

But my initial question was to OP who is just starting out and learning. I don't think he is going to create a massively complicated instrument to begin with. So a more user/beginner friendly approach might be interesting.


----------



## d.healey (Nov 19, 2019)

EvilDragon said:


> Every new HISE library is a separate plugin (to my understanding - do correct me if I'm wrong),



Pretty much. HISE has an expansion system which is currently rather experimental but it allows you to load multiple sample packs (individual products) into a single plugin. It could be used to make a custom player plugin. I tried it but my plans were quite ambitious so I decided to go back to individual plugins. I'm still exploring the use of expansion packs in order to divide products into smaller packages. For example instead of buying my entire woodwind collection you'd be able to get it one instrument or a group of instruments at a time.

Also there is supposedly a HISE player in the works but when it will appear nobody knows.



> which eventually would (and I assume will) bloat everyone's plugin lists in DAWs, etc...


Depending on your DAW's plugin manager this isn't really a problem. After all Kontakt only offers a list of encoded libraries (which now has a search feature!), the quick launch, or the regular file browser. The search facilities in some DAWs are far better and make it much easier to organize and find instruments.


----------



## Lindon (Nov 20, 2019)

EvilDragon said:


> And also don't forget that for many, many, *many *people, Kontakt acts as a hub to all their sample library. Simply because there's so many libraries available for it. Every new HISE library is a separate plugin (to my understanding - do correct me if I'm wrong), which eventually would (and I assume will) bloat everyone's plugin lists in DAWs, etc...



Dave covered this one I think..



EvilDragon said:


> Also, try doing bigger libraries (dozens of thousands of samples in a single instrument, lots of groups, modulation and FX going on), then tell me how HISE fares.



It fares pretty well actually - and is a whole lot LESS painful in terms of setting up your samples (yes I've heard of Creator Tools). The XML based approach is so much more 21st century......I can use ANY scripting environment to build out my sample maps - and HISE is smart enough to load ONLY what I need...YMMV.




EvilDragon said:


> "Might"? It has a huge number of unique installs in the world. People love buying Komplete because of all the goodies, and all the extra available 3rd party stuff for Kontakt doesn't hurt.


true...But for everyone who doesnt want to cough up $1200.00 for stuff they might never use ....




EvilDragon said:


> Or some of the actual KSP functionality, like the recently added user zones and drag&drop samples directly on the GUI, MIR functions, XY pads, dynamically reordering FX without needing to resort to C++ (according to documentation I found you have to do this if you want that in your library?)... etc. Or use LFOs that go above 10 Hz without resorting to the source code of the sampler or scripting your own, heh...


Right using this weeks new KSP feature to decide its a better tool is a bit of a long bow dont you think?

But yes MIR functions (also brand new)
but X/Y pad - well no that capability has been in HISE for a long time 
Re-ordering FX? yep Kontakt its easier for sure - I've had it in our Kontakt libs for several years - users dont really care about it in my experience
LFOs above 10Hz ? You mean like up to say 40Hz? Already in HISE




EvilDragon said:


> Yeah, I know I'm biased. I have every right to be.



Sure - but you are incorrectly informed on some points, and you ignore others: for instance 
- HISE OpenGL paint routines - you want a vector based knoB? or a range slider? sure write your own with a few lines of javascript code
- "sensible" panel based approach - no 5 panel limit, panels have children that inherit parental display settings...ugh all that KSP code to just get the UI to draw properly...
- Modulating modulators , which are modulated by modulators... you get the picture.

Well I could go on... but look I've spent 10 years building pretty sophisticated Kontakt instruments, and I will use it again if I cant get the product done in HISE - but if I CAN get it done in HISE then wild horse wouldn't drag me into building it in Kontakt. Each environment has its advantages and disadvantages. I suggest you explore all of them.


----------



## EvilDragon (Nov 20, 2019)

Lindon said:


> Right using this weeks new KSP feature to decide its a better tool is a bit of a long bow dont you think?



No. If you need that feature for your library then of course it's a better tool. 



Lindon said:


> LFOs above 10Hz ? You mean like up to say 40Hz? Already in HISE



Docs say 10 Hz. Still far cry from Kontakt's 213 Hz.



Lindon said:


> but X/Y pad - well no that capability has been in HISE for a long time



Didn't find that in docs? XY pad in KSP supports up to 16 cursors.



Lindon said:


> panels have children that inherit parental display settings..



ui_panel in KSP does the same.



Lindon said:


> - Modulating modulators , which are modulated by modulators... you get the picture.



This is also possible in Kontakt?


----------



## d.healey (Nov 20, 2019)

EvilDragon said:


> Kontakt's 213 Hz.


That's not an LFO. That's just an O 

HISE goes up to 40 from what I can tell, docs must be out of date. It's probably possible to go higher with custom nodes but not something I've explored.


----------



## EvilDragon (Nov 20, 2019)

Well no if you check some other synths their LFOs can go well into audio range. For example Waldorf's synths. In Kontakt it just exploits the modulation system's processing rate to the max.


----------



## storyteller (Nov 20, 2019)

Weird thread.


----------



## Light and Sound (Nov 20, 2019)

EvilDragon said:


> Also, try doing bigger libraries (dozens of thousands of samples in a single instrument, *lots of groups*, modulation and FX going on), then tell me how HISE fares.


One of the unique things about HISE is that you don't _need _lots of groups. What took 450 groups in kontakt takes 9 instead, possibly down to 5 with HISE. You can do things a lot more efficiently almost universally, and it encourages stepping back to think of the best way to do things.

The joy of writing without the limitations of KSP, and add in the ability to include your own C++?

Incomparable.


----------



## EvilDragon (Nov 20, 2019)

I suppose depends how you do your mapping in Kontakt... But yeah if you can purge per zone in HISE, that is an obvious benefit. However, everything depends on what exactly you want to do in your library. Sometimes there's no real way around having hundreds of groups, for this or that reason.


----------



## Light and Sound (Nov 20, 2019)

EvilDragon said:


> I suppose depends how you do your mapping in Kontakt... But yeah if you can purge per zone in HISE, that is an obvious benefit. However, everything depends on what exactly you want to do in your library. Sometimes there's no real way around having hundreds of groups, for this or that reason.



Being able to dynamically add "groups" (or even better, multimic enabled groups in this case) is something kontakt is not able to do, as far as I'm aware, so definitely a big plus on HISE.


----------



## Hans Adamson (Nov 20, 2019)

I want to give credit to Native Instruments for creating KSP and the initial KSP manual/tutorial that gave musicians (like me) that had no experience of computer programming the chance to creatively develop scripted sampled instrument with a relatively small effort. Recently I have studied and tried to learn C++ and it has really dawned on me how well done and easy to follow for a complete beginner the initial KSP tutorial was compared to anything similar I have studied for C++. I don't know if the initial manual/tutorial is still available, but if it is, I recommend it as the best way to learn KSP if you are new to computer programming.


----------



## EvilDragon (Nov 21, 2019)

That old manual can probably be googled away, but here it is:


----------



## Takabuntu (Nov 21, 2019)

I scanned through this thread, but I couldn't find any info if you are a programmer or a software engineer. I've been doing software engineering for more than 20 years in one form or another. Every new programming/scripting language that you learn has its challenges and there's a (steep) learning curve. But there's also a lot of similarity, once you know how to properly program. In essence syntax is just a way of conveying a solution. Some languages are hard in that respect and some may be are easier. Good luck in your KSP endeavour.


----------



## Lindon (Nov 21, 2019)

EvilDragon said:


> Well no if you check some other synths their LFOs can go well into audio range. For example Waldorf's synths. In Kontakt it just exploits the modulation system's processing rate to the max.


Ok well if you used HISE you would know that you can use scriptnode and SNEX to have an "LFO" that worked at the audio sample rate - so all the way to 96KHz (utterly useless by the way) - at this rate all its doing is +/- each sample - just silly. Of course you may well be doing this to attempt to make your LFO into some sort of oscillator - which would again be pointless in HISE as you get a very rich set of oscillators given - in fact I've built (and shipped) a synth in HISE that doesn't use samples at all. 

But this is again turning into a silly thread - and after I promised myself I wouldnt argue with you or anyone else here about HISE functionality until they've done something beyond reading the (very out of date and incomplete) documentation. 

So here's my full disclosure:

I build software VI's for a living.
I do it in Kontakt - with many many dozens of instruments over the last 10 years
I do it in HISE - with over a dozen shipped over the last 12 months

I have no financial affiliation with Native Instruments or Christoph Hart

Mario?....


----------



## EvilDragon (Nov 21, 2019)

Lindon said:


> (very out of date and incomplete) documentation



Would be great if it were actually complete and up to date, then.


----------



## Lindon (Nov 21, 2019)

EvilDragon said:


> Would be great if it were actually complete and up to date, then.


yes of course it would, but it's been mentioned here (in this thread and in others) that its very out of date and incomplete yet you continue to quote it as the true state of play. Why are you doing that?


----------



## EvilDragon (Nov 21, 2019)

Well if they don't want me to quote it as true state of play then they better update it.  I don't have time to delve 100% deep into it with incomplete documentation, that's a waste of time. 
And also seems like HISE's answer to everything is "well you can do it yourself if it's not in there". While I can certainly see the benefit in that, you cannot say that it's also at the same time a negative point. If they want to convert more Kontakt devs, they'll have to offer more complete functionality out of the box without requiring 3rd parties to code their own solutions for something that's not there but is there in Kontakt. Then again, there will always be developers that are happy to do just that, and I'm not saying anything against that. It's just not for me, personally.



Lindon said:


> (utterly useless by the way)



It's not useless if you want to do AM/FM etc.


----------



## Lindon (Nov 21, 2019)

EvilDragon said:


> Well if they don't want me to quote it as true state of play then they better update it.  I don't have time to delve 100% deep into it with incomplete documentation, that's a waste of time.
> And also seems like HISE's answer to everything is "well you can do it yourself if it's not in there". While I can certainly see the benefit in that, you cannot say that it's also at the same time a negative point. If they want to convert more Kontakt devs, they'll have to offer more complete functionality out of the box without requiring 3rd parties to code their own solutions for something that's not there but is there in Kontakt. Then again, there will always be developers that are happy to do just that, and I'm not saying anything against that. It's just not for me, personally.
> 
> 
> ...



Again...wrong - and now not even bothering to read the documentation that is there:





__





HISE | Docs






docs.hise.audio





See that button on there marked "Enable FM"? -- you get FM out the box - no need to use some modulator to fake it, so who's the "well you can do it yourself if it's not in there" culprit this time? Looks like Kontakt to me...Dont get me started on the FM module in scriptnode.

It's beginning to look like you haven't read enough of the incomplete documentation (still waiting for the KSP V 6.2 documentation by the way so its not a one way street on this "out of date" docs stuff) , and sure if you dont have the time to do so then that's absolutely fine, whats less fine is having incomplete information and then quoting it as if its comprehensive and correct. Again: why are you doing that?

It's beginning to look like you have some agenda. So one more time:

So here's my full disclosure:

I build software VI's for a living - for lots of different people.
I do it in Kontakt - with many many dozens of instruments over the last 10 years
I do it in HISE - with over a dozen shipped over the last 12 months 

..and again one more time let me invite you to offer your full disclosure.


----------



## EvilDragon (Nov 21, 2019)

Lindon said:


> See that button on there marked "Enable FM"? -- you get FM out the box - no need to use some modulator to fake it



Sure you do need it if you want to FM *any *parameter that is modulatable, not just modulating one sound generator with another. I saw docs for that module (and in fact, I've read nearly all of what's available, just to counter your point) and that wasn't what I wanted.



Lindon said:


> It's beginning to look like you have some agenda.



As if you don't know where my (let's call it that, although it's not quite that) affiliation lies. But this doesn't prevent me to use other samplers or whatever. Or at least attempt to use and then hit too many stumbling blocks, as in this case. That's all I'm gonna say, and apparently since this thread got too weird for some, I'm over and out.


----------



## Light and Sound (Nov 21, 2019)




----------



## storyteller (Nov 21, 2019)

Light and Sound said:


>


Ha, Lightsabers were apparently drawn at some point...  

btw - I love the people involved in the dual though... So... Carry On.


----------



## cpaf (Nov 22, 2019)

For someone just getting wet into ksp its awesome to hear your opinions all - didnt know about HISE before reading this thread - also learned a lot about Kontakts functionality. I am biased towards Kontakt at the moment (as a beginner) as it is the most used and recognised. HISE sounds like Bitwig but I need/want Cubase to compose which to me is like Kontakt. 

But I do hope the Kontakt team is looking forward and think about moving towards a newer programming foundation than pascal.


----------



## Fredeke (Nov 23, 2019)

Ay. A painful realization just dawned on me.

I hate to bother with variable types. I like PHP (and, to most extent, javascript) because it takes care of them for me - even though I need to keep aware of what it's doing in that respect. I loved GfA back on the Atari ST because I could choose to go low level and be rigorous, or stay high level and be sloppy - which I did, most of the time.

Anyway, one reason I find KSP tedious is because of how strict it is when it comes to types, and it pains me how simple formulaes become unreadable when you nest int_to_real's into real_to_int's... But then, I do need it to be as efficiently real time as possible, so even with a better language, I suppose I should still manage variable types myself for better code efficiency.

So there's no way around this annoyance. And that's a cruel truth.
(Life does what a vacuum does best.)


----------



## szcz (Nov 23, 2019)

Once I got used to it, I rather like KSP, I find it quite easy, since real math arrived you can do a lot with it. Strict types are good, you know what are you dealing with and you're not wasting resources. Somehow I find KSP much simpler and comfortable than SublimeKSP, I really hate what I have to deal with it, it's like adding layers of nonsense to something that is already convoluted enough. I think that people with previous programming background find KSP odd, as it has a slightly different mindset, then Sublime acts as prostetic to make it look more familiar. Actually Kontakt itself is harder than KSP, it's just such a mess here and there, like the timing controllers for Replika and Phasis that have different polarity for no apparent reason, many small quirks like that.


----------



## Fredeke (Nov 23, 2019)

szcz said:


> Somehow I find KSP much simpler and comfortable than SublimeKSP, I really hate what I have to deal with it, it's like adding layers of nonsense to something that is already convoluted enough.


I understand SublimeKSP could be too bothersome to learn (especially with its fragmented doc), especially if your projects are simple enough to dispense with it. But for what I've been tackling, I could hardly do without the comforts of its features making KSP at least half resemble a modern language. It has been a lifesaver in some situations.

Of course, I worry that the preprocessed script becomes a humongous mess in regular KSP when I use some of the more sophisticated features, which would defeat the speed of execution that is the original lack of feature's only (and yet debatable) justification.

Is SublimeKSP more convoluted? Yes, obviously. That's its whole point. But I would rather say it's regular KSP that is not convoluted enough. Which requires you to write sometimes excessively extensive scripts - maybe that's what you meant.

Indeed you could call Kontakt's engine convoluted (or at least incoherent in places, as you seem to do), and so KSP's integration into it. But KSP itself is too basic as well as too straightforward if anything.

Note that SublimeKSP is the only aid I've used so far. I hear there are more. I welcome any suggestion.


----------



## szcz (Nov 23, 2019)

Fredeke said:


> I understand SublimeKSP could be too bothersome to learn (especially with its fragmented doc), especially if your projects are simple enough to dispense with it.


I don't think it's complexity that matters here, I believe I have been dealing with fairly complex stuff (as far as Kontakt goes), maybe not, I don't know what are you dealing with. Anyway, what I meant, it's mainly a frame of mind problem. What I see, is that people who already program in some language seem to hate KSP when they are exposed to it. I had little programing experience prior to KSP and that was in 8 bit some long time ago, which is possibly why I have no discomfort here.


----------



## Dewdman42 (Nov 23, 2019)

if and when I start doing some KSP stuff, I personally will first learn NI's KSP language directly. Later I will see what Nil's approach might do for me. Especially since Nil's approach is basically a pre-processor that produces KSP, I feel its important to understand even the generated KSP. There are always pros and cons to using a higher level language that generates a lower level language. It can make some things easier and some things more difficult. I say that in complete ignorance about both KSP and Nil's stuff, but extensive experience as a software developer that has had to deal with various kinds of preprocessors over the years. They can be a blessing and/or a curse. If KSP is unnecessarily terse, then I'm sure I will run to Nil's stuff pretty quickly or make my own way of dealing with specific annoyances. 

Having to specify the type for variables doesn't bother me in the least, in fact I may prefer that. But if there are some common tasks such as building up arrays of interface controls or something like that I could totally see why it would be beneficial. I am mostly only interested in simple and efficient midi processing myself...so possibly I may prefer to use the lowest language possible...ie...KSP. but we shall see.

Incidentally I have a question for you KSP gurus before I spend time trying to figure out if its even possible... There is currently a "bug" in Kontakt5 ( I haven't tested K6 for this), which has to do with the way CC automation is handled. Specifically, it seems that in any process block of time, Kontakt seems to process first the CC automation events, followed by any note events in that process block. That is a problem if you have a need to have a specific ordering of CC-note-CC-note-CC-note all on the exact same point in time, like a chord, with each voice of the chord having a different CC value applied to it. This comes up with articulation handling in some Kontakt libraries for chords with poly-articulations and using CC as the switch for each note. I am wanting to see if there is some way with a KSP multi-script to work around that problem in kontakt where it seems to, for any given point in time, first process all CC's followed by al notes (in that case the last CC wins control over all notes of the chord). But I don't know how and where KSP sits in the midi signal flow in kontakt or whether it would somehow be possible to script around that annoyance in kontakt. Anyone have an idea about that? Particularly this came up for me when I was using the cc automation section in kontakt to receive CC's and change parameters in the instrument. That all happens before any notes are processed, not necessarily in the order the cc-note-cc-note's were sent from the host to the plugin.


----------



## EvilDragon (Nov 23, 2019)

Dewdman42 said:


> If KSP is unnecessarily terse



It quite is 

Would you rather write:


```
define NUM_SLIDERS := 10
declare ui_slider Slider[NUM_SLIDERS] (0, 1000000)
```

or:


```
declare ui_slider $Slider0 (0, 1000000)
declare ui_slider $Slider1 (0, 1000000)
declare ui_slider $Slider2 (0, 1000000)
declare ui_slider $Slider3 (0, 1000000)
declare ui_slider $Slider4 (0, 1000000)
declare ui_slider $Slider5 (0, 1000000)
declare ui_slider $Slider6 (0, 1000000)
declare ui_slider $Slider7 (0, 1000000)
declare ui_slider $Slider8 (0, 1000000)
declare ui_slider $Slider9 (0, 1000000)
```


----------



## szcz (Nov 23, 2019)

Dewdman42 said:


> ordering of CC-note-CC-note-CC-note



On script level events appear in host programmed order, so if you script automation it may solve the problem.


----------



## P.N. (Nov 23, 2019)

Dewdman42 said:


> Especially since Nil's approach is basically a pre-processor that produces KSP, I feel its important to understand even the generated KSP. There are always pros and cons to using a higher level language that generates a lower level language. It can make some things easier and some things more difficult. I say that in complete ignorance about both KSP and Nil's stuff, but extensive experience as a software developer that has had to deal with various kinds of preprocessors over the years. They can be a blessing and/or a curse.



I'm not a software developer, but i agree. Not getting the underlying code can be frustrating and detrimental.
I always try to understand the code on its lowest level. That's where i feel i can produce better logical decisions, at least for more complex custom tasks.

About the synthax... well, it is what it is. It's probably the worst thing about going full vanilla.

I wouldn't say "Never go full vanilla", but i can see its shortcomings too, sure.


----------



## Dewdman42 (Nov 23, 2019)

szcz said:


> On script level events appear in host programmed order, so if you script automation it may solve the problem.



That is good to know, So KSP multi-script could access the automatable parameters of a commercial sample instrument, same as Kontakt's CC automation does?

I have to do some experiments again to see if that will still preserve the ordering of the instrument itself processing cc-c-note-cc-note, in that preserved queue order when they are all on the same beat/sample position.


----------



## Dewdman42 (Nov 23, 2019)

EvilDragon said:


> It quite is
> 
> Would you rather write:
> 
> ...



In answer to that question, "it depends". Yes on the surface, it may be easier to use the one liner, they all have 100000 param for some purpose. if they are all slightly different, then I'd rather use the low level stuff.

Question for you. If you use the declare macro above...can you later in the script refer to $Slider1 directly even though you never actually coded a declare for that control yourself?


----------



## szcz (Nov 23, 2019)

Dewdman42 said:


> So KSP multi-script could access the automatable parameters of a commercial sample instrument, same as Kontakt's CC automation does?



Not really, multiscript can only process MIDI stream. So you would have change/add code at instrument level to make CC interact with given parameter. If it's commercial lib, hard luck as the script is most likely locked.
You can load factory MIDI monitor script into empty instrument and see that the event queue is preserved. It is for me, feeding from Sonar to Kontakt 5.

What are you trying to achieve? Microtuning by chance?


----------



## P.N. (Nov 23, 2019)

Fredeke said:


> Anyway, one reason I find KSP tedious is because of how strict it is when it comes to types, and it pains me how simple formulaes become unreadable when you nest int_to_real's into real_to_int's...


 
Are you saying that something like this is unreadable? (circle)


```
{x}%records[%rec_str[0] + $count + %rec_offset[$count2]] := real_to_int((0.50 + (int_to_real($radius) / 1000.0) * sin(~NI_MATH_PI * int_to_real($count) / int_to_real($pb_bars * $BAR_LENGTH) * int_to_real($pb_bars) * 2.0 - ~NI_MATH_PI / 2.0)) * 1000.0)
              {y}%records[%rec_str[0] + $REC_MAX + $count + %rec_offset[$count2]] := abs(real_to_int((0.50 + (int_to_real($radius) / 1000.0) * cos(~NI_MATH_PI * int_to_real($count) / int_to_real($pb_bars * $BAR_LENGTH) * int_to_real($pb_bars) * 2.0 - ~NI_MATH_PI / 2.0)) * 1000.0))
```

Be reasonable...


----------



## Dewdman42 (Nov 23, 2019)

szcz said:


> Not really, multiscript can only process MIDI stream. So you would have change/add code at instrument level to make CC interact with given parameter. If it's commercial lib, hard luck as the script is most likely locked.
> You can load factory MIDI monitor script into empty instrument and see that the event queue is preserved. It is for me, feeding from Sonar to Kontakt 5.
> 
> What are you trying to achieve? Microtuning by chance?



I was afraid of that. Yes it came up particularly for one commercial lib I sometimes use (Kirk Hunter) and its locked of course. There are a couple of functions on there that he does not provide a good keyswitch for, he provides a "toggle" which is a bad idea because an articulation system has no way of knowing whether its on or off currently. But of course you can easily use cc automation in kontakt to turn that particular control on or off directly (rather then toggling with the keyswitch he provided). I wrote some LogicPro scripts to send that CC per articulationID when needed, but what I found in my testing was that if you have a chord with different articulations on each note of the chord (yes, rare situation, but still), then the CC's from automation all get processed by the instrument before any of the notes. So the last CC sent from host...goes through automation...changes that control to whatever is it, then finally all the notes of the chord are processed by the instrument...and that is the problem. 

I have heard other people complaining about hard to solve CC switch issues in some Kontakt instruments, and I suspect its also related to this, but I don't know for sure whether this is a problem from using CC automation in kontakt as i was trying to do, or if kontakt is actually processing all CC's before notes. I suspect it has to do with Kontakt processing all the cc automation for a given beatpos before the notes. So the instrument has no control over it, I can't change the instrument anyway...and it sounds like a multi-script may not be able to work around it either.


----------



## szcz (Nov 23, 2019)

Dewdman42 said:


> LogicPro scripts to send that CC per articulationID when needed...



I see, I haven't tested how it works with automation... However I think it could be handled at multiscript level. Basically I guess what would need to be done, is to add microdelays if events arrive at the same song position, 300 microsecond delay is not audible, but would set order within the instrument processing. Or perhaps you can do that in Logic script? I would load MIDI monitor into Kontakt first and check if the events really arrive in order, maybe the problem is at host level...


----------



## Fredeke (Nov 23, 2019)

szcz said:


> I don't think it's complexity that matters here, I believe I have been dealing with fairly complex stuff (as far as Kontakt goes), maybe not, I don't know what are you dealing with. Anyway, what I meant, it's mainly a frame of mind problem. What I see, is that people who already program in some language seem to hate KSP when they are exposed to it. I had little programing experience prior to KSP and that was in 8 bit some long time ago, which is possibly why I have no discomfort here.


On one hand, I can respect that, as it's been my own stance more than once.
On the other, I can't help thinking you're missing out.



Dewdman42 said:


> Especially since Nil's approach is basically a pre-processor that produces KSP, I feel its important to understand even the generated KSP.


That's definitely right.

Just tonight, I had to go check what the preprocessor was spurting out in order to understand why I was using it wrong.

It's a good idea to begin with regular KSP. But you'll want some meat with your potatoes soon enough.



Dewdman42 said:


> Question for you. If you use the declare macro above...can you later in the script refer to $Slider1 directly even though you never actually coded a declare for that control yourself?


Yes of course.

I think you could write $Slider[1] (as in first element of an array) and the preprocessor would translate that to $Slider1, or you can write $Slider1 directly. (A senior member will surely correct me if I'm wrong)

Btw, EvilDragon's example is very basic. There are shortcuts in SumblimeKSP that would fill the height of your screen several times over in KSP, and not because of mere repetitions. (Well, ok, partly because of them. But not just.)


----------



## Dewdman42 (Nov 23, 2019)

I have thought of doing some stuff like that where I detect that poly-articulation situation and add some delay, which from Logic Pro the least amount of delay possible from Scripter is 1/960th of a beat. Probably small enough to not detect as you say. But I'd actually rather have a multi-script do it in kontakt so that my Articulation Scripts don't have to have that in them complicating them all... one simple kontakt-fixer multi-script would be easier. Sounds like maybe I might be able to get a smaller delay with multi-script also if you're able to schedule things there based on sample position rather then beat pos.

and yea I did already check with the monitor. Host was sending exactly as intended.


----------



## Dewdman42 (Nov 23, 2019)

I guess another question would be this...KSP multi-script...is that before CC automation also? And presumably kontakt processes cc automation once per process block...which is generally the size in time of the audio sample buffer. so all events within that window would be processed together..first the CC automation, then the notes. So basically any kind of script would need to delay each note in the poly-articulation chord by enough of an amount to go to separate process blocks each. I think? That most likely means something more like 1ms apart.


----------



## EvilDragon (Nov 23, 2019)

Dewdman42 said:


> Question for you. If you use the declare macro above...can you later in the script refer to $Slider1 directly even though you never actually coded a declare for that control yourself?



Yes, the code above also creates an array containing UI ID arrays for direct access to the control, by using <name-of-control>[x] array. But also yes, you can use the direct name of any of the generated sliders directly. So you can:


```
define NUM_SLIDERS := 10
declare ui_slider Slider[NUM_SLIDERS] (0, 1000000)

Slider6 := 100
```





Dewdman42 said:


> KSP multi-script...is that before CC automation also?



Multiscript intercepts all incoming MIDI, AFAIK.




Dewdman42 said:


> And presumably kontakt processes cc automation once per process block...



Kontakt processes things internally in 32 samples buffers.






Fredeke said:


> I think you could write $Slider[1] (as in first element of an array)



_Second _element of the array  And you'd write %Slider[1], of course. Or just not use %, because meh. 

And it actually doesn't translate to $Slider1, it translates to get_ui_id($Slider1).


----------



## szcz (Nov 23, 2019)

Dewdman42 said:


> I guess another question would be this...KSP multi-script...is that before CC automation also?



Easy to check. Such script ain't complicated, try this...



Spoiler: code





```
on init
    
    set_script_title("force schedule")
    
    {
    detect events that occur within given frame (value in milliceconds - 1/1000 s),
    delay all events that occur within the timeframe by defined delay (value in microseconds = 1/1000000),
    second event receives double delay, third received tripple delay and so on...
    }
    
    declare ui_value_edit $delay(100,5000,1)
    declare ui_value_edit $frame(1,200,1)
    declare ui_button $on
    $delay := 500
    
    declare $x
    declare $event_counter
    declare $time_checkpoint
    
    make_persistent($delay)
    make_persistent($frame)
    make_persistent($on)
    
end on

on midi_in
    if($on =1)
        if($MIDI_COMMAND = $MIDI_COMMAND_NOTE_OFF or $MIDI_COMMAND = $MIDI_COMMAND_NOTE_ON or $MIDI_COMMAND = $MIDI_COMMAND_CC) {only process notes and CC}
            
            $x := $ENGINE_UPTIME - $time_checkpoint {how much time passed from last event?}
                
            if($x <= $frame) {not enough, delay event}
                inc($event_counter)
                ignore_midi
                wait($delay * $event_counter)
                set_midi($MIDI_CHANNEL,$MIDI_COMMAND,$MIDI_BYTE_1,$MIDI_BYTE_2)
            else
                $time_checkpoint := $ENGINE_UPTIME
                $event_counter := 0
            end if
            
        end if
    end if
end on
```



Just note that frame is in milliseconds and delay in microseconds (that's very short, so 5000 is 5 ms delay, practically inaudible). As I checked in Sonar, frame=1 catches all four notes aligned at certain position in my host.
Note that it could potentially make stuck notes, if you had a super-short notes defined in your host (like 1ms duration) your 'note on' could be delayed so it would go after 'note off'. Not very likely in practice, but for the record...


----------



## Fredeke (Nov 23, 2019)

EvilDragon said:


> _Second _element of the array  And you'd write %Slider[1], of course. Or just not use %, because meh.
> 
> And it actually doesn't translate to $Slider1, it translates to get_ui_id($Slider1).


Right. 
(And right again.)


----------



## Fredeke (Dec 12, 2019)

szcz said:


> I had little programing experience prior to KSP and that was in 8 bit some long time ago, which is possibly why I have no discomfort here.


Sure, if you were the type who coded directly in binary (I've seen hackers and demomakers do that on the C64), then I guess nothing can sway you after that


----------



## Lord Adef (Dec 14, 2019)

Hi guys,
I´m new here. So I´m also new to KSP.
KSP itself is actually rather easy! With SublimeKSP things flows very nicely.

The Kontakt interation is another story though, and may need some time to dig in.

If you have some programming experience you wouldn´t have any problems at all.


----------



## Fredeke (Dec 15, 2019)

Lord Adef said:


> Hi guys,
> I´m new here. So I´m also new to KSP.
> KSP itself is actually rather easy! With SublimeKSP things flows very nicely.
> 
> ...


I think that's well summarized. The language is simple, but addressing Kontakt's components is a little more tricky.
@NormkbPlayer : Remember to read the stickies in this forum. Especially @EvilDragon 's one about modulations.

@Lord Adef : welcome


----------



## estevancarlos (Feb 21, 2022)

Fredeke said:


> KSP is a rather tedious language because it was devised with real time efficiency in mind, rather than convenience.
> 
> However, several free 3rd party projects merged into SublimeKSP, a KSP pre-compiler plugin for Sublime Text Editor (of which the free demo is fully workable). It adds a lot of useful features to the language, like real functions, _for_ loops, multi-dimensional arrays, macros, syntax highlighting, etc.
> 
> ...



Wait wait wait wait

I'm new to KSP. Just barely reading through the documentation now. It does not have functions or for loops? I was actually google searching to see if supports OOP... I'm assuming it doesn't?


----------



## EvilDragon (Feb 22, 2022)

It's not an OOP language, it's procedural and callback-based. It does have functions but without arguments and returns (SublimeKSP allows you to hack those in). And it indeed only has while loops (but again you can have for loops with SublimeKSP). There are also no namespaces or local variables (again, SublimeKSP allows you to hack those in).


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> It's not an OOP language, it's procedural and callback-based. It does have functions but without arguments and returns (SublimeKSP allows you to hack those in). And it indeed only has while loops (but again you can have for loops with SublimeKSP). There are also no namespaces or local variables (again, SublimeKSP allows you to hack those in).



Not gonna lie. I'm extremely surprised. Thanks for clarifying.


----------



## EvilDragon (Feb 22, 2022)

Gotta be extremely fast and lean in order to be ran in a realtime audio thread...


----------



## neblix (Feb 22, 2022)

EvilDragon said:


> Gotta be extremely fast and lean in order to be ran in a realtime audio thread...


Yeah, that's why all audio plugins are written in C++, a language that foregoes the use of functions with arguments, for loops, namespaces, and local variables.


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Gotta be extremely fast and lean in order to be ran in a realtime audio thread...



That's a good point. Some technologies strike a balance. For example, my main area of expertise, MaxMSP supports Javascript for non-realtime thread. Then you can write C-like code in the audio thread.


----------



## EvilDragon (Feb 22, 2022)

neblix said:


> Yeah, that's why all audio plugins are written in C++, a language that foregoes the use of functions with arguments, for loops, namespaces, and local variables.


Sure but C++ is compiled not interpreted in realtime.


----------



## tack (Feb 22, 2022)

Performance isn't a good reason for KSP being such a terrible, frustrating language. These things are solved problems. I mean, not that JSFX is a paragon of language design, but at least has these basic language constructs and executes quickly.

Also, when you consider the aforementioned SublimeKSP simulates enough of these capabilities while transpiling to native KSP, it seems to me that defeats any performance-related argument justifying KSP's crimes against humanity.


----------



## estevancarlos (Feb 22, 2022)

tack said:


> Performance isn't a good reason for KSP being such a terrible, frustrating language. These things are solved problems. I mean, not that JSFX is a paragon of language design, but at least has these basic language constructs and executes quickly.
> 
> Also, when you consider the aforementioned SublimeKSP simulates enough of these capabilities while transpiling to native KSP, it seems to me that defeats any performance-related argument justifying KSP's crimes against humanity.



Yeah... it's 2022. 

Then there's MaxMSP's approach of two languages (C-like and Javascript). We probably could have KSP and also an NI-official transpiling language.


----------



## EvilDragon (Feb 22, 2022)

Transpiling can really blow up though with larger projects, sometimes lasting several minutes if there are a lot of includes etc... It's a bandaid, not a solution (and we're glad it exists anyways).

At any rate, KSP is from 2005 so you gotta think with 2005 mindset. LuaJIT wasn't really there back then. Because if it were, I'm sure NI would've went with it.  But this is a good question - what was out there in 2004-2005 that was an interpreted scripting language that was fast enough to be running in the RT audio thread on computers of that time?


----------



## tack (Feb 22, 2022)

There's nothing preventing KSP as a language from having evolved in a backward compatible way over the past 17 years. I think it's fair to criticize it from the lens of today, even if the language was conceived almost two decades ago. Because it's not like language design improvements isn't a thing, even in DSLs. Indeed, KSP _has_ evolved in the sense that new functions become available. No reason the core syntax couldn't also improve over time, while maintaining backward compatibility.


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Transpiling can really blow up though with larger projects, sometimes lasting several minutes if there are a lot of includes etc... It's a bandaid, not a solution (and we're glad it exists anyways).
> 
> At any rate, KSP is from 2005 so you gotta think with 2005 mindset. LuaJIT wasn't really there back then. Because if it were, I'm sure NI would've went with it.  But this is a good question - what was out there in 2004-2005 that was an interpreted scripting language that was fast enough to be running in the audio thread on computers of that time?



I think transpiling should just be an official option at this point. Not necessarily replacing KSP. 

Too often I use MaxMSP as an example with these technologies. They are older than Kontakt. They added JS support in the early 2000s (I think) and then followed up with C-like support. Of course Max is very inefficient, so that's one thing. You're right that transpiling is a band-aid. It just seems like the best band aid for Kontakt since it would be too disruptive to replace KSP.


----------



## EvilDragon (Feb 22, 2022)

tack said:


> There's nothing preventing KSP as a language from having evolved in a backward compatible way over the past 17 years.


In theory, yes. In practice, it's always effort vs returns I guess...


----------



## tack (Feb 22, 2022)

EvilDragon said:


> In practice, it's always effort vs returns I guess...


I certainly agree with that. The cost-benefit isn't always clear, and when you have an operational monopoly you can often afford to shift the development burden to your customers. But this is a very different argument than the performance one.


----------



## EvilDragon (Feb 22, 2022)

I think it's also a bit of a "cursed if you do, cursed if you don't" situation. Any major change to syntax will create friction and added learning curve. Is this really something that this super small cottage industry needs? Remains to be seen.


----------



## tack (Feb 22, 2022)

ED you'd know this better than I do, how many developers are using Nils' KSP extensions in production code? Is it fringe, or popular?


----------



## Mike Greene (Feb 22, 2022)

EvilDragon said:


> I think it's also a bit of a "cursed if you do, cursed if you don't" situation. Any major change to syntax will create friction and added learning curve. Is this really something that this super small cottage industry needs? Remains to be seen.



That's an important point. While I'm a little out of my depth here (okay, _way_ out of my depth) talking about the benefits of one language over another, I will say that I personally like KSP as it is. It certainly has its limitations (don't get me started!  ), but it's sooooo straightforward, and the linearity is really easy to follow. I think that's a hook for beginners to get started and NI wouldn't want to lose that.

In fact, years ago, I was reading some discussion here and I realized I was able to follow the code, line by line, and I thought "Hey, I can do this!" (It helped that I had a class in PASCAL in college, which I'd bet KSP used as a model.) That realization is was what got me started, and I'll bet I'm not the only one.

So I think there could be a danger to modernizing KSP too much, because you might lose the novices. Object oriented languages are great (I know just enough Python to get myself in trouble), but
it's conceptually much less intuitive, because of all the _"Look here, now look over there, now look in this third place."_ Don't get me wrong, it's great that you can have master scripts with often-used functions that newer scripts can refer to, but that's much more difficult to follow for someone new to coding. Not to mention a Kontakt rookie is likely to stumble on the concept of a function's local variables (arguments) having different names from when the function is called. Easy concept for veterans, mind-blowing concept for rookies.

Don't get me wrong, now that I've gotten my feet wet, I wouldn't be mad at a more object oriented approach, and damn, these KSP scripts can be loooooong! But we do have Sublime-KSP, which solves a lot of the KSP shortcomings (thank you to all involved in that!), so if I were NI, I'd be reluctant to make any structural changes there.


----------



## EvilDragon (Feb 22, 2022)

tack said:


> ED you'd know this better than I do, how many developers are using Nils' KSP extensions in production code? Is it fringe, or popular?


I think at this point almost everyone uses it. Almost! But this is a personal guesstimate since there's no usage data tracking built into Sublime Text or the add-on. 



Mike Greene said:


> I will say that I personally like KSP as it is.


I like it too. And I'm fully aware it's the best possible example of Stockholm syndrome there is! 



Mike Greene said:


> and damn, these KSP scripts can be loooooong!


Which is why you should (friendly advice) spend some time in structuring your code better and moving things that belong to a certain functional part of the interface and/or engine to separate files. Then you just import them in a master file. Sublime Text still allows you to quickjump between function definitions even across multiple files (Ctrl+R on Win, and I guess Cmd+R on Mac).


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> I think at this point almost everyone uses it. Almost! But this is a personal guesstimate since there's no usage data tracking built into Sublime Text or the add-on.
> 
> 
> I like it too. And I'm fully aware it's the best possible example of Stockholm syndrome there is!
> ...



If there was an transpile language that supports OOP and renders to KSP, we could write briefer code (I actually don't know of the SublimeKSP supports OOP though).

Regarding the risk of changing the syntax, definitely true. Javascript went through a necessary evolutionary period between 2006 to today. Javascript was actually invented! within two weeks back in early 90s. It was never intended to be a serious language. It needed to ship with Netscape Navigator. Once business pressures increased, the organization that manages the language discussed and planned a series of updates over the span of 10 years. It worked fine. I think the same could be done for KSP if NI was interested in doing so. The ECMAScript organization that manages the language even added convenience features to simplify the process of writing code. It's been a great move.


----------



## tack (Feb 22, 2022)

Mike Greene said:


> While I'm a little out of my depth here (okay, _way_ out of my depth) talking about the benefits of one language over another, I will say that I personally like KSP as it is.


I think this might be a case of ignorance is bliss. Not having a lot of experience with other languages makes it harder to notice how much more painful KSP really has any right to be. Basically, you spend your life as a developer building a mental library of patterns to solve common problems, and then repeatedly find they don't work in KSP, quite commonly due to the lack of a fairly basic language construct.

I'm not talking about going full OOP with all kinds of fancy convenient data types. (Though I don't think a simple low-cost Lua-like table is _too _much to ask for. )

Rather, a few straightforward and computationally free abstractions could significantly improve developer effort, code readability, and supportability. Control flow improvements like break and return, perhaps continue (though less important). Functions as first class objects. Actual functions with actual arguments, for that matter. (I can only imagine how much inline function duplication exists for very large projects that use SublimeKSP's function abstractions.) Native structs.

I mean, look how verbose this code is. If there's a way to make that code less redundant, I couldn't find it. In every other language, I'd just assign the inner struct to a tmp variable and use that, rather than fully qualifying it every time. (Well really I'd use whatever the language offered to copy structs, even if it's as simple as memcpy().) Please school me if I've missed an easy trick!

(I know nojanath's fork of SublimeKSP has some extra features like structs. I haven't worked with this fork yet, but I didn't notice any features that would have simplified this example.)



EvilDragon said:


> I think at this point almost everyone uses it. Almost!


That was my intuition too. But isn't this an argument against your concern about increasing the learning curve?

Clearly developers are willing to learn a bit more syntax if it makes their overall code more readable and less DRY, generally making them more productive.


----------



## EvilDragon (Feb 22, 2022)

tack said:


> (I can only imagine how much inline function duplication exists for very large projects that use SublimeKSP's function abstractions.)


Not a lot if you know what you're doing... The trick is to use a macro to set up function arguments and then call a regular KSP function, then you get callable functions with arguments. Or you can use Big Bob's taskfuncs (with the added benefit of thread safety).



tack said:


> But isn't this an argument against your concern about increasing the learning curve?



I'm not entirely sure. I would bet many have gotten to grips with vanilla KSP first (I know I have, at the very least, but I know a bunch of others who were the same), before embarking on the sytactic sugary trip with sKSP... But we're really entirely in guesstimation world now.



tack said:


> I know nojanath's fork of SublimeKSP has some extra features like structs. I haven't worked with this fork yet


Why tf aren't you on this one? Dude! Get on with the program!  (It's the only one that is actually being up to date with any recent additions to vanilla KSP, to my knowledge.)




estevancarlos said:


> Javascript went through a necessary evolutionary period between 2006 to today. Javascript was actually invented! within two weeks back in early 90s. It was never intended to be a serious language.


Oh man... this is almost the same scenario as with KSP. Everything snowballed.

Initially, KSP was supposed to be internal only, NI wanted to mimic the articulation matrix feature from Vienna's player. It really was just a basic MIDI processor originally (=what multiscripts are currently). Then guys from Soniccouture came in and did some interesting things. In the very early versions there wasn't even a wait() command! So Dan from SC asked for it so that they could do sequencing and arpeggiators... Wolfgang Schneider (OG dev of Kontakt) said that is not gonna be possible... so he went and hacked it in in two days. It really snowballed from there, SC made that Kontakt Experience library that was basically an early KSP showcase. The rest is history.


----------



## polypx (Feb 22, 2022)

2005... crazy times.


----------



## Mike Greene (Feb 22, 2022)

tack said:


> I think this might be a case of ignorance is bliss.


Could be. If I had actual coding experience (other than a few classes in college, included a FORTRAN class where we used punch cards), I'm sure I would find KSP to be awful. My son has a CS degree and he teases me that KSP is "cute."

For coding beginners, though, which is a category I think most Kontakt developers started as, something like Python looks like gobbledygook, and I think I would have been too intimidated if that's what I had seen in that fateful thread years ago.

My guess is most sample developers didn't start off as coders. When I tell my friends why I started this company, I tell them it's because I had a recording facility, I had really good singers in my Rolodex, I have an ear for what sounds good and what doesn't, I have available cash, and I have enough mathematical abilities that I could learn the coding.

In other words, the coding is just one of many requirements, and in most cases, not the most important one. When I saw that _"Hey, I understand what this script is doing!"_ thread years ago, I wasn't thinking that I'd learn KSP and build a company around that. Rather, I was thinking I have a studio, I know singers, and I can afford to pay them. So I can start with that, then figure out just enough code to create a legato script and make an instrument. That's the appeal of a simple (albeit weak) scripting language. It gives the impression, _"You can do this!"_

That's just me, though, and for sure you're right that the Kontakt scripting language could be much slicker. I'm just not sure I could have gotten there, though.


----------



## Mike Greene (Feb 22, 2022)

EvilDragon said:


> Initially, KSP was supposed to be internal only, NI wanted to mimic the articulation matrix feature from Vienna's player. It really was just a basic MIDI processor originally (=what multiscripts are currently). Then guys from Soniccouture came in and did some interesting things. In the very early versions there wasn't even a wait() command! So Dan from SC asked for it so that they could do sequencing and arpeggiators... Wolfgang Schneider (OG dev of Kontakt) said that is not gonna be possible... so he went and hacked it in in two days. It really snowballed from there, SC made that Kontakt Experience library that was basically an early KSP showcase. The rest is history.


Whoa! I didn't know any of that. Way to go, Dan! (@polypx )


----------



## polypx (Feb 22, 2022)

I agree with Mike that KSP is well designed because it does "exactly what it says it does". As such it's easy to understand and people can start very simply, get the idea, grow from there. Basically KSP doesn't need to be complicated, because all it's doing is exposing a bunch of "under the hood" stuff to user manipulation.

Code is always developing levels of abstraction balanced upon previous levels of abstraction, and Sublime KSP is basically our first level of abstraction from vanilla KSP. That's fine, it works. We can all still READ vanilla KSP when we need to. 

It's not like we need to do incredibly complicated things most of the time ... sure, a 'browser' is hard and cumbersome to build, but not THAT hard if you really think about it. I think structures like legato actually benefit from being "close to the action" ... too much abstraction would probably result in bloated code, and not exploit the best of what Kontakt already offers internally. Using Kontakt to do what Kontakt ALREADY DOES, that's one of the things you always have to balance against KSP.


----------



## estevancarlos (Feb 22, 2022)

Mike Greene said:


> Could be. If I had actual coding experience (other than a few classes in college, included a FORTRAN class where we used punch cards), I'm sure I would find KSP to be awful. My son has a CS degree and he teases me that KSP is "cute."
> 
> For coding beginners, though, which is a category I think most Kontakt developers started as, something like Python looks like gobbledygook, and I think I would have been too intimidated if that's what I had seen in that fateful thread years ago.
> 
> ...



Here's one way to think about it. You can write procedural type code in more robust languages. In other words some languages allow you write in a simple way if you choose. I teach the basics of programming and we often don't address advanced topics in the first semester. Students end up writing in a very procedural way using the language of Javascript and others.

BUT if KSP supported more advanced topics, it can make code more modular and reduce the amount of code we have to write.


----------



## EvilDragon (Feb 22, 2022)

Making code more modular and reducing the amount of code you have to write is _exactly_ what SublimeKSP offers.

https://nilsliberg.se/ksp/scripts/tutorial/editor.html (from old standalone editor - this is all basis for SublimeKSP)
https://github.com/nojanath/SublimeKSP/wiki/Added-Features


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Making code more modular and reducing the amount of code you have to write is _exactly_ what SublimeKSP offers.



Yes I understand. It sounds good. I'm partly surprised it's just not an official effort from NI baked into the language.


----------



## EvilDragon (Feb 22, 2022)

Because it's not as immediate as vanilla KSP, it's an intermediate step that takes time. But also, it's open source so there's no real incentive for NI to repeat the work that was already done by somebody else, when it's already out there.


----------



## tack (Feb 22, 2022)

Mike Greene said:


> That's just me, though, and for sure you're right that the Kontakt scripting language could be much slicker. I'm just not sure I could have gotten there, though.


I'm not arguing for a new world order or anything. Just a few extra basic language features and zero-cost ergonomic improvements that most other languages have would go an very long way in making KSP code more readable and supportable.


----------



## EvilDragon (Feb 22, 2022)

What would be those "zero cost" ergonomic improvements? I bet they still cost dev time.


----------



## tack (Feb 22, 2022)

EvilDragon said:


> Because it's not as immediate as vanilla KSP, it's an intermediate step that takes time.


Isn't all the code compiled into an intermediate bytecode when it's shipped with the NKR anyway? Or is it just obfuscated?



EvilDragon said:


> What would be those "zero cost" ergonomic improvements? I bet they still cost dev time.


Zero _runtime performance_ cost. All changes require dev and QA time, of course.

But, ok, I seem to be in the minority here. If most developers building Kontakt libraries are happy with KSP -- shocking though that may be to me -- obviously NI would be pretty irrational to try to improve it.


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Because it's not as immediate as vanilla KSP, it's an intermediate step that takes time. But also, it's open source so there's no real incentive for NI to repeat the work that was already done by somebody else, when it's already out there.



I don't know how SublimeKSP works yet but if it completely abstracts the Vanilla KSP, then that is a problem. Which means there's still room for improvement. 

I wrote some somewhat procedural stuff in Lua but I could integrate it with more advanced topics at the same time. They could be side by side. I would hope that SublimeKSP allows you write vanilla and advanced KSP at the same time, no?


----------



## tack (Feb 22, 2022)

estevancarlos said:


> I would hope that SublimeKSP allows you write vanilla and advanced KSP at the same time, no?


It does. It's a transpiling superset language like Typescript: you can use its features, which transpile to native Javascript, or you can just write direct Javascript.


----------



## EvilDragon (Feb 22, 2022)

tack said:


> Isn't all the code compiled into an intermediate bytecode when it's shipped with the NKR anyway? Or is it just obfuscated?


There is no intermediate bytecode with KSP. There's a parsing step to check if syntax is alright but from that point it's all interpreted in realtime (literally calling Kontakt's internal C++ engine I/O functions to change effect or other parameters, for example). When you build an NKR it's just packed into a monolith, when you do a Player library you have an option to encrypt the NKR. Still, no intermediate bytecode, this is not Java  Obfuscation is an optional SublimeKSP feature, yes, which just mangles the variable names. This just makes it more difficult to debug (i.e. if you use Creator Tools to have a proper multi-line debug view).



estevancarlos said:


> I don't know how SublimeKSP works yet but if it completely abstracts the Vanilla KSP, then that is a problem. Which means there's still room for improvement.


You write your code in SublimeKSP, you press F5 (or Cmd+K on Mac) and it compiles it and shoves it into system clipboard (or optionally also spits it out into a txt file). From here you paste that into Kontakt (or link to the txt file from the resource container).


----------



## estevancarlos (Feb 22, 2022)

tack said:


> But, ok, I seem to be in the minority here. If most developers building Kontakt libraries are happy with KSP -- shocking though that may be to me -- obviously NI would be pretty irrational to try to improve it.



I think this essentially the problem. Some devs probably don't know what the alternative are (Cough, UVI Falcon + Lua). I am 100% positive if every Kontakt dev spent 1 week on something like Falcon, they would at least ask NI to make improvements to their tools. I keep having to encounter a painful reality in my life: popular technologies are not always "good" technologies.


----------



## tack (Feb 22, 2022)

EvilDragon said:


> Still, no intermediate bytecode, this is not Java


That's nothing unique to Java. All LLVM-supported languages do that. Even Python compiles to a bytecode.

So, ok, if there's no intermediate bytecode for KSP, then yes, a built-in transpiler would slightly slow down load times. More of an argument to improve the language natively -- or would be, if KSP's limitations bothered anyone but me.


----------



## estevancarlos (Feb 22, 2022)

tack said:


> It does. It's a transpiling superset language like Typescript: you can use its features, which transpile to native Javascript, or you can just write direct Javascript.



Okay, that sounds as I would expect.


----------



## estevancarlos (Feb 22, 2022)

tack said:


> That's nothing unique to Java. All LLVM-supported languages do that. Even Python compiles to a bytecode.
> 
> So, ok, if there's no intermediate bytecode for KSP, then yes, a built-in transpiler would slightly slow down load times. More of an argument to improve the language natively -- or would be, if KSP's limitations bothered anyone but me.



Na, they bother me too but I'm having to ask myself if I'm being picky. I'm probably not being picky. I've written in so many languages as it is. I even like C.


----------



## EvilDragon (Feb 22, 2022)

estevancarlos said:


> Some devs probably don't know what the alternative are (Cough, UVI Falcon + Lua). I am 100% positive if every Kontakt dev spent 1 week on something like Falcon, they would at least ask NI to make improvements to their tools.


Actually a lot of the devs are quite familiar with what's out there. But you cannot beat the market reach that Kontakt has. I do have Falcon and I love it, but it is not as performant as Kontakt (no multicore support etc.). It is definitely not suitable for libraries that rely on a large number of samples, and there's no background loading...

But most of all, even UVI people are not interested in competing directly with Kontakt, which is also showcased by the sort of products they release.


That said, people at NI do like Lua (as evidenced by its inclusion in Creator Tools). _Something_ tells me this is not the last time we will see it in context of Kontakt...


----------



## EvilDragon (Feb 22, 2022)

tack said:


> That's nothing unique to Java.


Oh I know! It's just that, somehow, Java came first to mind when I read "bytecode"


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Actually a lot of the devs are quite familiar with what's out there. But you cannot beat the market reach that Kontakt has. I do have Falcon and I love it, but it is not as performant as Kontakt (no multicore support etc.). It is definitely not suitable for libraries that rely on a large number of samples, and there's no background loading...
> 
> But most of all, even UVI people are not interested in competing directly with Kontakt, which is also showcased by the sort of products they release.



Okay. I guess you would know. Yeah, I don't get the impression UVI is even interested in 3rd party stuff too much. And Falcon is only optimal for certain types of libraries. I can see that.


----------



## EvilDragon (Feb 22, 2022)

Basically I love it as a sound designer's playground. All the different oscillator types are super fun to mix and match and just have a ball. Sure you can also make a pretty great product with it! I don't know why there's not more UVI Workstation (=Kontakt Player) content out there... it's like UVI literally doesn't _want_ 3rd parties (even though they do have _some_).


----------



## estevancarlos (Feb 22, 2022)

EvilDragon said:


> Basically I love it as a sound designer's playground. All the different oscillator types are super fun to mix and match and just have a ball. Sure you can also make a pretty great product with it! I don't know why there's not more UVI Workstation (=Kontakt Player) content out there... it's like UVI literally doesn't _want_ 3rd parties (even though they do have _some_).



Yeah, it feels like a mystery to me.


----------



## Mike Greene (Feb 22, 2022)

estevancarlos said:


> I would hope that SublimeKSP allows you write vanilla and advanced KSP at the same time, no?


Yes. When you compile a script that you wrote in SublimeKSP, it converts it to vanilla KSP. (Everything has to end up as vanilla KSP.) So for example, you can have a "for" loop in SublimeKSP, but when you compile, it converts that "for" loop into a "while" loop, so Kontakt can read it.

But you don't _have_ to use all the fancy SublimeKSP tricks, so I often write while loops manually, even though using a "for" loop would be easier. I do that simply because I've done so many while loops over the years that it's just a habit to write the extra lines.

You can totally mix and match, and when you compile, Sublime converts the things that needs converting and it leaves the stuff that doesn't need converting as is.



tack said:


> -- or would be, if KSP's limitations bothered anyone but me.


I'm sure there are a whole lot of you. It's just that with me, at least, it's a case of pearls before swine. 

Like I said, I still write while loops manually half the time. I'm only one step more advanced than my wife, who still goes to the Files tab to save a Word doc, instead of clicking Apple-S. 



estevancarlos said:


> Yeah, I don't get the impression UVI is even interested in 3rd party stuff too much.


I asked them this specifically at NAMM a couple years ago, offering to give them some space on VI-Control similar to what we have here for Kontakt developers, but they told me they're not interested in expanding their third party reach. I thought that odd, but I can see how it might be more trouble than it's worth, since supporting third party libraries makes comparatively little money, while the real money is in their own releases.


----------



## davidnaroth (Feb 22, 2022)

Whats the most similar language to KSP? or what is KSP based off of? I have a feeling it starts with a C but not sure if those are the closest or not


----------



## EvilDragon (Feb 23, 2022)

KSP syntax and certain approaches are very much like Pascal. For example, floats are called reals, value assignment is := not =, and so on.


----------



## EvilDragon (Feb 23, 2022)

Mike Greene said:


> so I often write while loops manually, even though using a "for" loop would be easier. I do that simply because I've done so many while loops over the years that it's just a habit to write the extra lines.


You don't even need to _write _the extra lines! Use snippets! This is when you start typing some keyword, then you will see this in autocomplete:






Then you press Tab and it autocompletes the rest of while loop for you. You enter your condition then press Tab to jump to the body of the loop. There's dozens of other snippets that come with SublimeKSP. For example you can just start typing "fun" then press Tab and it autocompletes a function declaration for you. Same thing for UI widgets and some other stuff too (say you start typing "iei" then Tab, you get an if-else if constructed in a jiffy)!


----------



## soniccouture (Mar 2, 2022)

EvilDragon said:


> It really snowballed from there, SC made that Kontakt Experience library that was basically an early KSP showcase. The rest is history.



Wooh!

Just to clarify - NI made 'Kontakt Experience' as an NI product, and we (Soniccouture) ended up contributing most (but not all) of the patches to it (we had nothing much else to do in those days).
My point being that NI *was* trying to promote and open up KSP early on. In my recollection they always saw it as a selling point for Kontakt, not an internal tool, but really it didn't pan out quite as they saw it, but kind of half-way between the two I guess.

Soniccouture then released the remaning unused patches submitted for Kontakt Experience as 'Abstrakt Vol.1' (The first SC product), which included 5 or 6 KSP modules for the user to load up - things like 'Analog Oscillators', a tuning de-stabilising script.


James


----------



## EvilDragon (Mar 2, 2022)

Thanks for additional details, James!


----------



## Pier (Mar 2, 2022)

EvilDragon said:


> I don't know why there's not more UVI Workstation (=Kontakt Player) content out there... it's like UVI literally doesn't _want_ 3rd parties (even though they do have _some_).


My impression is also that UVI is not really interested in 3rd party content (not published by UVI).

It's a weird position but I guess they must be doing alright (financially speaking).


----------

