What's new

For Those of Us Considering Jumping from Kontakt to HISE

One thing I'm not sure about is what 'git' is? I know what it refers to here in the UK, but not in the coding sense... If anyone could chip in with what the 'Git' in GitHub means that would be cool.
accessible to the laymen.
Git is a version control system created by (and perhaps named after Linus Torvalds ;) the guy who wrote/writes the Linux Kernel).

Version control is just what it sounds like, it allows you to keep track and control different versions of your project. It's mainly useful for text based files as it can track changes in their content easily, but I believe it also works with images and audio files.

A repository in the general sense is a place where things are stored, like a book repository for instance. In a version control system a repository is a folder that is used to store and track the files that belong to a project.

Git works locally on your machine, but it has the ability to interface over a network with repositories on another machine. These are called remote repositories.

Git is designed as a decentralized system, anyone can set up a remote repository on their own server if they want to.

Github is a website (one of many) that allows you to create remote repositories without having to setup and manage your own server. It's owned by Micro$haft and is entirely separate from git.

Github is a convenient way to collaborate with other people. All gratis repositories on github are public, anyone can access them, if you want a private repository then you have to pay.

You don't need to use git or github to use HISE, but you do need to go to the HISE github repository to access the source code for HISE.
 
Thanks for the info!

Can HISE be presented in a similar fashion to Kontakt in being a standalone individual sampler as opposed to just one library? So say someone downloads the 'Waverunner Audio App/Sampler' (built with HISE) and then can load libraries from it, or browse to them/have the ones they own listed there?
 
Thanks for the info!

Can HISE be presented in a similar fashion to Kontakt in being a standalone individual sampler as opposed to just one library? So say someone downloads the 'Waverunner Audio App/Sampler' (built with HISE) and then can load libraries from it, or browse to them/have the ones they own listed there?
Slow down grasshopper.....

Yes it's possible using HISE expansions, but they require a bit of work to implement, there's no expansion installer built into HISE either so you'll need to create a method for your users to install them. I haven't released anything using expansions yet.

It's also possible if you build your frontend with C++, then you can do almost anything.

If each of your instruments aren't too different from one another then you can probably just use the HISE preset system to do this as it has a built in tool to add additional presets.
 
Thought I'd chip in with my getting started day today for those considering with little to no coding background as there are a few terms and things to get your head around before even opening HISE (Xcode, IPP, compiling, JUCE, GitHub, repository) and pretty much all of them were unfamiliar to me.

