# HISE as Alternative to Kontakt (Split from NI-Partnership Thread)



## EvilDragon (Mar 1, 2018)

*NOTE FROM MODERATOR: This discussion originally started in the Native Instruments - An Eco-System for Your Sounds thread, but merits its own thread. Lindon had mentioned HISE as an option, then Mario responded with the following:*

Don't you need to own JUCE (which is €1000) if you want to release commercial products with HISE (correct me if I'm wrong)? It's a one-time fee, but it's not quite what I would call a small upfront fee...

Also still curious about its CPU efficiency compared to Kontakt... I don't recall seeing any head to head tests.


----------



## Lindon (Mar 2, 2018)

EvilDragon said:


> Don't you need to own JUCE (which is €1000) if you want to release commercial products with HISE (correct me if I'm wrong)? It's a one-time fee, but it's not quite what I would call a small upfront fee...
> 
> Also still curious about its CPU efficiency compared to Kontakt... I don't recall seeing any head to head tests.



Yes you are wrong. The JUCE license is less than this I think but you dont need to have it in any case to release a HISE product as far as I am aware. But even assuming you are correct its a one-off fee NOT a per instrument fee, so amortised over several releases. 

CPU - well I havent seen any apples-to-apples comparision either - but its written(as you observe) in JUCE C++ so I think it would be unlikely to be a CPU fail device.


----------



## gregh (Mar 2, 2018)

Most of the libraries I buy are not official Kontak libraries (or whatever it is called) what is the advantage to a developer to have the full blown license? Ie how much more money will you make


----------



## d.healey (Mar 2, 2018)

They recently changed the JUCE license when version 5 was released - https://juce.com/get-juce

If you want to release a proprietary product with HISE then you have to get a JUCE license and a HISE license - talk to Christoph for more info.

ED how would you do a head to head test between two quite different platforms? I'd be happy to run some test but I'm not sure how to go about it.


----------



## EvilDragon (Mar 2, 2018)

d.healey said:


> ED how would you do a head to head test between two quite different platforms? I'd be happy to run some test but I'm not sure how to go about it.



Well, do the similar things in both of them. See the CPU when streaming hundreds of voices, throw some filters in there and see how it compares, etc. I truly wonder how efficient JavaScript is compared to bytecode compiled and assembler optimized KSP... I know Christoph did some optimizations (I watched that presentation video) to it, but it still seems like those optimizations he did are pretty limited (like, you have this fast variable type, or something, but you can only have a finite number of such variables in a script, etc.)



Lindon said:


> Yes you are wrong. The JUCE license is less than this I think but you dont need to have it in any case to release a HISE product as far as I am aware. But even assuming you are correct its a one-off fee NOT a per instrument fee, so amortised over several releases.



Looks like it's not a one-off fee any longer, it's a per-month subscription, as David linked. Doesn't really even out the playing field IMHO.



Lindon said:


> but its written(as you observe) in JUCE C++ so I think it would be unlikely to be a CPU fail device.



Kontakt is written in C++ as well with assembler optimizations, what's your point? :D I'm more concerned about JavaScript vs KSP, because one is JIT interpreted (AFAIK) and the other is bytecode compiled with heavy optimizations for realtime usage... And also concerned on efficiency of HISE's DSP. Last time I checked you could prototype your own effects but that wasn't particularly CPU efficient, it has to be compiled (and even then I'm not sure it can be as deeply optimized with SSE and AVX - again, guys, correct me if I'm wrong).


Again - not to knock on HISE. I think it's a wonderful project, but I still feel it still has some ways to go.


----------



## d.healey (Mar 2, 2018)

EvilDragon said:


> Looks like it's not a one-off fee any longer, it's a per-month subscription, as David linked. Doesn't really even out the playing field IMHO.


It's not so obvious on that page but if you look at the bottom of each table there is a one off fee option still, and even better (well kind of) it's now free for proprietary use with a personal license if you are making less than $50k a year.


----------



