What's new

For Those of Us Considering Jumping from Kontakt to HISE

EvilDragon

KSP Wizard
Git is a version control system created by (and perhaps named after Linus Torvalds ;) the guy who wrote/writes the Linux Kernel).


From wiki:


Torvalds sarcastically quipped about the name git (which means unpleasant person in British English slang): "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." The man page describes Git as "the stupid content tracker". The read-me file of the source code elaborates further:

The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
  • random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
  • stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
  • "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
  • "goddamn idiotic truckload of sh*t": when it breaks



Yup. :)
 

Dewdman42

Senior Member
git and GitHub are invaluable. I highly recommend all developers to learn git and GitHub as well. GitHub now supports private repos so you can use it as a free cloud backup of your source code. I actually prefer GitLab over GitHub right now, but they are very very similar.

Git can be kind of complicated if you let it, it can also be kept simple, but it is definitely a bit of a left-brained activity....and it will take a bit to wrap your head around it, but I still highly encourage everyone doing any kind of source code or other text based materials to use some kind of version control, and git happens to be the flavor of the day and probably for the next decade at least. Git can definitely also store binary non-text files, including images and everything else, but that is not its forte and if you're not careful your repo can grow huge that way, but do your research about how to properly handle binary files in git. But most of the benefits of git and any version control system are when you have text files with incremental changes that you want to be able to view the changes in a human readable way.

For GitHub/GitLab, In addition to being a cloud server to store your code, they also have issue trackers, boards, for organizing and prioritizing your tasks, etc. You can associate code changes with issue #'s so that in the future you will be able to see exactly what was changed to fix a particular issue, etc.. If you have multiple people working on something together you can facilitate peer code reviews before making the change final, etc.

You can also manage releases as snapshots in time and even distribute your binary through GitHub if you want. You can create wiki docs that exist on GitHub...its a good place to share technical docs between collaborating developers, etc.

The learning curve is a bit steep, no doubt about it, don't expect to master it over night, but anyone that is serious about developing anything that will involve a reasonable amount of source code of any kind, should spend a little time every week learning git and GitHub until it clicks. The benefits are great. that's why so many people are using it. There are lots of version control systems that have come and gone, but due to the distributive and free nature of git, it has taken hold as the defacto standard for the foreseeable future.

If you do source code, you want it under source control. git is the one everyone is using today.
 

chrisboy

Active Member
Git can definitely also store binary non-text files

Well, that's a bit of a problem when it comes to sample files and I would never ever recommend putting the gigabytes of sample data into a Git repository. There's a special extension for Git called LFS (=Large File Storage) which is supposed to address the problem, however it's ridiculously expensive on GitHub and the workflow is super annoying, so I tried it once and never again.

The proven method (at least for me) is ignoring the sample files and just sync Dropbox for it (and you can redirect the sample folder of a HISE project to a Dropbox folder). Sure you loose file versioning, but in no project ever I needed to jump back to an older version of a sample file so that was never a problem.
 

Dewdman42

Senior Member
Agree 100% about sample files, git is not the place except for in house git repos...perhaps with lfs for sure but only perhaps and definitely not on the cloud.

There are lots of other binary Files that can make sense occasionally such as pdf’s, images, stuff related to docs, resource files needed, etc that need to be versioned. But as I said you could easily get into trouble with an exploding git repo if not handled correctly and there might be other ways to point to binary files by versioning. If a binary is not likely to change much or there will never be any need to have access to past, present and future versions of it; then don’t put it in git.

GitHub should not be mistaken as a free file hosting service. It is a place to track file versions and to share mostly text source code with occasional versioned binary files handled carefully that specifically need to be versioned also to match the release schedule of the versioned code and aren’t too big. Git can handle that and so can github but if you’re contemplating having to pay more to extra space you’re probably misusing git IMHO
 

Mark Schmieder

Senior Member
There's also Gorilla Engine from UJAM but it is under beta at the moment and not yet public even in its API specs. I'm not sure how much overlap there is in their goals and those of HISE, but it looks like HISE will be open source, which I don't think will be true of Gorilla Engine.

Is there an active community effort on HISE? I only just saw this thread and there's five pages to go through, but I'll see if I can find a GitHub link, an Issues list, and maybe a way that I can contribute while I am still unemployed.
 

d.healey

Senior Member
but it looks like HISE will be open source,
Well it has been for the last 5 years :P

which I don't think will be true of Gorilla Engine.
Gorilla is proprietary as far as I'm aware