To access the latest version of HISE you need to download the source code from GitHub and then compile the code to create an executable application version of HISE (correct me if I'm wrong). This isn't too difficult to do, but a little daunting if you've never done this before. On mac OS you need XCode and recommended is Intel Performance Primitives (IPP). I think a reasonable analogy would be writing an essay in Microsoft Word being writing the code, and our 'executable' being a physical book version, with printing being the compiling and the printer being XCode... maybe?

What is compiling? @d.healey & @chrisboy please feel free to chip in with a better explanation but here is an explanation from Reddit that seems ideal:

"As you may know, everything in a computer is represented by a series of 1's and 0's (which themselves represent high and low voltages on transistors, but that's a topic for another time). When the computer runs a program, the program itself is made of a bunch of 1's and 0's.

However, since we still need humans to write our programs, putting everything in 1's and 0's (called machine language) would be very difficult. So we made higher level languages like Java and C# to write code in. These languages look a lot more like English, so they're a lot easier to write and maintain.

When you compile code, the compilor (usually another program) takes the program the human wrote, and converts it into the program the computer can understand (i.e. converts from Java to machine language). The very short version could be, yes, compile means to make the code executable."


So at present the latest and most up-to-date version of HISE is presented in source code and you need to follow the steps helpfully presented by David Healey here to compile before you even open HISE.

So you get SOURCE CODE > COMPILE (via steps linked above) = then you have HISE to open

Downloading XCode: Requires an Apple developer account which is easy to set up - https://developer.apple.com/xcode/

Downloading IPP: Requires an Intel account which is also easy to do. One thing I'm not sure of is what elements of this need installing. Will do a it more research once I've got Mojave installed tomorrow.

How they all communicate I'm not too sure from a complete layman's perspective - my understanding is XCode is a development tool, or an environment for multiple development tools, in which to create apps for the Mac OS and OSX platforms, and when compiling HISE this is used to do just that; it's part of taking the HISE source code and creating an 'app' form on Mac OS and OSX.

GitHub: My understanding of GitHub is it's a website where people can share code and projects easily, including versions and stages of development of the projects making it especially easy for people to collaborate and/or build on other projects especially open source ones. One thing I'm not sure about is what 'git' is? I know what it refers to here in the UK, but not in the coding sense... If anyone could chip in with what the 'Git' in GitHub means that would be cool.

Repository: I think is the term given to a location where code is stored, maybe just like a folder, but specifically for containing core code? Anyone able to clarify that more for us laymen?

- - - - -​

The following is very specific to me, but thought I'd share in case it's helpful to someone else and only really applies to anyone running an old mac; I have a 2012 Mac Pro running High Sierra. This limits me to older versions of XCode and IPP.

The latest version of XCode is only compatible with a minimum of Mac OS 10.15.2 onwards, so it's a no go for High Sierra. It seems XCode 10.2 can be used in High Sierra with some editing of XCode files which makes things even more fiddly. It seems relatively simple to install older versions of IPP, but I figured going round-about-ways from the start isn't ideal for something potentially so crucial so after looking at ways to install older versions of XCode and which ones are okay for High Sierra would recommend unless you really, really have to, probably a good idea to err on the side of upgrading whatever you need to to get Mojave+ (8 years has been a mighty fine run for this ol' machine), though maybe @chrisboy could clear any of that up i.e. any issues using older version of IPP or XCode to compile?

That leaves updating Mac OS to Mojave which can be done on Mac Pro 2012s with the right graphics card, see here. I've ordered the Sapphire Pulse Radeon RX 580 to install which means Mojave is, or at least was until recently, officially supported (I think however Apple don't officially support Mac 2012s running Catalina).

Of course 8 years is a long time to have a machine and there are other things cropping up requiring later versions of Mac OS so it's probably about time to upgrade anyway, but seems the graphics card upgrade might get another couple years out of it. And going back 15 years a computer older than 6 months was basically ancient so it's good times.

Coming from a place that isn't familiar with GitHub, repositories, XCode etc, thought I'd write a little something about them with the hope those who are familiar with them might help clarify any definitions and explanations to make it all more accessible to the laymen.
Ross, your experience is very similar to mine. I bought a used MacBook Pro specifically so I could load on Catalina, mainly because XCode insisted on it. (As you saw.) I just couldn't get it working, though, so at the advice of one person the HISE forum (but against the advice of another person), I loaded Mojave instead. Many hours later, I eventually got a version working. It's still not perfect, since it won't compile final instruments, but at least I can make basic instruments.

I eventually gave up, though, and hired Lindon to build my instrument for me. That's working out really well ... for me, at least. The stuff I gave him is such a mess that he's probably regretting it, though. :grin:

HISE is a great platform, but there is one massive roadblock to it being adopted by more than the current handful of tech guys: It is simply too complicated to get started with. 90% of the sample library developers (I've met most of them) are like Ross and me, and will get frustrated and give up. (As I did.) Even the part-time guy who I hire here at my studio to do more tech oriented coding (we're starting some basic JUCE stuff, for instance) couldn't get HISE working properly on his system.

So, assuming the goal is for HISE to be used by more developers (I don't know whether that's Christof's goal or not, so it's presumptuous of me to assume that) then here is what I recommend:

1. Make the website so at the top, easy to see, is a simple download of the app itself. No IPP, no XCode, no ProJucer, no GitHub ... none of the stuff that I guarantee is scaring away 95% of the people who might want to try HISE. Just a simple app download so people can make an instrument ... now. (I think that's called a "single binary?" Again, this is lingo that hardly any of us real-word guys understand.)

Note that this already exists on the site, but it's not obvious that it's there. (I wasn't aware of it until David told me.) That existing one is also over a year old, so it's missing many features and bug fixes. Update the damn thing. And make it more obvious! ;)

2. This single binary version won't compile into standalone instruments, of course, but if/when someone is ever ready for that, then they can do that complicated installation process, which should be further down the page on the website. After the simple "Here's the app so you can get started now" version.

Speaking of which, that complete installation process would be much simpler by that point, because familiarity with the app itself helps make more sense out some of the installation steps. If I tried again now, for instance, I think I might be more successful.

3. I would update the site to make it more newbie-friendly. A link to the manual, right under the "easy download," for instance. (I didn't realize the manual existed, until someone here told me.) I would also add a page linking David's HISE videos, and sort them so the most newbieish ones are at the top.

There are also some correction that should be made. As Nick pointed out earlier in the thread, it says HISE is only compatible up to Mac Sierra. That may seem trivial, but I was worried about Catalina compatibility, which as we all know, has been a snag for many developers, so it was an uh-oh moment for me.

Also, there are two GitHub versions. Clicking green “Clone or Download” button here:
https://github.com/christophhart/HISE/
...appears to be newer than the zip file from this other page:
https://github.com/christophhart/HISE/releases/

The Mac Installation instructions are incomplete, and without David's video, no one could install based on them. Even with David's video, I needed to make some installation notes. These were intended only for myself, so they are notes, not "instructions," but if it helps, I'll post them here. I've hit my word limit, so I'll paste into the next post.
 
Last edited:
My installation notes to myself:

Install XCode (get it at the App Store) - It seems XCode 10.3 is necessary, not XCode 11.

Install IPP:
https://software.intel.com/content/www/us/en/develop/tools/integrated-performance-primitives.html

Download HISE zip file by clicking green “Clone or Download” button here:
https://github.com/christophhart/HISE/
Note that that appears to be newer than the zip file from this other page:
https://github.com/christophhart/HISE/releases/

Download and place:
ASIO SDK: ASIO SDK
VST SDK: (broken link removed)
Place the ASIO and VST folders into:
HISE . Tools > SDK

Run Projucer
HISE > Tools > Projucer
(Note - If in Catalina, then must use latest Projucer from the JUCE website)
Click “Open existing project” button
Select and run each of these:
HISE > Projects > Plugins > HISE Jucer
HISE > Projects > Plugins > HISE Standalone Jucer

On Left sidebar, check Modules:
If any paths are red, they need to be corrected to: ../../
On Left sidebar, check Exporters > XCode (MacOSX):
Set “VST (Legacy) SDK Folder” path to “../../tools/SDK/VST3 SDK (Can use Browse button)

Exporters > Release (also Debug and Jenkins?)
OSX Architecture: Select 64 bit

Now Save - File dropdown at top.
At bottom is “Save Project and open in IDE…”

In XCode, go to Product menu at top. Select:
Build for > Running (1st attempt) - Debug - I think this a mistake, and we really need to do:
Build for > Profiling (2nd attempt) - Release

Bell symbol on left sidebar displays warnings. There will be lots of warnings, but hopefully no errors.

Now open in HISE > Projects > Standalone (or Plugin) > Builds > MacOS> Build > Release or Debug
 
Also, there are two GitHub versions. Clicking green “Clone or Download” button here:
There are about 100 versions on Github, Git is a versioning system after all.

1591983209170.png

Generally you want to use the most recently updated branch from Christoph's repository (repo). But at the moment that version doesn't work - it's in active development so these develop branches can't always be guarenteed to work.

So you have a few choices
* Use the latest Release, which is quite old now but will definitely work - this is why I recommend it in my video.
* Try out different commits on different branches to find the most recent that works (very time consuming)
* Ask/search the HISE forum to find out what everyone else is using - generally do a search because it's already been asked.
* Use (broken link removed) which has a bunch of extra features not yet in Christoph's repo. My fork is based on the scriptnode branch from a commit around January.
 
That's really helpful, David.

Although ... it illustrates again how none of us regular Kontakt/UVI developers are going to be successful at this. (Forks, Branches, Releases ... this is all new to me.) Now that you explain it, it makes sense, but it seems every step of the way needs an additional explanation like this. :grin:
 
For those who are interested in licensing / product keys, you might want to check out LicenseSpring.


I use this for OmniTag and it has been great. They have a free tier too.
 
I totally understand how setting up the toolchain required to use HISE for development might seem daunting to developers who come from an environment that offers everything in a box like KONTAKT.

However I deliberately chose to not flatten the learning curve in the beginning. The reason why this process is not 100% smooth for non-coders is that you will have to use the exact same tools to build your actual projects with HISE so the troubles would just be delayed to the point where you want to export your project as VST plugin and if you don't manage to suceed there for various reasons, the level of frustration will be much higher because you already spent multiple hours with your project already. But once you get all this out of the way, using the latest source code of HISE (or whatever state in history you might prefer, currently it's a bit messy because I got stuck in a major feature rewrite) is the fastest and most effective way to use a SDK like HISE in my opinion.

Now for your specific problem with macOS: You don't need the latest Xcode version (AFAIK I am still using XCode 8.3.2 on macOS High Sierra myself), so basically just pick whatever versions you need for IPP and XCode to match your macOS system and then go from there. There might be hiccups along the process, but the same will be true if you use the latest of everything, so prepare for a bit of fuddling (curiously it's much easier and more constistent to get HISE working on a windows system).

The only thing you need to know about GitHub and repositories is that these two things just offer a way to make incremental changes in your project code and go back in time if you find yourself breaking things with a change, which is an invaluable tool as soon as the project size exceed a certain threshhold or if there are more than one developer working on a project. So GitHub is a webservice for that and a repository is the file-system that tracks all changes and allows jumping on the time line and creating parallel branches for new features etc. The project structure of HISE was designed with best compatibility to that workflow in mind but using Git is nothing special to HISE but more like the standard way of project management for software developers these days.
 
EDIT: For some reason I just read the first long post from Ross but overlooked that the conversation went on so this answer might seem a bit out of place. I'll let it here anyways :)
 
I totally understand how setting up the toolchain required to use HISE for development might seem daunting to developers who come from an environment that offers everything in a box like KONTAKT.

However I deliberately chose to not flatten the learning curve in the beginning. The reason why this process is not 100% smooth for non-coders is that you will have to use the exact same tools to build your actual projects with HISE so the troubles would just be delayed to the point where you want to export your project as VST plugin and if you don't manage to suceed there for various reasons, the level of frustration will be much higher because you already spent multiple hours with your project already. But once you get all this out of the way, using the latest source code of HISE (or whatever state in history you might prefer, currently it's a bit messy because I got stuck in a major feature rewrite) is the fastest and most effective way to use a SDK like HISE in my opinion.