## EvilDragon (Mar 2, 2018)

Ah, gotcha. Well that ain't too shabby for smaller devs for sure.


----------



## Lindon (Mar 2, 2018)

Wow its the Smalltalk vs C++ argument all over again:

"JIT interpreted (AFAIK) and the other is bytecode compiled"

Do a quick look on the interwebs and you will see a well structured interpreter(and Javascript has one - its essentially copied from Smalltalk) will perform as well as a bytecode compiled object . Look at the JAVA vs C++ comparisons their results may seem counter intuitive but they have proven out. Even worse in this case we are looking at a comparison between a well-worn(I will grant you) vendor-specifc bytecode and an industry standard interpreter model. I will leave you to assess which might be the more efficient.

But hey if you think HISE is slow then sure it might be. 

Prototyping your own effects (something you cant come even near in Kontakt)? Yes there's a tiny-C compiler in there. 

So hanging HISE for "poor DSP" and then using "you can prototype your own effects" is in-genuine. HISE instruments, just like Kontakt, can have poorly written(prototype) code from its user base, and that has nothing to do with the native performance of either product.


----------



## EvilDragon (Mar 2, 2018)

Exactly because KSP is well-worn and heavily purpose-optimized, in my mind I feel it might perform better than industry standard interpreter which needs to be all things to everything (even after admittedly smart optimizations Christopher did)...


----------



## d.healey (Mar 2, 2018)

It's proving difficult for me to do a meaningful comparison with HISE and Kontakt at the mo because I'm running Kontakt under WINE and I can't compile HISE to a VSTi on Gnu/Linux yet and HISE isn't as efficient as the plugins it exports. I think someone would need to do test on Windows or Mac for it to be useful.


----------



## EvilDragon (Mar 2, 2018)

Yeah running Kontakt under WINE would make it a pretty uneven comparison...


----------



## chrisboy (Mar 2, 2018)

Hi, HISE dev here.

there seems to be a few misconceptions which I'd like to address. First of all, the Javascript engine in HISE has nothing to do with any other "official" implementation like V8, it just happens to share the same syntax, so any argument of HISE having some kind of generic interpreter vs. KSP being a specialised language for its task are kind of pointless.

The scripting engine of HISE is also 100% tailored for the task of MIDI event processing (with the convenient bonus that you can use a few higher level concepts of Javascript for GUI design). Since it is pretty hard to make any predictions about performance for a callback that happens occasionally on incoming midi messages, I opened the scripting language for calculating DSP effects for the sole reason of being able to tune the throughput of the language. However it is definitely not fast enough to calculate eg. filters on an audio signal (a simple low pass needs about 5% CPU, which is about 10-20x slower than C++).

You can do about 1M Javascript ops per second (basic math, calling API functions are of course a bit slower) which should be more enough than you need for processing MIDI or a timer with a low frequency. Sure, I could try to improve the speed even further - I did some experiments with embedding a JIT engine that can be seen here: http://forum.hise.audio/topic/210/what-s-all-this-jit-stuff, but I realised that JIT isn't allowed on iOS thanks to Apple's control-freakish nature  Since the idea of HISE is having one platform that works equally on every OS so I didn't pursue this any longer.

Now to the recurring argument with the limited variable slots, you can easily bypass this by using namespaces (a concept borrowed from C++) or simply use the default variable type, which is a bit slower. But bear in mind that in HISE you can do specialised scripts that perform one task only so it's unlikely that you need more than 32 (fast) variable slots.