Is there an active community effort on HISE?
HISE is developed almost entirely by Christoph Hart and there is a growing number of us adding smaller contributions. This is the official (Christoph's) repository.
 

Mark Schmieder

Senior Member
Thanks, I'll take a look. I don't generally have a reason to canvas the entire industry for what's going on, so please excuse my ignorance for having a minimal awareness of something that's already been around for five years; it just didn't matter to me before. Right now, I'm trying to do as much as I can to help the music and audio community pro bono as everyone was hurt even if they're still employed.
 

Mark Schmieder

Senior Member
I'm just about to wrap up and publicly post a half dozen of my own open source libraries, but did bookmark the HISE page yesterday and plan to take a deeper look this coming week, as there are several areas where I may be able to contribute.

As I am actively helping someone on a JUCE project at the moment, the timing is pretty good as that shows up in the GitHub repository as part of the picture.
 

Andrew Aversa

Lead Developer
When is HISE going to properly update and address their site & documentation? I check it every 6-12 months and it's always a little lacking. For example, there is no obviously-available feature list. It would make sense to detail what you can do with HISE. Custom DSP? Custom filters? Native code? Efficient disk streaming? Multi outputs? How about a comparison to Kontakt in terms of features? This should be clearly listed on a single page.

Next - all 5 tutorial links in the navigation are broken. The pages have a PHP error. A variety of documentation pages are either confusing or broken.

For example, this page has a missing explanatory image. Also, the layout makes little sense. I don't understand what the author is describing. The "Summary" part should be at the top. If I click "ScriptNode" I want a basic overview explanation of what that is, and some practical examples of how I might use it. I've read the page and I still don't get it.


The ScriptNode manual page is missing:


This page talks about a "scriptnode graph". What is that? Hmm, maybe I can check the glossary. Oh wait, "graph" is nowhere on this page or in the navigation. Also, this page is full of broken images.


I'm interested in the Wavetable Synthesizer module. The page on it describes next to nothing about how it works or how to use it.


Some pages have incomplete sections, like the Slider page. What is Filmstripping? I don't know. It's blank.


The examples area has some interesting stuff. But while a 1Band Dynamic EQ is fine, having only a single DSP example given the staggering amount of DSP possibilities out there, seems very sparse. I'm sure a HISE expert could cook up 4-5 more examples of things like... subtractive synthesis, a filter model, distortion model, or other very common DSP applications.

I'm certainly interested in HISE but it would be really nice to see these things addressed. I'm sure a lot of developers are tired of Kontakt's limitations and interested in a potentially superior option. Taking the time to at least ensure features are documented and presented correctly would probably do a lot to convince people to come over.
 
OP
Mike Greene

Mike Greene

Senior Member
Moderator
Thread starter
  • Thread Starter
  • Thread Starter
  • #92
This speaks to what I believe is a fundamental problem with the open-source model. The HISE engine is very powerful and in the course of my project (an attempted port of Realivox Blue to HISE), Cristoph has been very responsive to our requests for specific updates. The "product" is great, and the "development team" (Christoph) is top notch.

The business side, though ... well, let's just say Christoph is a helluva coder. ;)

Whether it be with the website issues Andrew describes, or the fact that there is no easy download so someone can experiment with HISE (today, rather than having to first learn about IPP and ProJucer and XCode before I can even insert my first sample), or various missed opportunities in terms of presentation ... this is where someone with a good business sense needs to take the reigns. I'll go so far as to say that if someone took this over as a for-profit venture, they could turn it into a true competitor, at least at a level of Falcon.

Take Andrew's 1Band EQ example, for instance. If I were running HISE, the second thing I'd do (first is creating a simple download) is start working out deals with DSP developers to have their effects available, either by me paying them up front, or offering them ala carte to the instrument developers. Good as the Kontakt 6 effects are, this would take things to a whole new level. Unfortunately, that goes completely against the open-source model, though.

It's a lot like LINUX. Great platform (at least that's what all the advocates keep telling me), but it will never go anywhere, because it isn't set up to ever gain traction with anything useful.
 

d.healey

Senior Member
The main problem with keeping everything up to date is lack of man power. However the docs are editable by anyone (I think) so if people are interested they can contribute. I might talk to Christoph about this and see if I can help him out.

Here's the page about contributing - https://docs.hise.audio/glossary/contributing.html
 
Last edited:

AlexRuger

rewgs
Well, that's a bit of a problem when it comes to sample files and I would never ever recommend putting the gigabytes of sample data into a Git repository. There's a special extension for Git called LFS (=Large File Storage) which is supposed to address the problem, however it's ridiculously expensive on GitHub and the workflow is super annoying, so I tried it once and never again.

The proven method (at least for me) is ignoring the sample files and just sync Dropbox for it (and you can redirect the sample folder of a HISE project to a Dropbox folder). Sure you loose file versioning, but in no project ever I needed to jump back to an older version of a sample file so that was never a problem.
Bumping a thread with an idea since I'm running into this same problem at the moment.

All the video games I worked on used Perforce for version control, rather than git. We've version controlled our FMOD/Wwise/etc projects, and it seems much more capable with large files like wavs. I'm considering looking into it myself.
 

MartinH.

Senior Member
Bumping a thread with an idea since I'm running into this same problem at the moment.

All the video games I worked on used Perforce for version control, rather than git. We've version controlled our FMOD/Wwise/etc projects, and it seems much more capable with large files like wavs. I'm considering looking into it myself.

I just tried to find out what that costs and only thing I'm finding is "contact us for a quote".
 

Fredeke

Senior Member
and more effort spent on maintenance as Mac or Windows introduce new operating systems.
You're bound to address that problem with the former, and probably not with the latter. Every OSX version breaks compatibility here and there, while Windows has outstanding records with backwards compatibility (not that I'm a fan, but it has a few qualities).

I still ran apps from 1995 in Windows 8.1 ! They may not look good, but they worked. Now with Windows 10, apps from circa. 2000 are starting to bug a little, but we're still far from the absolute refusal to start up Mac apps exhibit after only a couple of years. Anyway, I run pretty old VSTs and there's absolutely no problem there.
 
Last edited:
Top Bottom