Now for your specific problem with macOS: You don't need the latest Xcode version (AFAIK I am still using XCode 8.3.2 on macOS High Sierra myself), so basically just pick whatever versions you need for IPP and XCode to match your macOS system and then go from there. There might be hiccups along the process, but the same will be true if you use the latest of everything, so prepare for a bit of fuddling (curiously it's much easier and more constistent to get HISE working on a windows system).

The only thing you need to know about GitHub and repositories is that these two things just offer a way to make incremental changes in your project code and go back in time if you find yourself breaking things with a change, which is an invaluable tool as soon as the project size exceed a certain threshhold or if there are more than one developer working on a project. So GitHub is a webservice for that and a repository is the file-system that tracks all changes and allows jumping on the time line and creating parallel branches for new features etc. The project structure of HISE was designed with best compatibility to that workflow in mind but using Git is nothing special to HISE but more like the standard way of project management for software developers these days.

Thanks for your answer @chrisboy , all makes sense and good to know re the XCode versions, though I suppose it's a good excuse to upgrade the graphics card anyway! And understand that new releases can introduce new problems as much as using older versions, indeed I'll usually find a system that works and stick with it until there's something incredibly pressing requiring an upgrade.

I definitely echo @Mike Greene 's suggestions IF what you're looking to do is make this a platform for developers like us to jump on board with as an alternative to Kontakt. At present it feels like a different level (if at one end is source code and the other is a ready-to-go platform like Kontakt) and that jump is a huge one for smaller developers who I'm sure like me would love to embrace an alternative, especially if there's the potential for presenting their own player.