Also, if you ever run into a script so complex that you start getting performance issues, you can simply rewrite the code in C++ and embed it into your plugin (I mirrored the scripting API on the C++ side and these languages are more similar than you'd think).

Now the real question about performance is how it handles hundreds of streamed voices, which is the bottleneck of all sampler platforms. I did a lot of profiling & tweaking on the lowest level using SSE optimisations where possible and tried to introduce some higher level concepts which brings down the CPU consumption (eg. using multiple mic positions saves recalculation of modulators). Also the streaming engine is tightly coupled to the lossless HLAC codec which offers about 50% size reduction with nearly no CPU overhead.


----------



## EvilDragon (Mar 2, 2018)

Nice to see you here, Chris. And thanks for addressing concerns!



chrisboy said:


> (eg. using multiple mic positions saves recalculation of modulators)



Well that sounds quite nifty indeed.


Regarding HLAC, IMHO its main letdown is not supporting 24-bit samples, which Kontakt's NCW does. Otherwise, all good  Oh yeah... are all common sample rates supported with it? Mono, stereo, multichannel?


----------



## chrisboy (Mar 2, 2018)

All sample rates, Mono and Stereo yes, but multichannel isn't supported natively. However HISE simply uses multiple files for multichannels which brings the nice benefit that you can purge individual channels (which is impossible if you have them interleaved in one file). If you have a sample set that uses more mic positions, it will export each mic position as dedicated file, so you don't need to bother about this actually.

16bit vs 24bit, here we go  I have deliberately chosen to not support 24bit on HLAC, because there is no benefit in 99% of all use cases (the only use case that comes into mind is that if you heavily compress percussion samples that bring up the noise floor). During recording & editing 24bit is a must, but in the end product, it's just a waste of resources (this is not true for recordings of music, a classical piece might contain the dynamics that justify a range that 24bit offers).
If you spend some time writing an algorithm that tries to squeeze every possible bit out of the signal, it is really hard justifying that about a third of the data just contains unneeded noise that will most likely never be heard. It also brings down the compression ratio. The same signal that can be reduced by 50% in 16bit can only be reduced by 66% (and this is only the ratio, don't forget the file itself is bigger too).

Limiting HLAC to 16bit has also the benefit that I can use 16bit for the preload buffers, which reduces the memory usage too.

I've written a more in-depth technical perspective of this subject here: http://forum.hise.audio/topic/343/monolith-hlac-should-have-normalization-built-in.


----------



## EvilDragon (Mar 2, 2018)

Gotcha. Yes, percussion and transient-rich material (acoustic guitar, but also drum loops, or any kind of looped content that's not smashed to clipping smithereens!) was where I was going with my 24-bit comment 


For the record, with Kontakt's NCW it is also apparent that 24-bit samples don't compress as well as 16-bit (so likely there might be some very similar math between NCW and HLAC - just a conjencture!). But at least they compress!


----------



## chrisboy (Mar 2, 2018)

Actually if you start comparing all lossless audio codecs, things start to look pretty similar. There's always two stages: divide the signal into something that can be compressed pretty good (A) and the rest (B) which can be hopefully saved in a lower bit rate because that's how you can get the file size down. FLAC (and every other general purpose lossless codec) use linear predictive encoding + RICE encoding for the residual, which brings the best ratio, but is really inefficient and can't be really used for streaming multiple voices.

HLAC uses a simple trick: It stores every 4th sample (A) and the derivation from the line for sample 1, 2, 3 (B). Both signals are bit compressed. The decompression is almost as trivial as deinterleaving stereo channels and can be perfectly SSE optimized because of the stepsize 4.

I am guessing that NCW does something similar because there is no way you get LPC + Rice with the performance of NCW / HLAC, but I don't have any real insights - obviously


----------



## EvilDragon (Mar 2, 2018)

chrisboy said:


> FLAC (and every other general purpose lossless codec) use linear predictive encoding + RICE encoding for the residual, which brings the best ratio, but is really inefficient and can't be really used for streaming multiple voices.



Seems to work pretty well in UVI Falcon... they have some optimizations in place for FLAC streaming... Still, not at level of Kontakt of course.


----------



## chrisboy (Mar 2, 2018)

Yeah they probably exchanged RICE for something more vectorizable


----------



## EvilDragon (Mar 2, 2018)

No their streaming works on regular FLAC files, no special encoding tricks (AFAIK)... Might be some decoding tricks instead (well that's the important part for streaming after all).


----------



## chrisboy (Mar 3, 2018)

Really? I am pretty sure I‘ve read somewhere they made customizations to the actual codec (but I might be wrong).

The unaltered FLAC is 10x - 15x slower than uncompressed PCM reading even if you read the whole file at once so there is little chance that a streaming engine can be more performant by applying tricks other than improving the algorithm itself.

Edit: Reread your post, if they really support original FLACS that are created elsewhere then it‘s of course how you said.


----------



## EvilDragon (Mar 3, 2018)

They really support original FLAC. I just drop the file I encoded myself and it works.


----------



## otristan (Mar 6, 2018)

I confirm for the FLAC streaming 
24bits is honestly useless as you usually normalize your samples when used in a sampler context
You should of course record in 24bits but for actual data storage it is mostly useless especially as you can keep the original volume layout using volume settings and not in sample itself.


----------



## EvilDragon (Mar 6, 2018)

otristan said:


> 24bits is honestly useless as you usually normalize your samples when used in a sampler context



Not always and not for all type of content, though...


----------



## otristan (Mar 6, 2018)

EvilDragon said:


> Not always and not for all type of content, though...


Honestly this is 99% wrong as a full scale 16bits has a 96dB range which is way beyond human capability.
You need to normalize your sample of course and maybe dither.


----------



## EvilDragon (Mar 6, 2018)

This is not about dynamic range but transient fidelity, which will be better on 24-bit regardless of dynamic range.


----------



## otristan (Mar 6, 2018)

EvilDragon said:


> This is not about dynamic range but transient fidelity, which will be better on 24-bit regardless of dynamic range.


At record time to leave headroom to avoid clipping I can understand why, I doubt this is really useful at playback especially given no DA converter SNR match 24bits. Not sure high end even match 96 dB


----------



## Mike Greene (Mar 6, 2018)

otristan said:


> I confirm for the FLAC streaming
> 24bits is honestly useless as you usually normalize your samples when used in a sampler context
> You should of course record in 24bits but for actual data storage it is mostly useless especially as you can keep the original volume layout using volume settings and not in sample itself.


That might be true from an academic or engineering standpoint, but from a marketing standpoint (after all, Realitone is a business, not an AES chapter), good luck trying to educate buyers that 16 bits is just as good as 24 bits. I still can't even get customers to understand the difference Kontakt and Kontakt Player. 

When it comes to selling product, it doesn't matter what the real science is, and it doesn't even matter if _most_ people believe 16 bits is fine. As long as there's still that 10% who think they need 24 bits, then that's 10% of potential sales I left on the table.


----------



## chrisboy (Mar 6, 2018)

Well you can tell customers they get 33% more streaming performance without sacrificing sound quality.

If I could choose between 24bit versions and (correctly normalized) 16bit versions of a library I would always pick the 16bit version because it allows me to load more samples before my system chokes.


----------



## otristan (Mar 6, 2018)

I tend to not compromise my technical belief for marketing reason and try to educate users whenever I can.
Sure this is not the easiest path but I have hope for the future.
I've sent quite some time this video to some users in similar thread

UVI soundbank are recorded at 24bits / 88.2kHz but final assets are delivered as 16bits / 44.1kHz for this exact reason. Playback engine can still be oversampled internally if necessary for distortion/filtering.
Sorry for the HS.


----------



## d.healey (Mar 6, 2018)

otristan said:


> UVI soundbank are recorded at 24bits / 88.2kHz but final assets are delivered as 16bits / 44.1kHz for this exact reason.


That video looks interesting, thanks! So 44.1kHz not 48?


----------



## EvilDragon (Mar 6, 2018)

Yeah, because at 44.1k you still shave off some megabytes, ehehe. Nevermind that most pros are working at 48k and that the library in that form would get resampled on the fly anyways...


----------



## otristan (Mar 6, 2018)

44.1khz vs 48khz is mostly a radio music vs cinema industry rather than pro vs not pro.
It all depends which crowd your soundbank are aimed at.
It's best to select the SR that match your industry to avoid any realtime resampling.
Our Trailer FX soundbank is in 48khz for this matter.

End of HS and back to Hise which looks very good especially for an open source project. Congrats !


----------



## mcalis (Mar 6, 2018)

@chrisboy I don't have much to add to this discussion, but I wanted to quickly hop in to thank you for making HISE. I've only worked with it a little bit, but I'm frankly amazed that you've made this software on your own. I've already constructed a few personal libs (really dumb percussive stuff, no scripting) with it and I plan to soon show it to some other audio folks I know 

And thanks again Mr. Healey for pointing me toward HISE in the first place!

Carry on


----------



## EvilDragon (Mar 6, 2018)

otristan said:


> 44.1khz vs 48khz is mostly a radio music vs cinema industry rather than pro vs not pro.



True to an extent. 44.1k is CD audio format, but 48k is DVD audio format (and movies, yes).


----------



## P.N. (Mar 7, 2018)

Also, downsampling from 88.2 kHz to 44.1 kHz minimizes the risks of aliasing, since you're dividing it in half.
From 88.2 kHz to 48 kHz the conversion could suffer. Is it audible though? Probably not.


----------



## Mike Greene (Mar 7, 2018)

chrisboy said:


> Well you can tell customers they get 33% more streaming performance without sacrificing sound quality.


Sure, except that's a conversation that would never happen. Customers aren't going to email and ask, _"Golly, I see that you guys' samples are 16 bit. Why is that?"_ People (outside of forums) don't like to be confrontational, so they hesitate to ask biting questions like that.

Instead, a potential customer might be trying to decide between my new (hypothetical) string library and Company X's string library. He asks his friend for his opinion. The friend will likely say, _"Well, Company X's library is 24 bit, but Realitone's is only 16 bit."_ From there, they _might_ discuss whether 16/24 bits actually matters, but if they do, there's a good chance they're conclusion will be that ... it does! If Mario in this thread isn't completely convinced there's no loss at 16 bits, then we can be sure the masses won't be either. In fact, I know of one company who used to give customers the option of 16 bit and 24 bit versions, and now they only give the 24 bit option because no one wanted the 16 bit versions.

Don't get me wrong, if you don't want to offer compression for 24 bits, then don't. It's not a deal breaker per se, but I can tell you that I'm alone in that if I do decide to do a library using HISE, I would forego compressing the samples and just leave them uncompressed, so they could stay 24 bit. It's Sample Library Marketing 101.


----------



## gsilbers (Mar 7, 2018)

before we go way too into bit depth talk... 

whats the appeal or interest of hise?


----------



## Mike Greene (Mar 7, 2018)

gsilbers said:


> before we go way too into bit depth talk...
> whats the appeal or interest of hise?


For me, there are three things that interest me:
1. Better copy protection possibilities, since I assume I can tweak the C++ code to throw in my own little twists. Kontakt is a big target, so hackers will spend some time trying to crack it. But l'il ole me with my Realitone libraries? Highly unlikely anyone would bother, so I wouldn't even need to get fancy in order to protect my libraries.

On that front, NI has been completely deaf to our (developers') suggestions for ways to improve it. We've made what I believe are very reasonable and simple requests to make it so we could insert own CP schemes, but NI doesn't even respond when the topic is brought up.

2. With Realivox Blue, because of the wordbuilder, Kontakt's lack of ability to let users input from their QWERTY keyboards is a major drawback. Mind you, I don't know whether HISE _does_ allow QWERTY input, and perhaps Kontakt 6 (whenever they decide to release it) will allow it, but for now, this has me interested in alternative platforms.

3. I have an instrument idea that requires real-time audio input, which Kontakt can't do. Since HISE is basically anything you want to make it, I assume this will be possible.

I'm not the only developer who has toyed with the idea of creating my own sampler, and every once in a while, some of us will even discuss teaming up to do that. There's a LOT of work and risk in doing that, though, so the fact that Christof has already done most of the work and we can tweak from what he's already done, is very appealing.

With all that said, I would likely still continue with Kontakt for most of our stuff. It's a great platform with some serious advantages, plus I don't want to rewrite everything we've already done, so no way would I abandon it.


----------



## EvilDragon (Mar 7, 2018)

Mike Greene said:


> Kontakt's lack of ability to let users input from their QWERTY keyboards is a major drawback.



K5 got the ui_text_input() widget, so entering text is definitely possible. However, you cannot parse what's been inputted in order to check validity of input (i.e. if the user typed "rah" or "raa" etc.) - it's mainly there for stuff like naming keys and/or NKA files. Still, it's there.


----------



## d.healey (Mar 8, 2018)

gsilbers said:


> whats the appeal or interest of hise?


For me:

It's free as in speech (and beer if you're releasing a GPL licensed library).
Far superior scripting language(s) to Kontakt, or any other sampler.
A proper script editor.
WYSIWYG GUI Designer.
Modular design makes it very easy to maintain and re-use parts of one project in another
Built in vector graphics tools allow for scalable UIs to be designed within HISE without needing to use external images (or you can use external images, including vectors/svg)
UI is scalable up to 200%
XML Based file format makes it easy to edit presets and sample maps in a text editor.
Hot-swappable sample maps
Built in support for mult-mic samples
Built in support for crossfading between groups
Can export directly to a VSTi - no need for a separate player app
Sample editing tools to auto trim samples
Sophisticated sample import tool (is Kontakt still limited to dragging in 127 samples at a time?)
Floating point numbers  (I know Kontakt has these now, after 15 years or more)

I could keep adding to the list but basically unless you are creating an instrument that requires some feature that HISE doesn't support (time stretching, beat slicing), would be more efficient in Kontakt, or doesn't fit the HISE paradigm, then HISE is probably a better choice than Kontakt or any other sampler. If you are just starting out with developing sample libraries then definitely learn HISE.


----------



## EvilDragon (Mar 8, 2018)

d.healey said:


> (I know Kontakt has these now, after 15 years or more)



Around 11 years. Kontakt 1 didn't have scripting at all, hell it didn't even have DFD initially (released Aug 2002). KSP was introduced in K2 (July 2005). And real numbers and math functions were introduced in K5.6 in Sep 2016.


----------



## d.healey (Mar 8, 2018)

EvilDragon said:


> Around 11 years. Kontakt 1 didn't have scripting at all, hell it didn't even have DFD initially (released Aug 2002). KSP was introduced in K2 (July 2005). And real numbers and math functions were introduced in K5.6 in Sep 2016.


Yeah I started with Kontakt 4 so wasn't sure on the history, knew it had been around for a while before that.


----------



## P.N. (Mar 8, 2018)

Is there any free HISE example instrument available so that users can try it out and see how it works?


----------



## d.healey (Mar 8, 2018)

P.N. said:


> Is there any free HISE example instrument available so that users can try it out and see how it works?


http://hise.audio/manual/Tutorial1.php


----------



## chrisboy (Mar 9, 2018)

There are also a few example projects here:

https://github.com/christophhart/hise_tutorial

However you need to build them yourself which is not the most convenient thing on earth if you don‘t have any experience in this field. But it‘s on my roadmap to offer precompiled versions of a basic plugin suite that people can download and check.


----------



## P.N. (Mar 9, 2018)

chrisboy said:


> There are also a few example projects here:
> 
> https://github.com/christophhart/hise_tutorial
> 
> However you need to build them yourself which is not the most convenient thing on earth if you don‘t have any experience in this field. But it‘s on my roadmap to offer precompiled versions of a basic plugin suite that people can download and check.



Yes... i'm not a programmer, i only have a little over a year in programming experience (all KSP), so i'd just like to see the plugin or stand-alone in action in a practical example.

Studying further requires a lot of free time, so i'd really just like to try it as a user and see how it works. 

When you have something available, i'll check it out. In the meantime, i'll do some light reading on the available documentation. Thank you.



d.healey said:


> http://hise.audio/manual/Tutorial1.php



Thanks, David. I had an issue downloading from here. File corruption. And it's also not compiled...

Best regards,

Paul


----------



## d.healey (Mar 9, 2018)

P.N. said:


> Yes... i'm not a programmer, i only have a little over a year in programming experience (all KSP), so i'd just like to see the plugin or stand-alone in action in a practical example.
> 
> Studying further requires a lot of free time, so i'd really just like to try it as a user and see how it works.


HISE is a tool to build sample libraries so to see it in action you need to build a project. There is no standard end user interface for an instrument built with HISE, the developer can make it look like or do whatever they want (within reason).


----------



## P.N. (Mar 9, 2018)

I see. So there's no standard shell and it will work as a regular VST plugin. But that also means no standard set of rules or options - which i'm not so sure it's a good thing. Thank you.


----------



## d.healey (Mar 9, 2018)

P.N. said:


> I see. So there's no standard shell and it will work as a regular VST plugin. But that also means no standard set of rules or options - which i'm not so sure it's a good thing. Thank you.


Yeah I imagine each developer will build their own "engine" so that their libraries have a standard look. But all instruments tend to have the same features just they'll look different. Not really much different to how things are done with Kontakt other than you don't have the standard Kontakt header.


----------



## chrisboy (Mar 9, 2018)

P.N. said:


> I see. So there's no standard shell and it will work as a regular VST plugin. But that also means no standard set of rules or options - which i'm not so sure it's a good thing. Thank you.



Actually I had some kind of common top bar for all HISE instruments but literally everyone asked me how to remove it so I didn‘t bother about it.


----------



## P.N. (Mar 10, 2018)

d.healey said:


> Yeah I imagine each developer will build their own "engine" so that their libraries have a standard look. But all instruments tend to have the same features just they'll look different. Not really much different to how things are done with Kontakt other than you don't have the standard Kontakt header.



I was refering to some common things that we normally take for granted.
Audio and Midi configuration, and other fundamentals . RAM management, sending MIDI to outside... stuff like that.

The rest, sure. It's a developer's responsability. It's always important to keep your projects organized if you're targeting coherency in both visuals and features.



chrisboy said:


> Actually I had some kind of common top bar for all HISE instruments but literally everyone asked me how to remove it so I didn‘t bother about it.



After reading more, i think now i understand the philosophy of HISE. 

I'll gladly try to learn HISE eventually. I'm just a little scared by the apparent complexity (which is probably not too hard for folks with computer engineering backgrounds).

If someone were to make a... KSP to HISE converter or something. I know, just a crazy thought.


----------



## d.healey (Mar 10, 2018)

P.N. said:


> If someone were to make a... KSP to HISE converter or something. I know, just a crazy thought.


Pretty much impossible to do a like for like conversion. Sure you could convert one script from KSP to HISE Script but the whole paradigm of HISE is totally different to Kontakt. For example in Kontakt you tend to have one massive script per instrument (sometimes you might have more than 1 but you can only have 5 maximum), in HISE you will have lots of little scripts for doing individual tasks.


----------



## Ivan M. (Nov 30, 2020)

Hey, what's the situation today? How does HISE performance kompare to Kontakt?


----------



## d.healey (Nov 30, 2020)

Ivan M. said:


> Hey, what's the situation today? How does HISE performance kompare to Kontakt?


Unlike Kontakt, HISE is a dedicated tool for creating plugins, it is not the end product. So to compare HISE itself against Kontakt is meaningless. Comparing individual sample libraries created in HISE or created in Kontakt is a lilttle better but still not very useful (unless you compare identical libraries in both).

The level of "performance" between plugins will vary grealy between different developers as well as between plugins. A simple sample library with a single sampler and minimal scripting will probably perform better than a more bloated library with lots of samplers and badly written scripts.


----------