What makes it tricky beyond the learning curve has all been pointed out well by Mike; not having a specific 'use this version' with an explicit download link. It doesn't mean there's no understanding as to why that's the case, just that that being the case makes it pretty in-accessible. It's almost as if there needs to be a middle man more adept at coding and willing to take on the version-testing on various OSs to hand something to those developing for the likes of Kontakt. And the website suggestions are really good too; as it does seem geared up to appeal to people looking to make libraries, just a bit of house-keeping in terms of the dates, links, compatibility, layout etc would help make it more so but again, that comes down to where you want to take this of course.

Something I've learned is how necessary it is to have literature explaining things I take for granted. For example customers asking what Kontakt is and how to use it. Certainly starting off I assumed everyone would at least know that but upon reflection, well why would they. Therefore I would say don't be afraid to explain what might seem really simple things that are incredibly familiar to you, which is evident in terms of us getting our heads around some of things mentioned above (and I'm glad to see I'm not the only one, phew.)

This all comes from a place of wishing to see it succeed as it all looks really excellent and clearly there's huge potential. I'm excited to delve into it more tomorrow and happy to share my experience here and the HISE forums. Although installing the new Graphics Card might mean obviously I should probably test out it's working and the best way to do that is probably with games and remastered versions of Command and Conquer have just been released so... might get back to you after the weekend.

I'd also love to learn more about the HISE extensions @d.healey , but can't see anything in the documentation, any links to a bit more info on heading down a stand-alone style player route?
 
However I deliberately chose to not flatten the learning curve in the beginning. The reason why this process is not 100% smooth for non-coders is that you will have to use the exact same tools to build your actual projects with HISE so the troubles would just be delayed to the point where you want to export your project as VST plugin and if you don't manage to suceed there for various reasons, the level of frustration will be much higher because you already spent multiple hours with your project already.
That assumes most people will continue along with HISE long enough to get to the point where they need to export as a VST. HISE looks great, but ... that's a pretty bold assumption. ;)

Kontakt has already set the bar very, very high. They're on version 6 now, and they've added tons of features that we now take for granted. So no developer is going to blindly jump ship and say, "Well, if I have to spend a couple days (that's how long it took me) figuring out how to get HISE running, then it's totally worth it in the end, because for sure I'm going to use HISE instead of Kontakt ... before I've even tried it."

Instead, any developer is going to want to try HISE first, before making that kind of commitment.
 
> So no developer is going to blindly jump ship

I expect nobody ever to blindly jump ship. The only reason why developers have switched to HISE in the past is because there is something it can do that KONTAKT can't and even if it is just the simple fact that you have your own plugin / app at the end and are not bound into an ecosystem which limits your customer base to owners of full KONTAKT. So the idea of a developer occasionally checking out HISE and then switching his entire product catalogue from KONTAKT to HISE is a pretty theoretical construct, it's more like somebody has had a idea for a product for many years, then he finds out about HISE and the motivation to be able to realise this idea in HISE should get you over the initial hurdles (which are definitely a bit too high at the moment, no doubt).

Also this is not supposed to be an excuse for bad (or rather no) marketing, which HISE clearly is lacking and I admit that the current situation where you need to crawl around in development branches to get a working HISE version is unacceptable but there are plans for a HISE 3.0 release with a complete overhaul of the website, a public licensing scheme and a rather up-to-date nightly build system so your suggestions about the website are pretty reasonable and pretty much equal to what I had in mind. The basic idea still stands though: if you're having problems getting the right IPP version for your XCode, it won't go magically go away and you need to accept that (really frustrating) part of software development to become part of your work as soon as you leave the coziness of a platform like KONTAKT.

> So, assuming the goal is for HISE to be used by more developers

Well yes it is, but I rather have a slow but steady growth of developers like over the last years than an exponential user base growth that is powered by a big $$$ marketing campaign and fancy introduction videos that suggest that HISE can be used by anyone to make instruments - there were several attempts of this from other companies during the last years and so far none of them were successful. In the end HISE is and always will be on the nerdy end of plugin development tools: you need at least know scripting and you'll profit the most out of it if you know your way around C++ a little bit too.
 
For those a little put off by github and commits, try out the desktop app - it was terrible years ago but now it's actually really good and tbh, I use it over command line for HISE projects (but still the plugin for visual studio when making changes to the source).

But as a quick anecdote of "Why HISE", among many other things such as an in app downloader, I recently added equal power looping (~6 lines of code). This has apparently been within NIs bug tracker since at least 2013: https://www.native-instruments.com/forum/threads/equal-power-crossfades-for-loops.170141/

As a developer that really says everything to me, especially when you review the commit history of HISE.
 
Ross, your experience is very similar to mine. I bought a used MacBook Pro specifically so I could load on Catalina, mainly because XCode insisted on it. (As you saw.) I just couldn't get it working, though, so at the advice of one person the HISE forum (but against the advice of another person), I loaded Mojave instead. Many hours later, I eventually got a version working. It's still not perfect, since it won't compile final instruments, but at least I can make basic instruments.

I eventually gave up, though, and hired Lindon to build my instrument for me. That's working out really well ... for me, at least. The stuff I gave him is such a mess that he's probably regretting it, though. :grin:

..lots a stuff removed here by Lindon...

I have no regrets at all - its a really cool and interesting thing to work on - and is pushing HISE (and me) quite hard - so that's nice too.

But I really really get all the comments about getting to a more accessible starting point with HISE. I've been a coder for most of my professional life so version control systems, compilers, libraries etc were all stuff I understood well, and yet HISE was "hard work" at the start - to be fair it was a very early version and it (and its documentation) have moved a million miles in the last 12 months - it should be even better in version 3.0. But as Christoph says in the end there is no getting away from having to climb over the build/compile/libraries/git/github hurdles, you will need to be able to do this if you want to build your own VST/AU/AAX/iOS products.

(((So like a typical coding geek here's where I start to get uncomfortable with the sales/self promotion bit: so turn off if here you want....you've been warned.)))

As has been outlined it seems that as an audio library producer you have either the accessible but limiting option of Kontakt - or at the other end of the scale all the freedom, power and capabilities of "hard to learn" HISE. But like Mike decided to do for this first product there's a middle ground. Just like you can hire Mario(Evil Dragon) to build your Kontakt library there are a (small) number of developers in the HISE community who's business model is to build-it-for-you in HISE. Sure it's not where you will eventually be - but I remember building my first Kontakt instrument and Mario worked as a beta tester on it (yeah its that long ago) and his advice and input was invaluable. Yes I'm one of those guys, but I'm not the only one. I guess I'm saying just like Kontakt there's an eco-system out there now for HISE - you could use it. That first call will likely be free - so whats to loose?

(((( OK that's the bit that flys close to self-promotion- if not falls all the way into it - over with you can start reading again and I can try to forget I ever said any of that and it was someone else's suggestion))))
 
But like Mike decided to do for this first product there's a middle ground. Just like you can hire Mario(Evil Dragon) to build your Kontakt library there are a (small) number of developers in the HISE community who's business model is to build-it-for-you in HISE. Sure it's not where you will eventually be - but I remember building my first Kontakt instrument and Mario worked as a beta tester on it (yeah its that long ago) and his advice and input was invaluable. Yes I'm one of those guys, but I'm not the only one. I guess I'm saying just like Kontakt there's an eco-system out there now for HISE - you could use it. That first call will likely be free - so whats to loose?
That's a good point. (Although this "Mike" guy sounds kinda shady.)

By hiring Lindon to build this instrument for me, it not only takes lots of work off my plate, but it's also very educational, because I'm seeing how he handles each aspect. So if I do decide to continue with HISE for a second instrument, I'll have a much better understanding of how everything works, so I might be able to do that second one myself.
 
That's a good point. (Although this "Mike" guy sounds kinda shady.)

By hiring Lindon to build this instrument for me, it not only takes lots of work off my plate, but it's also very educational, because I'm seeing how he handles each aspect. So if I do decide to continue with HISE for a second instrument, I'll have a much better understanding of how everything works, so I might be able to do that second one myself.

Yeah precisely - though I would question how "educational" watching me work is - still its warts and all...I've uploaded to github every day - and that shady Mike guy has full access so he can "follow along". Part of my intention here is to make sure Shady Mike (sorry its sorta sticking now..I will stop now I promise) can fly this stuff on his own by the end of this.
 
Top Bottom