# For Those of Us Considering Jumping from Kontakt to HISE



## Mike Greene (Mar 9, 2020)

A little background: HISE is an open source framework for creating sample libraries. It seems to have the usual mapping, scripting, and other sampler features we'd see in Kontakt or Falcon or Halion, although probably requiring more effort, since it's designed for developers rather than users, so you can customize it how you want. Here's their website:





HISE


The open source framework for sample-based instruments.




www.hise.audio





I've toyed with the idea of creating my own player, especially for my wordbuilder instruments, since Kontakt has a few limitations that are problematic for me. Creating a player from scratch is a massive undertaking, but with HISE, the heavy lifting is already done. A finished library would be released in "my" platform (HISE is a development tool, so the end instrument is a Realitone plugin.), but unlike PLAY or SINE or Spitfire's new player, there's already a working framework and a number of released instruments, so there will be fewer surprises.

The two upsides that are of interest to me are that I can (presumably) do some things that Kontakt can't, and also that I can (again presumably) build in a better copy protection scheme. I suppose there's a third upside that I would eliminate license fees to NI, but that's not that much of a motivation for me, since I'll spend far more time (time equals money) learning a new platform than what I would save in license fees.

The three biggest downsides I foresee are the initial learning curve, the loss of sales to some customers who want to keep everything Kontakt, and more effort spent on maintenance as Mac or Windows introduce new operating systems. (I see on one HISE developer's site that his instruments are not Catalina compatible.)

I suspect a number of other Kontakt developers here may have different motivations from me, but have similar questions, so I'm starting this thread so the topic can be discussed. (I say "discussed," as opposed to "debated." Hint: If you're tempted to use words like "fanboy," you're probably debating, not discussing. The purpose here is not to convince anyone which platform is better, rather it is just to share information.)

A couple questions I'd like to start with:

1. With my upcoming wordbuilder instruments, I want to give the user the ability to type in words on their QWERTY keyboard. Kontakt doesn't (or at least hasn't) allowed me to do that. I assume with HISE, I could?

2. Regarding Catalina, is that resolved? How much work is involved when there is a new Mac or Windows OS?

3. Copy protection is a big motivation for me. I assume iLok is not an option, but can I write my own CP scripts? My theory is that my copy protection, as long as it is unique to Realitone, doesn't necessarily have to be very strong, since there's not as much motivation to crack a single company's CP. Kontak - big motivation. Realitone ... yawn.

*<<EDIT - as of March 16, 2020 - Here are some other useful resources we learn about later in the thread:>>*

HISE Manual

Staring at an interface and trying to figure out how toi get started is always tricky, so I made this "Getting Started" video: Quickstart Video

A _really_ good video on scripting by David Healey: HISE Scripting 101 video

How to install HISE:
Installing HISE on Mac (Mojave)
Installing HISE on Windows

The Mac installation was pretty complicated (for me, at least), so here is where you can download an "already-built" version that works right away, no muss, no fuss. (I guess they call that a "single binary.") It's pretty old (November 2018) and I was advised against it since it's missing a lot of features, but it works, so I'm glad I downloaded it. My assumption is pkg is Mac (that worked for me) and exe is Windows:

HISE.2.0.0.pkg
HISE_2_0_0.exe


----------



## d.healey (Mar 9, 2020)

Mike Greene said:


> The two upsides that are of interest to me are that I can (presumably) do some things that Kontakt can't,


HISE has many features that Kontakt lacks, but it also lacks some features that Kontakt has. HISE has no time/pitch stretching capabilities at the moment - but it's on the to-do list.

However, since it's a free software project you can add in any feature you want. If you're not a C++ programmer then you can hire someone else to add the necessary changes, or do what the rest of us do - nag Christoph (the HISE developer) to do it.



> I suppose there's a third upside that I would eliminate license fees to NI, but that's not that much of a motivation for me, since I'll spend far more time (time equals money) learning a new platform than what I would save in license fees.


If you're releasing a proprietary HISE built plugin then there are still some licensing fees (probably quite reasonable though).



> The three biggest downsides I foresee are the initial learning curve, the loss of sales to some customers who want to keep everything Kontakt, and more effort spent on maintenance as Mac or Windows introduce new operating systems. (I see on one HISE developer's site that his instruments are not Catalina compatible.)


I have tutorials on my YouTube channel that will help to get you started. A customer got back to me and said they are running one of my plugins on Catalina (even though I haven't notarized it). Plugins made with HISE are compatible with Catalina but you're supposed to code-sign and notarize them which I haven't got around to doing yet.



> A couple questions I'd like to start with:
> 
> 1. With my upcoming wordbuilder instruments, I want to give the user the ability to type in words on their QWERTY keyboard. Kontakt doesn't (or at least hasn't) allowed me to do that. I assume with HISE, I could?
> 
> ...



*1:* Yes

*2:* Windows updates shouldn't cause any issues because it doesn't require code-signing. MacOS - only Apple knows how they intend to screw up existing software, but for Catalina you need to have an Apple developer ID to code-sign and notarize plugins. There is some info about this on the HISE forum with a link to a tutorial at KVR.

*3: *iLok might be an option but you'd have to do some C++ work. HISE has a simple serial key system as well as a more robust server/client system (as used by PercX).

*4: *(You didn't ask this but you'll want to know). Since Pro-Tools doesn't support VST or AU plugins you'll also need to compile AAX plugins. This requires an AVID developer account and their SDK.

*5: *(You didn't ask this either). To build Windows plugins you need a Windows machine, Mac plugins require a Mac machine etc. I've found it best to use a Mac (Mini) and triple boot it with MacOS, Windows, and GNU/Linux so I can build for all three platforms on one system. I also use automated build scripts to build each plugin format and standalone program with one command. This is more advanced stuff that you'll want to look into later on if you get going with HISE.


----------



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

I got a question too.

I see that HISE supports vector graphics. 
Does it support 3D meshes and some sort of realtime 3D lighting?
Or anything else for that matter. (any type of image post processing)


----------



## jamwerks (Mar 9, 2020)

Can someone give us some names of devs/libraries that use HISE? Do we all have some and not even know it?


----------



## d.healey (Mar 9, 2020)

P.N. said:


> I see that HISE supports vector graphics.
> Does it support 3D meshes and some sort of realtime 3D lighting?
> Or anything else for that matter. (any type of image post processing)



No 3D rendering. It support rLottie vector animations.



jamwerks said:


> Can someone give us some names of devs/libraries that use HISE? Do we all have some and not even know it?




https://librewave.com (Me)
Auddict (PercX and Hexeract)
Channel Robot
NeoSoul Keys
Sampleson
There are a few others (can't remember their names) active on the HISE forum. I also know of a couple of larger devs that are working on unannounced (secret) HISE projects.


----------



## Nick Batzdorf (Mar 9, 2020)

Being a Realitone fanboy, I just looked at the HISE site.

For the Mac version it lists compatibility with OS X 10.7 to 10.12, and Catalina is macOS - not OS X anymore  - 10.15.

Is that real or just that they haven't updated the site?


----------



## d.healey (Mar 9, 2020)

Nick Batzdorf said:


> Is that real or just that they haven't updated the site?


Copyright at the bottom of the page says 2017, I assume that's when it was last updated.


----------



## robgb (Mar 9, 2020)

d.healey said:


> HISE has many features that Kontakt lacks, but it also lacks some features that Kontakt has. HISE has no time/pitch stretching capabilities at the moment - but it's on the to-do list.


I've gotta be honest. I played around with HISE but can't for the life of me figure out how to make it work on my computer. It's been awhile since I tried, but apparently I have to download some source code libraries or something along those lines to get it to compile anything? I can't really remember. I just remember thinking it was hurting my head, so I did something uncharacteristic of me and gave up...


----------



## ProfoundSilence (Mar 9, 2020)

I had a hise library and didn't know it. (hexeract)

+1 for promoting alternatives that are a bit more flexible than a proprietary engine for small devs. 

I'm excited for SINE but it doesn't help sample developers as a whole, and you cant just up and make a library on your own for the spitfire player for instance- so alternatives for sample developers to make sample libraries.


----------



## d.healey (Mar 10, 2020)

robgb said:


> I've gotta be honest. I played around with HISE but can't for the life of me figure out how to make it work on my computer. It's been awhile since I tried, but apparently I have to download some source code libraries or something along those lines to get it to compile anything? I can't really remember. I just remember thinking it was hurting my head, so I did something uncharacteristic of me and gave up...


HISE requires a bit of technical skill and initial setup. I have tutorials on YouTube showing the setup on all operating systems.


----------



## Lindon (Mar 10, 2020)

P.N. said:


> I got a question too.
> 
> I see that HISE supports vector graphics.
> Does it support 3D meshes and some sort of realtime 3D lighting?
> Or anything else for that matter. (any type of image post processing)


So in the "anything else" bucket:

- support for TrueType fonts
- script nodes - essentially (and I'm simplifying here) - a system not unlike Max or Reaktor (with all the associated screen-jumble) - that allows you to define and connect (with cables) nodes to make your own processing units - Here's an example from one of the "ScriptNode Experts" @ustk - its a formant processor...I think....so yeah all the power and all the ugliness...

NOTE: You dont have this unless you add it...so you are not natively wading thru this stuff...




- "real" oscillators - so we can all make a subtractive synth in Kontakt (just load up a wav file that is a single cycle from some osc.) but there are the anti-aliasing issues - HISE has built-in a synth - with all the usual subtractive synth candidates (Sine, Saw, Pulse, etc. etc.) and some FM capability
- Additive synthesis - you can use the sine wave generator to "do" additive synthesis - Sampleson are probably the experts on this...
- expansion system - allowing you to define new graphics(UI) and sample content and ship it as an expansion for your existing instrument - PercX uses this..
- unison - built in for all sound sources..
There's a lot more but that will do for now on the up side...

Downside:
- the FX are not as extensive as Kontakt - there's no flanger for a start - and the only meaningful distortion is the polyphonic waveshaper - there's no bit reduction either. Kontakt had a set of fairly ordinary FX for a long while - but now it's starting to gain the very very acceptable FX from NI stable of stand alone FX plug-ins so the quality is really very good. You may be waiting a fair while for similar FX to arrive in HISE - Christoph said the script node system was a response to "can I have XYZ audio FX please" - so I think he would point you at ScriptNode and say build your own...

- no "use your own samples" - recently added to Kontakt - on the to-do list at HISE

- Theres no bus system - building send structures for Send FX is still something that mystifies me - the tree structure of HISE is massively powerful but its here that HISE is harder to work with than Kontakt - though there is an outstanding request (from me) for a bus send/recieve FX which Christoph has said is a good idea so it will show up at some point (I have my fingers crossed)

- there's no wait() statement - In kontakt if you want to wait a fixed amount of time you just say wait(1000) and you get it given - HISE doesn't support this (real-time like environments really shouldnt) so you have to set up and use a timer(with its own independent function) - nice thing about HISE is you don't have just one timer (on listener to you KSP people) you can have as many as you want all running at different speeds - tho' Christoph has said anything past about 16 timers might start to affect performance - so more power - less ease of use

- the sample offset start is limited. You want to start your sample playback in Kontakt at 12 seconds into your 30 second wav file? - no problem - HISE? ...no dice its a very short offset capability - so stuff like the granular system I wrote in Kontakt wont work in HISE - I'll have to think of another approach - current favourite goes like this "Christoph? Pretty Please? Can you add a granular processor? Pleeeeeeease...." 

Fire away with specific questions .....


----------



## Lindon (Mar 10, 2020)

d.healey said:


> *2:* Windows updates shouldn't cause any issues because it doesn't require code-signing. MacOS - only Apple knows how they intend to screw up existing software, but for Catalina you need to have an Apple developer ID to code-sign and notarize plugins. There is some info about this on the HISE forum with a link to a tutorial at KVR.


Just a quick clarification here: if you are building plug-ins (VST/AU) on MacOS they will need to be codesigned - they do not and should not be notarized....

If you are building a stand-alone app for MacOS or iOS (yes you can build apps for your iPad..) then they will need to be codesigned AND be Hardened runtime enabled. They will also need to be notarized.

If you are building an installer (with something like Whitebox Pacakages) then this will need to be noterized too...

Theres a fairly techy-savy thread here at KVR Audio about this process...









KVR Forum: HOWTO macOS notarization (plugins, app, pkg installers) - DSP and Plug-in Development Forum


KVR Audio Forum - HOWTO macOS notarization (plugins, app, pkg installers) - DSP and Plug-in Development Forum




www.kvraudio.com


----------



## EvilDragon (Mar 10, 2020)

Lindon said:


> so we can all make a subtractive synth in Kontakt (just load up a wav file that is a single cycle from some osc.) but there are the anti-aliasing issues



Just FYI, there's the wavetable oscillator as well which is much better suited for this express purpose.


(Also BTW thanks for the pros/cons breakdown from your side! Is it still the case that you cannot dynamically load/unload FX from script like you can in Kontakt?)


----------



## Mike Greene (Mar 10, 2020)

Thank you David and Lindon. These are really good breakdowns, and exactly the sort of info I need. I think what I'll do now is go ahead and install it and then start playing around with it.

The videos take a while to search, so for those wanting links for installing HISE, here you go:
Installing HISE on Mac (Mojave)
Installing HISE on Windows


----------



## Lindon (Mar 11, 2020)

EvilDragon said:


> Just FYI, there's the wavetable oscillator as well which is much better suited for this express purpose.
> 
> 
> (Also BTW thanks for the pros/cons breakdown from your side! Is it still the case that you cannot dynamically load/unload FX from script like you can in Kontakt?)


I'm working hard not to be on "a side" Mario...

Oh yeah - forgot the wavetable oscillator in Kontakt - there's one in HISE too...this doesn't get around the anti-aliasing issue tho right? its still a sample being run thru not a calculated shape..

..and for dynamic load/unload of effects - in HISE there's an Effect called "Effect Slot" which allows you to select(load) any effect you want - but I've never used it so I cant comment on its viability, also there's no arbitary limit on effects either (no 8 slots and thats your lot - tho I cant imagine anyone really needing more) - you can have 20-30 fx if you want in HISE - it would grind to a halt at some stage tho...

A couple of other things that occurred to me whilst out chipping render off my house this morning(it was boring and I had to think about something)....


real-time envelope displays: - you can display your AHDSR envelope along with a set of controls - move a control the envelope redraws:





-- see that little black dot (you can have any colour you want)?- thats me playing a note and HISE showing me the position as the envelope executes...

User drawn LFOs:





LFO's can be any classic shape you want - but they can also be "user drawn" - above is a slightly mad example - user can define as many nodes as the like and define the curve between nodes... oh you can have LFOs behave as "one shot" - so in effect these are tempo controlled multi-point envelopes.

Real-time filter displays:






Select a filter type, and set its controls and the user can see whats going on..These will "move" if you add (say) an LFO to them.


EQ displays





This isnt a very clear example - as the eq display itself is placed behind the controls - so you dont have to have it like this - but you get a mutli-band eq (as many bands as you like not just 3 or 4 - tho its 4 here in this example) - and a display window that shows you the eq curve that changes as you change eq settings...

I'm trying to think of something negative about the UI in HISE - so I come off as more balanced, but I cant think of anything right now...sorry.


----------



## EvilDragon (Mar 11, 2020)

Lindon said:


> I'm working hard not to be on "a side" Mario...



I didn't mean THAT side (your vs my team). I meant from your POV as developer on both platforms.



Lindon said:


> Oh yeah - forgot the wavetable oscillator in Kontakt - there's one in HISE too...this doesn't get around the anti-aliasing issue tho right? its still a sample being run thru not a calculated shape..



It is cleaner than if you'd just stretch one zone of a sample across the keyboard. It works in a different way than pure sample playback, and also has 4 different interpolation quality levels.



Lindon said:


> I'm trying to think of something negative about the UI in HISE - so I come off as more balanced, but I cant think of anything right now...sorry.



Maybe that all that realtime UI refreshing is also a CPU drain?  (Unless it's GPU accellerated of course, but this also has its tradeoffs.)


----------



## d.healey (Mar 11, 2020)

EvilDragon said:


> Maybe that all that realtime UI refreshing is also a CPU drain?  (Unless it's GPU accellerated of course, but this also has its tradeoffs.)


UI stuff is handled in non-realtime thread and only when the interface is opened/visible.


----------



## Lindon (Mar 11, 2020)

EvilDragon said:


> I didn't mean THAT side (your vs my team). I meant from your POV as developer on both platforms.


OH OK - sorry.



EvilDragon said:


> It is cleaner than if you'd just stretch one zone of a sample across the keyboard. It works in a different way than pure sample playback, and also has 4 different interpolation quality levels.


OK maybe that's not such a big deal then, but HISE isnt doing any interpolation - its doing straight calculation.....



EvilDragon said:


> Maybe that all that realtime UI refreshing is also a CPU drain?  (Unless it's GPU accellerated of course, but this also has its tradeoffs.)



I think Dave got this one...but I'm actually really surprised how little CPU is getting used in my HISE products...

Oh and one more of these real time displays:

You get an Analyser FX: so you can show your end users any or all of: Oscilloscope, Goniometer(you know the thing that shows you the stereo spread) and Spectral Analyser


----------



## EvilDragon (Mar 11, 2020)

Lindon said:


> OK maybe that's not such a big deal then, but HISE isnt doing any interpolation - its doing straight calculation.....



With wavetables you always have to interpolate. All you have is a single cycle waveform at a static pitch, and it has to work across the whole keyboard. Interpolation is calculation too


----------



## Lindon (Mar 11, 2020)

EvilDragon said:


> With wavetables you always have to interpolate. All you have is a single cycle waveform at a static pitch, and it has to work across the whole keyboard. Interpolation is calculation too


No I think you misunderstand me - yes, sure, HISE I'm sure is doing interpolation just like Kontakt in its wavetable synth - but... HISE *also* has a "classic" synth inside - that is doing the "straight" audio rate calculation for each note played - no interpolation, no attempt to deal with anti-aliasing in any way - its a straight mathematical calculation - no wave data of any kind...like say U-He are doing in one of their analog style synths... (NOT saying HISE's synth is in the same ball-park as U-He products - tho some time this year I hope to prove it can be just as good as....)


----------



## EvilDragon (Mar 11, 2020)

Right, virtual analog oscillators you say. If there's no attempt to deal with anti-aliasing, though, then it sounds pretty shit, since there would be aliasing artifacts everywhere very easily. Naively coded oscillators alias like hell and sound bad. So there better be some attempts to do anti-aliasing, be it band-limiting or something else.


----------



## Lindon (Mar 11, 2020)

EvilDragon said:


> Right, virtual analog oscillators you say. If there's no attempt to deal with anti-aliasing, though, then it sounds pretty shit, since there would be aliasing artifacts everywhere very easily. Naively coded oscillators alias like hell and sound bad. So there better be some attempts to do anti-aliasing, be it band-limiting or something else.


yes the point Im trying to make here is that its NOT using wave file data.


----------



## EvilDragon (Mar 11, 2020)

All good, I got that  Still needs antialiasing tho


----------



## Lindon (Mar 11, 2020)

EvilDragon said:


> All good, I got that  Still needs antialiasing tho



As I've said .. yes. They dont sound "pretty shit", they are not "naively coded" they are very good.


----------



## chrisboy (Mar 11, 2020)

The answer whether the waveform generator uses a naive implementation or not can be found in the source code :


```
#define NAIVE 0
#define USE_MARTIN_FINKE_POLY_BLEP_ALGORITHM 1
```

If you change this compiler flag and build HISE, you'll get the beautiful sound of non-aliased waveforms in all their glory...


----------



## Lindon (Mar 11, 2020)

..and for those who care to know...









Making Audio Plugins Part 18: PolyBLEP Oscillator - Martin Finke's Blog






www.martin-finke.de


----------



## EvilDragon (Mar 11, 2020)




----------



## Mike Greene (Mar 14, 2020)

Okay, so I started installing HISE and ... well, I think I now know why there are so few developers adopting it. 

This installation process, even with David's video, is way over my head. Download this, download that, create an Apple ID so I can get XCode, get this Intel stuff which seems to be optional for some reason I don't totally understand, install and delete some IPP thing that I have no idea what that even is, put this into that folder, replace this file with that file unless x, y or z ... sure, I could probably get it to work if I spent some time on this, but given that HISE is an idea I'm toying with, as opposed to "definitely need to do this," I'm gonna wait until somebody more experienced with this stuff comes into my studio and can do this for me.

HISE isn't my baby, so it's a bit presumptuous of me to start spouting advice, especially since I don't know what Chrostoph's goals actually are. But here goes anyway. Here's what I would do:

Create a single download option. Make it so that all we have to do is click one zip file for OSX or one zip file for Windows, open it, boom. There's HISE, ready to start playing with.

Now, I know what you're thinking - Obviously, HISE and its various elements are constantly evolving, so maintaining a single download would be an enormous PIA. But what I'm suggesting doesn't need to be updated. Just pick a day, put it together, and that's the "HISE for Dummies" version. Maybe it only gets updated once a year. I'm fine with that. I don't need the newest features, I don't even need all the features, I just want to start checking it out.

Then after I play with it and start dropping in some samples and maybe do some basic scripting and getting a feel for it, then I go back and download all that other stuff, half of which I'm guessing is unnecessary until I get serious anyway.

That's what I would do. Because as much of a doofus as I probably sound like, most Kontakt developers are just like me. Many of us are decent KSP coders, but almost none of us are Computer Science grads who are comfortable assembling stuff we've never dealt with before. So to make HISE appealing, there needs to be an easier point of entry.

Maybe that's not possible, but it would be nice.


----------



## d.healey (Mar 14, 2020)

This process is definitely daunting to someone new to dealing with compiling source code. I struggled at the beginning too, and there was a lot less help available. The community at that time was much smaller.

Once you've built a project in HISE you'll want to export it to one of the various plugin formats. To do that you will need a build system (xcode, vs, g++, etc.) set up correctly. This is true even if you are using a pre-built click and go version of HISE (such versions are already available from the HISE website but they are way out of date so don't use them).

To successfully build HISE yourself from source you also need this build system setup. So it's best to get over this hurdle at the beginning, afterwards it's a breeze to update to the latest version, and it's (usually) 1 click to export your plugins.

I could send you the latest version as a single binary, but that won't help you when you want to export your plugins.

I can walk through the build process on Skype with you if you like.


----------



## Mike Greene (Mar 14, 2020)

Thanks David. Even though it may be old, I downloaded that download-and-go version and at least now I can see some basics. Fun to finally get started.

It looks like there's no manual, though? I know there are video tutorials and a forum, but that's really time consuming, especially since as I get started, there are a ton of questions, like how do I get my MIDI keyboard to work? (I see a preferences tab, but that seems to be an authorizing thing, rather than settings.) Or how to open a "map" so I can put in samples. (Figured it out - Click the + at the top next to "Master Chain," then select "Sampler." Apparently Samplers are like groups in Kontakt and you can have a whole bunch of them.) Or how do I move samples once they already in place? (Figured it out - On a Mac, use the Option key to enable the Hand icon.)

EDIT - I figured out how to enable my MIDI keyboard - Click the Gears at the upper right. This opens up settings but starts with "Project Settings," which fills the whole window and gave me the impression that was all it did.


----------



## d.healey (Mar 14, 2020)

Manual is here - https://docs.hise.audio/ - some images are missing at the moment but most of it's there.

In the latest versions of HISE the manual is built in, accessed via F1. The system used to create the in-built documentation can also be used to create built in documentation for your own projects. The docs can link to a server so your users will always have the latest version.

There is more documentation here in the form of blog posts.

HISE samplers are a little different to Kontakt's groups. A sampler is almost like a whole instance of Kontakt. It has groups, an amplifier section (gain in HISE), a pitch section, fx, scripts, etc. One really nice thing is you don't need to use the groups for multiple mic positions like in Kontakt. There is also dynamic crossfading built in.

You can have multiple samplers in your project, although for performance reasons you should aim to have as few as possible (as a rule of thumb no more than 16 but there are exceptions).

HISE offers multiple ways to layout your instruments and you'll probably take a different approach for each project depending on its needs. For example with Sofia Woodwinds I use one sampler per articulation, and one sampler for release triggers. With Michaela's Harp I think I use just one sampler and the articulations are separated into groups.


----------



## Mike Greene (Mar 15, 2020)

Thanks David, that's a good manual.



d.healey said:


> HISE samplers are a little different to Kontakt's groups. A sampler is almost like a whole instance of Kontakt. It has groups, an amplifier section (gain in HISE), a pitch section, fx, scripts, etc. One really nice thing is you don't need to use the groups for multiple mic positions like in Kontakt. There is also dynamic crossfading built in.


This sounds really interesting, and I'm intrigued by the possibilities.

Your HISE Scripting 101 video is really excellent. (I'll add that, as well as a couple other things, into my OP so that this info can be more easily accessible.) If you're in the mood, here's an idea for another video that I think would be helpful for those of us starting out:

I could use a video where you create a quickie instrument from scratch which shows how the "Samplers" work. Nothing fancy, even one sample per "Sampler" is fine, since all of us already know how to drop more than one sample onto the map, and we can figure out what the pitch/velocity parameters mean. (I would make a video that assumes the viewer is already very familiar with samplers.)

That part is pretty straightforward, but in a Kontakt instrument, I'll often need more than a hundred groups, so since HISE is limited to 16 "Samplers", it would be great if you could show how that is achieved. Again, nothing fancy, just a quick-and-dirty example of how to get multiple articulations (2 is fine ... I can figure out from there how to do 3  ) and mic positions (again, just 2 is fine) into a single Sampler.

I assume scripting has to be involved to make that work, so it would be great if you can show a rudimentary example of that, including showing _where_ we put that script (or those scripts.) Mind you, I don't think you need to explain the code itself, since that would be a video in itself. Instead, just show the code (and where it goes) with maybe an an overview explanation, and then we can go through it on our own.

Also, since almost anyone who watches this would be coming from Kontakt, I would actually say, _"Groups in Kontakt are the same as 'Samplers' in HISE, but with these differences..."_ That would be helpful for any other naming differences as well, since like I said, most of us are coming from Kontakt, so it makes it easier to get our footing.


----------



## d.healey (Mar 15, 2020)

I have a video about changing articulations, but it's quite in-depth. I'll look into doing a simpler quick-start type video soon. And I'll make a separate video for multi-mic stuff.


----------



## Mike Greene (Mar 16, 2020)

d.healey said:


> I have a video about changing articulations, but it's quite in-depth. I'll look into doing a simpler quick-start type video soon. And I'll make a separate video for multi-mic stuff.


Thanks David. That video shows what I needed to know (for any other Kontakt people, you see what you need to know in the first three minutes), and I'm now up and running, so no rush on my account regarding the quick start video. (Although if you have time, I think it's still worth pursuing.)


----------



## Mike Greene (Mar 16, 2020)

Since I was playing with HISE anyway, I went ahead and made a Quickstart video where I show how to get started and how to put samples into groups.


----------



## Lindon (Mar 17, 2020)

Mike Greene said:


> Since I was playing with HISE anyway, I went ahead and made a Quickstart video where I show how to get started and how to put samples into groups.


Nice Mike,

A couple of points...

The way you *first* put your samples in the <Project Name>/Samples folder before you mapped them in your Sampler is correct. More than that its pretty much the only way you will get to produce sample maps that you can easily compress and ship with your product. So it might be worth mentioning that in all cases when you are doing the sort of sample mapping you have in your video - FIRST you need to copy the wav files into the project folder(as you have done) - if you dont (and you drag them from some folder OUTSIDE your project folder structure) you are very very likely to get problems down the road.

Second "Samplers are like groups in Kontakt" - yeah I can see how you'd think that - I did at the start - but as Dave has said Samplers are WAAAAAY more powerful than Kontakt Groups - and they are (in essence) mini-kontakts all on their own - in the same way that you can have heaps of groups inside Kontakt, and a scripting space, you can have heaps of groups and a scripting space inside EACH sampler. The restriction of 16 Samplers - is in effect a limit that says "only 16 copies of Kontakt inside your instrument"


----------



## d.healey (Mar 17, 2020)

Lindon said:


> The restriction of 16 Samplers


You can add more than 16 samplers. I just advise against it because it's going to eat up system resources and it is generally better to have as few samplers as possible.

If you're building a more complex library that might need extra samplers for only some specific patches then there are tricks to reduce the amount of overhead of the unused samplers. This applies even if your project only has two samplers but one is unused.


----------



## EvilDragon (Mar 17, 2020)

It's basically like NKIs then, in a way. Since you can have up to 64 of them in a Kontakt rack. That's about as close of an analogy as it can get, no?


Are there any (practical, not theoretical) limits to group/zone count per sampler in HISE?


----------



## d.healey (Mar 17, 2020)

EvilDragon said:


> It's basically like NKIs then, in a way. Since you can have up to 64 of them in a Kontakt rack. That's about as close of an analogy as it can get, no?



This is a good comparison. Samplers don't have a direct equivalent in Kontakt, they have features of both groups and NKIs but are not exactly either one.



> Are there any (practical, not theoretical) limits to group/zone count per sampler in HISE?


Not that I've encountered. I know of a developer who is building a HISE project that uses hundreds of groups and tens of thousands of samples. They hit some issues last year but Christoph fixed the underlying cause and it seems their project is moving along just fine now.

One thing that seems to be missing is the ability to activate multiple groups at once in the same way we can in Kontakt. So far this hasn't been an issue for me because of the way instruments are generally organised in HISE, but I can see future applications where this would be helpful. I'll have to nag Christoph (or perhaps there's a way to do it already that I don't know).

Update: I just found a way to enable multiple groups. I don't like it though and it requires manually handling of note ons/offs


```
for (i = 1; i < NUM_GROUPS+1; i++)
    {
        Sampler1.setActiveGroup(i);
        Synth.playNote(Message.getNoteNumber(), Message.getVelocity());
    }
```


----------



## Mike Greene (Mar 17, 2020)

Lindon said:


> The way you *first* put your samples in the <Project Name>/Samples folder before you mapped them in your Sampler is correct. More than that its pretty much the only way you will get to produce sample maps that you can easily compress and ship with your product. So it might be worth mentioning that in all cases when you are doing the sort of sample mapping you have in your video - FIRST you need to copy the wav files into the project folder(as you have done) - if you dont (and you drag them from some folder OUTSIDE your project folder structure) you are very very likely to get problems down the road.


That makes sense. Just to clarify, is it still okay to drag samples in from the folder on my desktop, rather than using the files section on the left sidebar of the HISE interface, as long as I'm dragging from the Samples folder that's inside the Project folder on my desktop?



Lindon said:


> Second "Samplers are like groups in Kontakt" - yeah I can see how you'd think that - I did at the start - but as Dave has said Samplers are WAAAAAY more powerful than Kontakt Groups - and they are (in essence) mini-kontakts all on their own - in the same way that you can have heaps of groups inside Kontakt, and a scripting space, you can have heaps of groups and a scripting space inside EACH sampler. The restriction of 16 Samplers - is in effect a limit that says "only 16 copies of Kontakt inside your instrument"


That's becoming clearer as I keep playing around with this, and I'm seeing that HISE is indeed really powerful.

The one group issue I'm concerned about is that if I use the Round Robins to create all the necessary "groups" I'll need, can those RR "groups" each have their own volumes, envelopes and other settings? I'm assuming that would be accomplished through scripting (e.g. if RR Group 4, use Envelope 2 and mute all other envelopes)?

One other question - One thing that looks really appealing is that it appears that we can apply individual scripts to any of the elements of the instrument. Obviously that's nice that we can have that control, but what makes that even more appealing (to me, at least) is that these scripts can be individually placed where I use them, rather than in a giant master script. (The smaller I can make the master script, the better.)

So my question is - Is there a PGS equivalent so that these individual scripts can know what the master script is doing? For instance, in my wordbuilder example, can the master script tell an envelope script, _"Hey, we're starting with an "s" instead of a "t", so make the Attack longer."_?


----------



## d.healey (Mar 17, 2020)

Mike Greene said:


> That makes sense. Just to clarify, is it still okay to drag samples in from the folder on my desktop, rather than using the files section on the left sidebar of the HISE interface, as long as I'm dragging from the Samples folder that's inside the Project folder on my desktop?


Yes



> The one group issue I'm concerned about is that if I use the Round Robins to create all the necessary "groups" I'll need, can those RR "groups" each have their own volumes, envelopes and other settings? I'm assuming that would be accomplished through scripting (e.g. if RR Group 4, use Envelope 2 and mute all other envelopes)?


This is where HISE's tree structure falls down (currently). Groups have almost no routing. As you guessed you'll need to script this by turning modules on/off or adjusting their parameters. If it were possible to have more than one group active at a time (other than when using group FX) this could be really annoying.



> One other question - One thing that looks really appealing is that it appears that we can apply individual scripts to any of the elements of the instrument. Obviously that's nice that we can have that control, but what makes that even more appealing (to me, at least) is that these scripts can be individually placed where I use them, rather than in a giant master script. (The smaller I can make the master script, the better.)


Yes, this modularity is one of the greatest things about HISE. You can have a bunch of little scripts instead of one massive script. And you can reuse your scripts easily in other projects. I have a bunch of little scripts I use often here. The largest script in your project will probably be your main interface script, generally you should avoid doing any MIDI processing in this script to keep all of the UI stuff out of the real-time thread, but as always there are exceptions and it depends on what you're doing.



> So my question is - Is there a PGS equivalent so that these individual scripts can know what the master script is doing? For instance, in my wordbuilder example, can the master script tell an envelope script, _"Hey, we're starting with an "s" instead of a "t", so make the Attack longer."_?


Kind of. You can have global variables to share data between scripts. But there is no callback for when these variables change. Every script is also capable of accessing the controls of every other script, and this does trigger the accessed control's callback. With a combination of these two things and a bit of lateral thinking you should be able to have all the inter-script communication you need.

My current project has loads of scripts that interact with each other. Sharing data through global variables and carrying out actions based on UI control values which are set by other scripts.


----------



## Mike Greene (Mar 17, 2020)

Thanks David. (And thank you Lindon, too.)

One more question (sorry for all the questions, but I need to make sure there are no "deal-breakers" lurking, before I actually commit to doing this) - I think you or Lindon mentioned before that HISE doesn't do wait commands, so we would need to use a timer callback for that.

In a wordbuilder instrument, obviously I use the heck out of wait commands, since I start with a consonant, then wait, then if there's a second consonant (s followed by t, for instance) play that second consonant, wait, then start the first part of the vowel, wait before starting the end part of the vowel, etc. I can make a good guess how to do this with whatever the equivalent to an "on listener" callback would be. (I think you called that a "timer"?) So my questions:

1. How short a time can that timer (listener) callback be without causing problems? Is a 5 millisecond loop safe?

2. I assume there can be "play note" commands in the timer callback?

3. Now that I think about this, I wonder if this could be accomplished with delay effects? For example, the user plays a note and the current syllable is "Stu." So the script plays three notes all at once:
a. One is a note where only the s group is activated, then
b. A second note (without a wait) is a note where only the t group is activated, but sets the Delay effect on that "note" to 50 milliseconds so we don't hear the "t" until after the "s", then
c. A third note (no wait command) is a note where only the "oo" group is active, but sets the Delay effect on that "note" to 80 milliseconds, so that in reality, it would occur 30 milliseconds (80 - 30) after the "t."


----------



## d.healey (Mar 17, 2020)

The lack of a wait statement threw me too when I first started with HISE.



Mike Greene said:


> 1. How short a time can that timer (listener) callback be without causing problems? Is a 5 millisecond loop safe?


Timers are limited to a shortest speed of 40ms. If you need faster then it's time to nag Christoph.

I just had a thought. You could hack a wait statement together using a loop and the Engine.getUptime() function. This won't be real-time friendly though so might not be a good idea. But something to play with!

Update: Doesn't seem to work, causes execution time-out error :(



> 2. I assume there can be "play note" commands in the timer callback?


Yes. I use this a lot.



> 3. Now that I think about this, I wonder if this could be accomplished with delay effects? For example, the user plays a note and the current syllable is "Stu." So the script plays three notes all at once:
> a. One is a note where only the s group is activated, then
> b. A second note (without a wait) is a note where only the t group is activated, but sets the Delay effect on that "note" to 50 milliseconds so we don't hear the "t" until after the "s", then
> c. A third note (no wait command) is a note where only the "oo" group is active, but sets the Delay effect on that "note" to 80 milliseconds, so that in reality, it would occur 30 milliseconds (80 - 30) after the "t."


Sounds like it should work, I've not tried changing the active groups in a timer. Give it a try and report back  You might be better off separating your samples by velocity rather than group, unless you need the velocity range for some other purpose.


----------



## Mike Greene (Mar 17, 2020)

d.healey said:


> Timers are limited to a shortest speed of 40ms. If you need faster then it's time to nag Christoph.


Checking my current KSP script, some of my shortest wait times are 2ms, so 40ms would be way too long for certain consonant clusters. I think the delay trick should work, though. I'll test the method when I have a stronger footing with all this.



d.healey said:


> You might be better off separating your samples by velocity rather than group, unless you need the velocity range for some other purpose.


Definitely. There are almost 40,000 samples (just one mic position, so it's _legitimately_ 40,000 samples), so we're squishing them in with all sorts of tricks.


----------



## Lindon (Mar 18, 2020)

Mike Greene said:


> Checking my current KSP script, some of my shortest wait times are 2ms, so 40ms would be way too long for certain consonant clusters. I think the delay trick should work, though. I'll test the method when I have a stronger footing with all this.
> 
> 
> Definitely. There are almost 40,000 samples (just one mic position, so it's _legitimately_ 40,000 samples), so we're squishing them in with all sorts of tricks.


if you want delays down to 1 ms you can do this - simply add a "Simple Gain" effect to the module you want (in this case your sampler) - you will see the Simple Gain effect has a delay parameter- which you can set with your script...


```
const var MyGain = Synth.getEffect("MyGain");


and on some event....


MyGain.setAttribute(MyGain.Delay, somevalue);
```

in this case your script might fire all your "voice partials" at the same time having set a ms delay for each sample so they play back sequentially...never done it - never needed 1ms delay - but it should work I think.

Additional nice thing is you get sub-ms delays you need 14.33 ms? no problem...

..and you can keep all your "voice partials" in an object array, with their sample map, their note number, and their delay amount...for ease of access..


----------



## d.healey (Mar 18, 2020)

There's also Message.delayEvent() which has sample level timing.


----------



## Lindon (Mar 18, 2020)

d.healey said:


> There's also Message.delayEvent() which has sample level timing.


Thats probably even better - as you can use the same "voice partial" just delay it different amounts as needed in each phrase..


----------



## d.healey (Mar 18, 2020)

Lindon said:


> Thats probably even better - as you can use the same "voice partial" just delay it different amounts as needed in each phrase..


I'm not too sure how useful it will be in this particular situation. It only works with Message events, not played notes. It might be possible create an artificial message using a message holder though.

Edit: I just remembered there is also Synth.addNoteOn() and Synth.addNoteOff() which have a timestamp parameter. That'll probably do the job.


----------



## Mike Greene (Mar 18, 2020)

Lindon said:


> if you want delays down to 1 ms you can do this - simply add a "Simple Gain" effect to the module you want (in this case your sampler) - you will see the Simple Gain effect has a delay parameter- which you can set with your script...


Perfect. So it looks like I have some good options. This one appeals to me most (at the moment, at least), because it's easier for me to understand. Plus I think it might make for an easy way for me to organize the samples:

The instrument has Initial Consonants, Second Consonant, Vowels, Closing Vowels, and three Ending Consonants. So I could make one "Sampler" for each of those categories. That would be 7 Samplers. So for each syllable, the script would send the appropriate delay parameter to each Sampler, then simply play them all at once. (Obviously muting the Samplers that aren't needed, since most words don't have that many consonants.)

I tried this just now and ... it works! It's just static settings, with no scripting (I'm setting the delays manually), but making the script control those delays will be easy. One snag is the maximum delay in Simple Gain is 500ms, which might not be enough in certain circumstances. So I also tried the regular Delay Effect and that gives me plenty. So one way or another, this will work.

This is a whole lot of questions I'm asking, so I really appreciate your help with this, guys! I gotta say, HISE is very appealing, because it definitely has some advantages over Kontakt. (And vice versa, of course.) Before diving in, I need to make sure it's capable of doing every thing I'll need, though, which is why I'm asking all these questions.


----------



## José Herring (Mar 18, 2020)

It got so technical that I got lost so forgive me if this has been answered. 

So say you go with HISE, can it then be locked and distributed as a player type instrument or will the end user need a copy of HISE to open your protected samples?


----------



## Mike Greene (Mar 18, 2020)

josejherring said:


> It got so technical that I got lost so forgive me if this has been answered.
> 
> So say you go with HISE, can it then be locked and distributed as a player type instrument or will the end user need a copy of HISE to open your protected samples?


It would be self contained. (The customer doesn't need HISE. The customer won't even know HISE was used in the creation.)

Many people (including me) prefer libraries be released in Kontakt, since it's so easy and reliable. For instruments like Realivox Blue and Hip Hop Creator, though, I think releasing in a self-contained player would actually be an advantage. Many of those customers don't know nothin' about Kontakt (they ain't VI-Control people), so many are confused and annoyed that they have to load _two_ things (KPlayer and then my library) to make things work.


----------



## d.healey (Mar 18, 2020)

I'm doing a little HISE live stream in a mo. If you want to drop in, come over to my YouTube channel.


----------



## Lindon (Mar 19, 2020)

josejherring said:


> It got so technical that I got lost so forgive me if this has been answered.
> 
> So say you go with HISE, can it then be locked and distributed as a player type instrument or will the end user need a copy of HISE to open your protected samples?


You build your instrument in HISE - just like you would in Kontakt - but then you select an export option and HISE builds you a deliverable that you can send to your user. Export options are:

on Windows - VST2, VST3, AAX, Windows Standalone exe
on MacOS - VST2, VST3, AU, AAX, Stand Alone Mac App

You can also build for deployment on iOS(iphone or iPad)


----------



## Mike Greene (Mar 19, 2020)

Lindon said:


> You can also build for deployment on iOS(iphone or iPad)


Say what??? That could be pretty useful, since we do get requests for that pretty often.


----------



## Mike Greene (Mar 19, 2020)

I have one last question - One of the main reasons for me doing this is that for my wordbuilder instrument, I want to give the user the ability to type phrases directly from their QWERTY keyboard. (Which Kontakt doesn't allow.)

I have an English pronunciation dictionary database (yes, it's legal - boy, that was a challenge!), so I want to give the user the option to type in English, rather than phonetically. So my instrument will look at each word the user types, then scan my database and hopefully find a match, and use the associated pronunciation/phonetics for that word.

David told me previously that this would be possible using a JSON file. I have some familiarity with those from some Python coding that I've done, although an English pronunciation dictionary would be waaaayyyy bigger than anything I've ever done before. So my question is - is there a size limit to how big a JSON file can be, and still be totally accessible to HISE?

Assuming size isn't an issue, is there anything I need to be careful of, regarding formatting of a JSON file for this? Here is a JSON file from a Python script I made:

```
{"Window Size": "1201", "initial frequency": "87", "vowelFolder": "/Users/AAA/Desktop/SpliceFolder"}
```

That file has all the tuples on one line. For something as large as a dictionary, that will obviously be a mess, so is it okay to put each tuple on its own line, like this? (Forgive the newbieness of that question.)

```
{"Window Size": "1201",
"initial frequency": "87",
"vowelFolder": "/Users/AAA/Desktop/SpliceFolder"}
```

Also, the dictionary I'm using lists pronunciations like this:
DUCK: D UH K

So could the JSON file look like this? {"DUCK": "D UH K"}

Or does each of those vowels and consonants need to be an individual element? Like this: {"DUCK": "D": "UH", "K"}

Or another option is that I could assign a number to each vowel/consonant, then combine them into one big number, like this: {"DUCK": "120487"}

{I realize this is getting pretty far into the weeds, and I may be pushing the bounds of "free advice." So I understand if this beyond what anyone gets into.)


----------



## d.healey (Mar 19, 2020)

I'm not sure if there is a size limit imposed by HISE, we'd need @chrisboy to jump in and let us know.

With JSON just be careful to format it correctly. If you miss a quotation mark, comma, colon, etc. then it won't work when you load it into HISE and you probably won't get an error message which will be confusing.

Depending on the text editor you use for your JSON (I use CudaText) you might be able to install a JSON linter which will automatically validate the JSON. Or you can paste it into a site like this one.

The JSON can be written across multiple lines, I do this all the time, makes it much easier to read. I was using external JSON files in my livestream yesterday, video's still on YouTube 

There are a few ways to format DUCK. I'd probably use an array, like this:

{"DUCK": ["D", "UH", "K"]}

Then you can access each part by its index.

JSON can contain a mix of object, array, character, string, and numbers, as long as it's all contained in one overall object.


----------



## chrisboy (Mar 20, 2020)

The JSON import should be fine though, I am just using the default JUCE JSON parser implementation which is about as fast as you can get for parsing any data format and I know some developers use a copy protection scheme where they load about ten thousand license keys as JSON file; whether this is a sane approach is another question 

The real question is how to format the JSON so that the parser has to do as little as possible (because a dictionary with let's say 50.000 words is not trivial), and I would go for a whitespace separated string as value like this:

{
"DUCK": "D UH CK",
//...
}

the array approach that David mentioned might look cleaner, but parsing these arrays might turn out to be the bottleneck if you have tens of thousands of them (not that there is a hard limit but it might result in your plugin taking 3-4 seconds longer to load). 

You can later still get an array just by calling commaSeperatedString.split(" "), but this way you defer the array parsing to the latest possible moment.


----------



## Mike Greene (Mar 20, 2020)

Thanks Chris. There are indeed tens of thousands of them, and I can see how parsing a file that big could be time consuming, so I'll start with your "D UH K" approach. (Actually, I'll start with just 10 words and troubleshoot that, before I start formatting 50,000 entries for a script I haven't even written yet.  )

That's the last of my preliminary "deal-breaker" questions, so I think this will work, so it's time to start diving in.

Thanks guys!


----------



## chrisboy (Mar 20, 2020)

Just made some quick test and parsing a complex JSON with about 20.000 items takes 1-2ms so performance is less an issue than I thought


----------



## Ross Sampson (Jun 12, 2020)

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.


----------



## d.healey (Jun 12, 2020)

Ross Sampson said:


> 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.


----------



## Ross Sampson (Jun 12, 2020)

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?


----------



## Ross Sampson (Jun 12, 2020)

d.healey said:


> (and perhaps named after Linus Torvalds  the guy who wrote/writes the Linux Kernel).



Ha


----------



## d.healey (Jun 12, 2020)

Ross Sampson said:


> 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.


----------



## Mike Greene (Jun 12, 2020)

Ross Sampson said:


> 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?
> 
> ...


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. 

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.


----------



## Mike Greene (Jun 12, 2020)

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: VST SDK
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


----------



## d.healey (Jun 12, 2020)

Mike Greene said:


> 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.






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 https://github.com/davidhealey/HISE/tree/develop (my fork) 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.


----------



## Mike Greene (Jun 12, 2020)

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.


----------



## marclawsonmusic (Jun 12, 2020)

For those who are interested in licensing / product keys, you might want to check out LicenseSpring.






LicenseSpring: Software Licensing Cloud


Reliable, cross-platform, platform for licensing your software. Used in large deployments and standalone applications alike. Open your account today!




www.licensespring.com





I use this for OmniTag and it has been great. They have a free tier too.


----------



## chrisboy (Jun 12, 2020)

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.


----------



## chrisboy (Jun 12, 2020)

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


----------



## Ross Sampson (Jun 12, 2020)

chrisboy said:


> 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.
> 
> ...



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?


----------



## Mike Greene (Jun 13, 2020)

chrisboy said:


> 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.


----------



## chrisboy (Jun 15, 2020)

> 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.


----------



## Light and Sound (Jun 15, 2020)

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.


----------



## d.healey (Jun 15, 2020)

Light and Sound said:


> I recently added equal power looping (~6 lines of code).


Cool! Is this in a public fork?


----------



## Light and Sound (Jun 15, 2020)

d.healey said:


> Cool! Is this in a public fork?


All private at the moment as it's still in development (and may be kept private), but I pm'd you


----------



## Lindon (Jun 17, 2020)

Mike Greene said:


> 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.
> 
> ..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))))


----------



## Mike Greene (Jun 17, 2020)

Lindon said:


> 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.


----------



## Lindon (Jun 18, 2020)

Mike Greene said:


> 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.


----------



## EvilDragon (Jun 18, 2020)

d.healey said:


> 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 (Jun 18, 2020)

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 (Jun 18, 2020)

Dewdman42 said:


> 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 (Jun 18, 2020)

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 (Jul 18, 2020)

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 (Jul 18, 2020)

Mark Schmieder said:


> but it looks like HISE will be open source,


Well it has been for the last 5 years 



> 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 (Jul 18, 2020)

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 (Jul 19, 2020)

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.


----------



## ashh (Aug 12, 2020)

Ah @d.healey, you are a Yorkshire man. How that warms my heart. If I have misplaced you then please don't burst my bubble.


----------



## Lindon (Aug 12, 2020)

ashh said:


> Ah @d.healey, you are a Yorkshire man. How that warms my heart. If I have misplaced you then please don't burst my bubble.


...he's not the only one from Yorkshire either...


----------



## Andrew Aversa (Sep 1, 2020)

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.



HISE | Docs



The ScriptNode manual page is missing:



HISE | Docs



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.



HISE | Docs



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. 



HISE | Docs



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



HISE | Docs



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.


----------



## Mike Greene (Sep 1, 2020)

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 (Sep 1, 2020)

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


----------



## AlexRuger (Aug 24, 2021)

chrisboy said:


> 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. (Aug 26, 2021)

AlexRuger said:


> 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".


----------



## d.healey (Aug 26, 2021)

MartinH. said:


> "contact us for a quote".


Send Christoph a message. From what I understand the license is based on company size/income and is tailored for each developer.


----------



## Fredeke (Dec 12, 2021)

Mike Greene said:


> 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.


----------



## Lindon (Feb 9, 2022)

Well this hasn't been updated in a while so I'll add a few of the new things in HISE:

- Probably of most interest - the ability to allow the end user to add their own sounds to your instrument - drag and drop a wav file , set loop points and cross fades etc. all in your instrument interface.
- Send effects now implemented using an unlimited number of send busses
- pre and post preset load callbacks - if you've done presets in V1 of your product and want to make them work in V2 then you know why you might end up needing these
- reworked HISE UI: its taken me a while to like any of it (I'm an old fuddy duddy really) but there are good things in here 
- extended and enhanced scriptnode - more nodes, better display of nodes etc. etc. suffice to say it had power before now its getting *serious*
- Extended Look And Feel - so once you could set look and feel(vector based drawing usually) for a class of widgets - now you can target individual widgets...this just made vector based UI's way easier to implement
- the arrival of 3rd party "support" products - Whilst not a HISE feature per se - they tend to be built in HISE, and knowing he probably wouldn't mention it himself the most important being a standalone download, validate and install app (think Native Access) for your products and expansions. So yes you can ship a product - have it download and install seamlessly(into arbitrary places with any set of files, dlls, json, txt files anything you want really) and then sell expansions to go in your product too..all built in HISE and license able by someone who hangs about here a bit....(its not me).

I'm sure there's lots more .....I'll add to the list if I think of any


----------



## pulsedownloader (Feb 10, 2022)

Nice to see HISE getting more updates.

Pulse also now integrates with any HISE product to automatically generate the "link" file (located at {USER}/AppData/{PublisherName}/{VstName}/LinkWindows or {User}/Library/Application Support/{PublisherName}/{VstName}/LinkOSX) so that customers don't have to locate the .ch1 samples files when they first open their plugin.

I know a few companies mentioned the "link" process was one of the reasons they didn't use HISE in the end.


----------



## JEPA (Feb 12, 2022)

Lindon said:


> Well this hasn't been updated in a while so I'll add a few of the new things in HISE:
> 
> - Probably of most interest - the ability to allow the end user to add their own sounds to your instrument - drag and drop a wav file , set loop points and cross fades etc. all in your instrument interface.
> - Send effects now implemented using an unlimited number of send busses
> ...


Hello Lindon, are you referencing the last release of HISE Nov 2018? I could only find this:


----------



## pulsedownloader (Feb 12, 2022)

JEPA said:


> Hello Lindon, are you referencing the last release of HISE Nov 2018? I could only find this:


You can find more commits to the codebase here









Commits · christophhart/HISE


The open source framework for sample based instruments - Commits · christophhart/HISE




github.com


----------



## d.healey (Feb 12, 2022)

JEPA said:


> Hello Lindon, are you referencing the last release of HISE Nov 2018? I could only find this:


Ignore the releases, they are ancient. The version to use is usually the develop branch but you can view all the branches and pick the one that is most up to date to build from. If in doubt of which branch to use, ask on the forum.


----------



## JEPA (Feb 12, 2022)

Thank you @pulsedownloader and @d.healey for the advices!


----------



## Mike Greene (Feb 12, 2022)

d.healey said:


> Ignore the releases, they are ancient. The version to use is usually the develop branch but you can view all the branches and pick the one that is most up to date to build from. If in doubt of which branch to use, ask on the forum.


It sounds like the situation is the same as it was almost two years ago when I started this thread. HISE is certainly a great platform, and I really wish I could have made it work, but all this talk of GitHub branches, plus the underlying requirements of installing Intel Performance Somethingorother and all the other things I couldn't get working is where you're going to lose the majority of potential developers. Evidence of which is that even now, very few people are using HISE.

HISE could easily get a bunch of Kontakt developers to jump ship, if for no other reason than we could actually have real copy protection. Or use our qwerty keyboard to type in letters. Or all sorts of things Kontakt simply can't do. (Developers are definitely grumbling.)

Heck, _I_ was hoping HISE would be my ticket out. But it got to a point where I realized that if have to put _that_ much effort into getting it working, I'd rather just go ahead and put a little more effort (and money) into creating a platform of my own. With the added reward that I could have full ownership and control. (I'm not making my own player, but that was my situation.)

The way HISE is currently set up, it's not simple enough to attract Kontakt developers with low to mid-level coding abilities, yet the developers with higher level abilities (or resources to hire them) will more likely spend a little more and create own their player.

I'm not saying all this to slam HISE, I'm saying all this to hopefully encourage Chris or whoever is running things to treat this more like a business, as opposed to after-school computer club. For starters, the latest build on the main page shouldn't be from November 2018.


----------



## d.healey (Feb 12, 2022)

*TL;DR *If you're a Kontakt developer thinking about switching to HISE and you have limited knowledge of writing software applications then you're in for an adventure. Adjust your expectations, HISE is almost nothing like Kontakt. Be prepared for learning a whole set of new skills that are necessary to write real software applications and not just writing scripts that run inside another piece of software.


I've suggested a business model that is similar to Ardour's. Where the source code remains free but if you want pre-built, up to date binaries, then you pay a small fee. This is in addition to the licensing side of the business. I don't know if Christoph will go this route but I think it would be a good approach to generate additional income and allow beginners to play around with HISE to get a feel for it.

Even if you use a prebuilt binary though you are still going to need to setup compilers and a build environment on each OS to be able to export your project. This isn't a limitation of HISE, its the reality of developing software applications (as opposed to writing a script that runs inside another piece of software, like a KSP script).

When you "export" a project from HISE you are not actually exporting your project from HISE  What happens is HISE will generate a JUCE project for you, containing all of the stuff needed to build. Then you compile this with the compiler of choice for your OS (Xcode, VS, makefile, etc.).

The same is true for any C/C++ application, it has to be compiled using a compiler. Generally that means a separate build environment for each OS. HISE makes it much easier than writing a C/C++ program from scratch or even building one with JUCE, but it can never be as convenient as running a script inside an existing application like Kontakt or a web browser (Electron).

The source code for HISE is available on github. You don't need to know anything about git or github to build or use HISE, you just go to the link and click download. But the experience will be better for you if you understand what git and github are and then you'll be in control of what you're doing. It doesn't take long to get a handle on these things, there is plenty of documentation.

If you aren't using git and you are a software developer (including a KSP scripter) then you're missing out. git is a version control tool, it's very easy to use and makes life more pleasant when managing different versions of your source code. Instead of having to keep multiple copies of files with different names, you just "commit" your changes with git and it remembers it for you. If you ever need to go back to a previous version you just click a button (or type a command) and you're there. If you want to share your code with others you can put it on github, or bitbucket, or gitlab, or sourceforge, or any other public git server.

I have made this offer several times, and quite a few people have taken me up on it - if you are struggling to get your build environment set up, let me know and I'll get in a video chat with you and get you up and running. It won't take long and you'll see how easy it is (barring the IPP crap, but that's Intel's fault because they keep changing the paths!).


----------



## Mike Greene (Feb 12, 2022)

I hear you, and that makes sense ... in the model as it's currently set up. 

I'm a cocky bastard, though, so if you'll indulge me, here's what I would do if I owned HISE (and if Chris is interested in selling...) - First, of course, would be easy download links right at the top of the main page, along with videos showing how to make a quick instrument. (This part is Software Business 101.)

We would essentially have a Kontakt Full equivalent. For free, since this isn't the moneymaking part. (At least not yet.) This is "attract some users" part. Nobody's going to uninstall Kontakt or Falcon because of this, of course, but "free sampler" will get some attention. I would also include some free content, so people can start playing right away and the HISE universe starts to become a real thing. (Forum post: _"Are there any cheap clarinets?"_ Answer: _"There's a free one on HISE!"_)

I mentioned this a couple pages back, but I would also work out a license deal with some effects developers to include their effects. (If it costs me money upfront, so be it. This is a long game.) Kontakt's effects have some weaknesses (guitar effects come to mind), so offering better options is a golden opportunity. Effects developers could even work ala carte deals for developers to include in their instruments. For example, IK Multimedia might charge a $5 per copy royalty for a stripped down version of Amplitube to include in a Realitone guitar library.

Okay, so now, all we have is a free (for now) alternative to the full version of Kontakt. That part is easy, but as David correctly pointed out, a developer who wants to take advantage of the real power of HISE and release a legit library with their own branding will need to do all those pesky things I hate.

But ... why? Why do _they_ have to do that? Why not have a guy on staff at HISE Headquarters who does that for them? Like what NI does when I send libraries to them? So guys like me with aging brains won't have to learn IPP and XCode and all those JUCE apps. We just make our library, send it to Team HISE with a check for $5k and voila!

Obviously there are numerous limitations to this, and certain instruments would need the full Intel IPP and all that stuff. But for 90% of Kontakt developers, this model would be just fine.

Possibly the best part - Kontakt is very closed. We can't add outside effects. Or our own copy protection. Or all sorts of things. So there are no third party opportunities. But with HISE, after it picks up momentum, clever (business savvy) coders can write copy protection additions, or effects, or fancy graphics packages, or whatever else they can sell to sample library developers.


----------



## d.healey (Feb 12, 2022)

I believe Christoph has plans for a HISE player that would allow you to export a project from HISE and run it in a pre-built plugin. Most of the infrastructure is already available for this in HISE but there is more work to do to make it happen.



Mike Greene said:


> But ... why? Why do _they_ have to do that? Why not have a guy on staff at HISE Headquarters who does that for them?


This also has been discussed. I don't even think it would require a human to be involved (much) as it could fairly easily be automated. But definitely a good way to make a bit of extra income. Offering extras like building installers would also be nice.

If Christoph wasn't interested in this I'm sure someone else could offer the service if there was enough demand.


----------



## JEPA (Feb 12, 2022)

I think I understand @Mike Greene right into that maybe it feels frustating seeing such powerful alternative to Kontakt not being "business" standardized and ready to go. I remember how VCV-Rack started and I think they are also open source, but decided quite well a business model for third parties. This model could perhaps serve as model for HISE? I followed them from the beginning and they are now in version 2.0 "commercial".





VCV Rack 2 - Virtual Eurorack Studio


VCV Rack - Virtual Eurorack Studio. Free download




vcvrack.com




as Mike said, first page "get Rack2" boom: https://vcvrack.com/Rack#get


----------



## pulsedownloader (Feb 12, 2022)

I think Christoph will also find there are plenty of companies who are willing to invest time/money in the platform however possible in order to see it succeed (Pulse included).


----------



## Lindon (Feb 13, 2022)

Ok some comments:

Mike said:



> Heck, _I_ was hoping HISE would be my ticket out. But it got to a point where I realized that if have to put _that_ much effort into getting it working, I'd rather just go ahead put a little more effort (and money) into creating a platform of my own. With the added reward that I could have full ownership and control. (I'm not making my own player, but that was my situation.)


I think this is likely an underestimation of the effort in "creating a platform of my own" - several large scale sample houses have gone this path, and to my knowledge they are spending in the region of 100s of thousands each year in the development of products (at least one I know has spent past $300K) that are not as advanced as HISE and generate a large quantity of grumbles from customers right here in these forums...pretty much building *anything* in HISE is cheaper than building your own platform and then building products on top of it. Maybe you have the deep pockets Mike, if so more power to you.

Oh by the way if you think getting HISE up and running is difficult wait until you are back at the base metal of C++/JUCE, where you'll have to do every single thing you need to do to make a HISE-based product and then some...but as I say some have gone that route.

Mike also says:


> Why not have a guy on staff at HISE Headquarters who does that for them? Like what NI does when I send libraries to them? So guys like me with aging brains won't have to learn IPP and XCode and all those JUCE apps. We just make our library, send it to Team HISE with a check for $5k and voila!


Hello have we met? I've done a truck load of this sort of thing.. people send me their Kontakt instruments and I make HISE versions for them. So far the only problem child (I admit) was Mikes "ladies" vocal instrument, every one else has a shipping product. I think its unrealistic to suggest there would be some "simple" automated porting mechanism for Kontakt->HISE, and its not reasonable I think to compare such a process with Kontakt-> Kontakt Player as done by NI (for their outrageous $10K) where nearly everything is exactly the same (especially the code). But of course if you are at the point of having your product in your copy of HISE and just want it compiling - thats trivial to automate...just one question - how did you get a compiled version of HISE? Oh yeah I send you that too...so yeah Want HISE for your platform - and then want me to compile the end result for you? Sure easy to do.


----------



## Lindon (Feb 13, 2022)

-- I tell you what (thinking about it whilst making lunch..) You tell me what version of HISE you want (MacOS/Windows and StandAlone/plugin) and I'll send it to you - for a very reasonable fee. I'll even throw in some getting started - online chat time...


----------



## JEPA (Feb 13, 2022)

I could think if HISE turns automated, ready to go for non coders, would it turn like Kontakt closed source business? Maybe that is the difference? It implies a lot of work, investment and maintenance!? Am speaking out of my ignorance, and excuse me in advance (am learning of all of this), comparing for example Ardour vs Mixbus, or PureData vs Max? Am very interested in HISE and following it for years, but only now (as a musician) I've learned a little bit programming and got the skills to try it.


----------



## d.healey (Feb 13, 2022)

JEPA said:


> I could think if HISE turns automated, ready to go for non coders, would it turn like Kontakt closed source business?


If a HISE player does materialize, which will lower the barrier to entry (it isn't that high to begin with), you will still need to know what you're doing in order to build instruments. You will also be missing out on other things HISE can be used for, like making effects plugins and DSP protoyping.

A HISE player would be a shell plugin that runs libraries exported from HISE. It wouldn't have much effect on the business model. If you wanted your library to be proprietary you'd pay a license fee, just as you do currently with HISE.

If your goal is to create a virtual instrument without having the skills (or the time/willingness to learn the skills) to create software why would you choose to use HISE when you could just use Kontakt or SFZ or Decent Sampler?

I don't know how to lay bricks. I have no desire to attempt building a garden wall. However, if such a desire arose I would start by learning how to lay bricks. I wouldn't go to a builder's yard and say, "but lego is easy, why can't your house bricks work like lego bricks?" If I wanted the end result without the work I'd hire a builder.


----------



## JEPA (Feb 13, 2022)

d.healey said:


> If a HISE player does materialize, which will lower the barrier to entry (it isn't that high to begin with), you will still need to know what you're doing in order to build instruments. You will also be missing out on other things HISE can be used for, like making effects plugins and DSP protoyping.
> 
> If your goal is to create a virtual instrument without having the skills (or the time/willingness to learn the skills) to create software why would you choose to use HISE when you could just use Kontakt or SFZ or Decent Sampler?
> 
> I don't know how to lay bricks. I have no desire to attempt building a garden wall. However, if such a desire arose I would start by learning how to lay bricks. I wouldn't go to a builder's yard and say, "but lego is easy, why can't your house bricks work like lego bricks?" If I wanted the end result without the work I'd hire a builder.


Thanks for responding! I haven't said any of that. I do want/am willing of learning every thing , but I am making analogies to understand the situation of HISE reading out all the posts in this thread. I am trying to interpret the posts of Mike, and yours (Christoph, Lindon and David) responses to make a picture of the situation, so I can understand where is HISE and what I need to get to work with it. I have learned bit of Phyton, Lua, KSP (I have bought your tutorials at Xtant), but my profession is Music, Music Production, Audio Editing and Musicology. So this thread is interesting for me and us willing to develop virtual instruments, and looking for alternatives to Kontakt.
My goal isn't to create virtual instruments while I sleep , instead I want to learn to have the skills to create software, and we are investing already more than two years in aqcuiring the knowledge plus creating our first library. We (my son and me) are going to release a Virtual Instrument soon, based on Kontakt platform, obviously, first step. And I am looking for alternatives, like many others. And because we, me, are new in the business I am trying to understand and interpret this whole picture of HISE, with great respect. So again, excuse me in advance for my ignorance when I ask something, but that is the reason I am asking with the "?" question marks. (And my native language is spanish, so one more barrier I have to outcome to communicate well in english).
Yes, I would hire a builder if I had the financial means, or learn it bymyself. I want to learn it by myself first. That's because am here commenting/asking! If my interpretations are not right I would be thankful for correction and excuse me for miss interpretation!

So, for my understanding:
- HISE is open source
- To get to use/install HISE lot of steps commented in this thread, but go to the offical website and Github pages
- To learn HISE look at the documentation, threads, forums, and your Tutorials. (are your @d.healey tutorials free or are you selling also some with deeper content? If so I would be interested)
- To release a Virtual Instrument, build it your self as you did with the installation of HISE and...
- To release commercially there is an agreement with Christoph (creator) via email for the license

right or not? Thanks in advance!
Jorge


----------



## d.healey (Feb 13, 2022)

JEPA said:


> I haven't said any of that.


Sorry, I wasn't directing all that towards you specifically, I was speaking more generally. I quoted you only for the bit about the HISE player idea and business model.



JEPA said:


> - HISE is open source


Yes, HISE is open source but the applications you create with it don't have to be.



JEPA said:


> - To get to use/install HISE lot of steps commented in this thread, but go to the offical website and Github pages


To get the latest version of HISE you need to go to github, download the source code, and compile it.



JEPA said:


> - To learn HISE look at the documentation, threads, forums, and your Tutorials. (are your @d.healey tutorials free or are you selling also some with deeper content? If so I would be interested)


All those places are great for getting info about working with HISE. The documentation is especially helpful but not always up to date with all the latest features and doesn't always contain all of the details you need for a specific project.

My tutorials are first posted to my Patreon page and then after a month or more they go public on YouTube and Odysee. Some videos are Patreon exclusive though and don't go public, I also post little snippets and articles to Patreon as well. I would like to make a more in depth premium course for beginners (similar to my KSP ones) but I haven't had the time to do it yet.



JEPA said:


> - To release a Virtual Instrument, build it your self as you did with the installation of HISE and...


Yes, to get turn your HISE project into a standalone application or plugin you need to compile it. Almost exactly the same process as building HISE.



JEPA said:


> To release commercially there is an agreement with Christoph (creator) via email for the license


No. To release a proprietary (closed source) application you need to have a license agreement with Christoph. This is true whether or not you charge people for copies. If you are giving it away for $0 but it's proprietary then you still need a license.

If your application is released under the GNU GPL license and the samples are released under a suitable license then you don't need a commercial license in order to distribute your application.


----------



## JEPA (Feb 13, 2022)

d.healey said:


> No. To release a proprietary (closed source) application you need to have a license agreement with Christoph. This is true whether or not you charge people for copies. If you are giving it away for $0 but it's proprietary then you still need a license.
> 
> If your application is released under the GNU GPL license and the samples are released under a suitable license then you don't need a commercial license in order to distribute your application.


Thanks for the clarification!! We will go to your Patreon for sure!


----------



## d.healey (Feb 13, 2022)

JEPA said:


> Thanks for the clarification!! We will go to your Patreon for sure!


And if you need any help building just let me know and we can get in a call.


----------



## Mike Greene (Feb 14, 2022)

Lindon said:


> Hello have we met? I've done a truck load of this sort of thing.. people send me their Kontakt instruments and I make HISE versions for them. So far the only problem child (I admit) was Mikes "ladies" vocal instrument, every one else has a shipping product. I think its unrealistic to suggest there would be some "simple" automated porting mechanism for Kontakt->HISE, and its not reasonable I think to compare such a process with Kontakt-> Kontakt Player as done by NI (for their outrageous $10K) where nearly everything is exactly the same (especially the code). But of course if you are at the point of having your product in your copy of HISE and just want it compiling - thats trivial to automate...just one question - how did you get a compiled version of HISE? Oh yeah I send you that too...so yeah Want HISE for your platform - and then want me to compile the end result for you? Sure easy to do.




Absolutely, this solution exists, and handing off parts of the process to you will indeed be successful. Even with Realivox, where the problems centered around my inflexibilities, not issues with HISE.

But HISE needs to be in a position where people are using it successfully _without_ needing to read threads on VI-Control to learn the workarounds for the substantial obstacles. _"There's a guy on VI-Control who can send you a binary so you can get started"_ is an absurd way to run a business.

The entirety of this process, even with the option of hiring you to help, isn't how most developers want to do things. It just isn't, and the proof is right there in the fact that HISE has been around for years now, yet still hasn't caught fire.

Which raises another issue - trust that the platform will continue to exist. I'm guessing Christoph makes very little money from HISE. I wouldn't even be surprised if he has another full time gig that pays his bills. That's not a good situation for longevity.

We can be sure Kontakt will be around for a long time, because the profit motivation is there. Even in smaller situations, if Doug Rogers dies, OPUS will still continue, because the estate will want to keep those EW dollars rolling in. Sine or the Spitfire Player, they'll stay around. Heck, even if Mike Greene dies, his lazy wife's not gonna let that Realitone gravy train stop rollin', so she'll see to it that someone keeps it going. Love or hate capitalism, it's a motivator.

But if Christoph dies, or more likely, gets bored or disillusioned, HISE would be in serious trouble, because as wonderful as people keep telling me open source is, it's usually just one guy keeping it afloat.

I'm not trying to slam HISE, I'm just illustrating how most developers think and why they're not flocking to a platform that truly does have so many features we want. By now, HISE should have made much more of a impact than it has, but even here, this thread is almost two years old, yet we're still reading the same bandaid solutions to the same problems. Which is fine if HISE is a hobby project (which I suspect it is), but if gaining traction amongst developers is a goal, then there needs to be a fundamental rethink of how it's set up.


----------



## musicsoftwaredeals (Feb 14, 2022)

As HISE is "open source", what's to stop someone just "forking" HISE and making their own commercial version? 

Or is it only the fact that you would no longer get the benefits of future "commits" (additions) from the original developer?


----------



## labyrinths (Feb 14, 2022)

musicsoftwaredeals said:


> As HISE is "open source", what's to stop someone just "forking" HISE and making their own commercial version?
> 
> Or is it only the fact that you would no longer get the benefits of future "commits" (additions) from the original developer?


It's released under the GPL, which is a copyleft license, meaning anything you build with it also has to be open source. It's not permissive in the same way that MIT and Apache open source licenses are, for example. For a closed source product, you'd need to license HISE from the developer, and the JUCE library may need to be licensed as well depending on your annual revenue.


----------



## tack (Feb 14, 2022)

musicsoftwaredeals said:


> As HISE is "open source", what's to stop someone just "forking" HISE and making their own commercial version?


The GPL under which HISE is licensed stops them.


----------



## d.healey (Feb 14, 2022)

tack said:


> The GPL under which HISE is licensed stops them.


This is not true. Commercial means charging money, absolutely allowed under the GNU GPL and encouraged by the FSF. What you are not allowed to do is release it in a proprietary form, aka closed source, whether or not you charge for it.

@Mike Greene you should listen to my interview with Christoph. He talks about his longer term aims regarding HISE.



Because HISE is open source it means it can't just vanish, unlike a proprietary app - anyone remember keymap pro?

Christoph is the main developer of HISE and the maintainer of the upstream source code repo, but he is not the only developer. Look through the github commits and you'll see a lot of commits from me and others. This could never happen with a proprietary app. No matter how much money Kontakt makes, Native Instruments will not let you add features to it.


----------



## labyrinths (Feb 14, 2022)

d.healey said:


> This is not true. Commercial means charging money, absolutely allowed under the GNU GPL and encouraged by the FSF. What you are not allowed to do is release it in a proprietary form, aka closed source, whether or not you charge for it.


I thought the JUCE license might prevent this, but it turns out I just hadn't read far enough! Even the higher revenue tiers still allow releasing your product under GPL as an alternative to licensing fees. I'm more used to seeing one or the other, but that's a particularly good licensing scheme.


----------



## tack (Feb 14, 2022)

d.healey said:


> This is not true. Commercial means charging money, absolutely allowed under the GNU GPL and encouraged by the FSF. What you are not allowed to do is release it in a proprietary form, aka closed source, whether or not you charge for it.


My bad for hastily posting an unnuanced reply. In my own defense, as a developer using the (L)GPL for 25 years, I do actually know this. 

But I do think though this scenario (having a proprietary closed source fork) is what musicsoftwaredeals had in mind, which is why I responded that way.


----------



## EvilDragon (Feb 15, 2022)

Mike Greene said:


> Or use our qwerty keyboard to type in letters.


Ummm but this is possible. Or do you actually mean "parse what you've typed to do something with it"?



Lindon said:


> (for their outrageous $10K)


This heavily depends on number of serials you need and MSRP you're targetting. Blanketing the statement that for any sort of encoded library you require an "outrageous" sum of 10k is disingenous.

I would say the volume+percent based setup is entirely reasonable. Plus, it's not a lump sump you have to pay at once anymore, since for at least a year now split payment is allowed.


----------



## EvilDragon (Feb 15, 2022)

@d.healey Quick question! Can HISE be cross-compiled, or did Chris ever consider to provide this possibility? I reckon that would be quite helpful in order to develop on one machine only (although that machine would probably have to be a Mac, since you can't get Xcode which has all the stuff necessary to build a macOS app to work on any other OS).


----------



## d.healey (Feb 15, 2022)

EvilDragon said:


> @d.healey Quick question! Can HISE be cross-compiled, or did Chris ever consider to provide this possibility? I reckon that would be quite helpful in order to develop on one machine only (although that machine would probably have to be a Mac, since you can't get Xcode which has all the stuff necessary to build a macOS app to work on any other OS).


No as far as I know, and I believe this is down to JUCE rather than a specific limitation of HISE. But you can compile in a virtual machine so only one computer is needed, I use an Intel Mac for this which can also compile Native M1 binaries.


----------



## EvilDragon (Feb 15, 2022)

Not really up to JUCE, I don't think. In Surge synthesizer project we enable crosscompilation through CMake commands and if you have the necessary compiler that supports it.

(That would be another good improvement for HISE - don't rely on Projucer but do CMake instead, or in addition to.)


----------



## Light and Sound (Feb 15, 2022)

EvilDragon said:


> Not really up to JUCE, I don't think. In Surge synthesizer project we enable crosscompilation through CMake commands and if you have the necessary compiler that supports it.
> 
> (That would be another good improvement for HISE - don't rely on Projucer but do CMake instead, or in addition to.)


JUCE has been making a transition over to CMake since I believe 6.0, I imagine they'll push it further as time goes on, but I imagine most devs are using CMake instead anyway for the flexibility.


----------



## Lindon (Feb 15, 2022)

Mike Greene said:


> But HISE needs to be in a position where people are using it successfully _without_ needing to read threads on VI-Control to learn the workarounds for the substantial obstacles. _"There's a guy on VI-Control who can send you a binary so you can get started"_ is an absurd way to run a business.


Of course its absurd, and really I'm not suggesting it as a long term option for HISE. In fact Christoph has a long term view of HISE, but I think it's just not lining up with how you would run the business. 


Mike Greene said:


> The entirety of this process, even with the option of hiring you to help, isn't how most developers want to do things. It just isn't, and the proof is right there in the fact that HISE has been around for years now, yet still hasn't caught fire.


Depends what you mean by "caught fire" there are now literally hundreds of plug-ins built using HISE, gee I've built and shipped over 50 myself...its hard to see its impact/penetration as the final products dont shout "Built using HISE" at you. I understand your definition may be about thousands of developers using HISE, and right now its hundreds. But I think its best to proceed with caution when considering the trajectory of product A (Kontakt) against product B (HISE), especially if you weren't actually there at Kontakt 1.0->Kontakt 3.0. I recall from those days Kontakt NOT being particularly fast on the uptake, sure KSP was really really REALLY limited in those early releases...so that was a handbreak on it.



Mike Greene said:


> Which raises another issue - trust that the platform will continue to exist. I'm guessing Christoph makes very little money from HISE. I wouldn't even be surprised if he has another full time gig that pays his bills. That's not a good situation for longevity.





Mike Greene said:


> We can be sure Kontakt will be around for a long time, because the profit motivation is there. Even in smaller situations, if Doug Rogers dies, OPUS will still continue, because the estate will want to keep those EW dollars rolling in. Sine or the Spitfire Player, they'll stay around. Heck, even if Mike Greene dies, his lazy wife's not gonna let that Realitone gravy train stop rollin', so she'll see to it that someone keeps it going. Love or hate capitalism, it's a motivator.
> 
> But if Christoph dies, or more likely, gets bored or disillusioned, HISE would be in serious trouble, because as wonderful as people keep telling me open source is, it's usually just one guy keeping it afloat.


I'm not sure how to address this - I think its a basic disagreement about the strengths and weaknesses of open source. HISE will be there for ever, it's on GitHUB go get your copy. Kontakt will very likely be there forever - but the one with any (even small) level of doubt is Kontakt and its new venture capitalist owners...it'd be stupid to shut it down sure - but venture capitalists have done sillier things - we only need look as far as Gibson in our own industry for a model of buy a successful products and kill it approach..(a technique they've used more than once if only to convince the rest of us just how clueless they are about anything but guitars...)


Mike Greene said:


> I'm not trying to slam HISE, I'm just illustrating how most developers think and why they're not flocking to a platform that truly does have so many features we want. By now, HISE should have made much more of a impact than it has, but even here, this thread is almost two years old, yet we're still reading the same bandaid solutions to the same problems. Which is fine if HISE is a hobby project (which I suspect it is), but if gaining traction amongst developers is a goal, then there needs to be a fundamental rethink of how it's set up.


Band Aid solutions to problems? You mean problems with the business model? You know I tend to agree with you a lot more than this thread may be reflecting, if I had some influence...etc. But yes you are right its a very small operation and the person (mostly) in charge doesn't seem to see it that way - he sees building better and better functionality as the way forward and wants to spend not so much time on stuff you or I might find interesting, like growing a multi-million dollar business....


----------



## EvilDragon (Feb 15, 2022)

Light and Sound said:


> JUCE has been making a transition over to CMake since I believe 6.0, I imagine they'll push it further as time goes on, but I imagine most devs are using CMake instead anyway for the flexibility.


Yeah that is indeed true. Best things they did with v6 cycle is CMake and accessibility support.


----------



## d.healey (Feb 15, 2022)

EvilDragon said:


> Not really up to JUCE, I don't think. In Surge synthesizer project we enable crosscompilation through CMake commands and if you have the necessary compiler that supports it.


Yup, you're right








Upgrade to JUCE 6 · Issue #171 · christophhart/HISE


Hi guys, can this be upgraded to juce 6?




github.com


----------



## Lindon (Feb 15, 2022)

Mike Greene said:


> But HISE needs to be in a position where people are using it successfully _without_ needing to read threads on VI-Control to learn the workarounds for the substantial obstacles.


Actually there was something here that was nagging at me... and then I just substituted Kontakt for HISE in the sentence....

"But Kontakt needs to be in a position where people are using it successfully _without_ needing to read threads on VI-Control to learn the workarounds for the substantial obstacles. "

--- luckily for all those Kontakt developers theres an entire permanent area in the forum dedicated to doing just this...


----------



## d.healey (Feb 15, 2022)

Lindon said:


> Actually there was something here that was nagging at me... and then I just substituted Kontakt for HISE in the sentence....
> 
> "But Kontakt needs to be in a position where people are using it successfully _without_ needing to read threads on VI-Control to learn the workarounds for the substantial obstacles. "
> 
> --- luckily for all those Kontakt developers theres an entire permanent area in the forum dedicated to doing just this...


This is so true, without the VI-Control forum (and Big Bob and ED) I would have had so much more of a struggle getting going with Kontakt. And without Nils' and his KSP extensions and later Sublime KSP I don't think I could have done nearly as advanced work in Kontakt as I have done.

It's also worth mentioning that there is more official developer documentation for HISE than for Kontakt (even if it's not 100% complete and up to date with the latest features). There is also a ton of additional documentation buried in the HISE forum and in my YouTube videos.


----------



## EvilDragon (Feb 15, 2022)

d.healey said:


> Yup, you're right
> 
> 
> 
> ...


Awww that's a bummer. Oh well.


----------



## chrisboy (Feb 15, 2022)

> Awww that's a bummer. Oh well.


Maybe I'm failing to see why CMake offers a substantial advantage over the Projucer instead of it being a bit more standardized so "real" C++ developers can integrate it in their workflow better.

What did you do in Surge to make cross compilation happen (I thought macOS is too closed for this). With the Projucer you can hook up a build server that spawns off the compilation for each OS to different systems and you get a "one-click -> signed and notarized installer" workflow which is as smooth as it can get.


----------



## Light and Sound (Feb 15, 2022)

chrisboy said:


> Maybe I'm failing to see why CMake offers a substantial advantage over the Projucer instead of it being a bit more standardized so "real" C++ developers can integrate it in their workflow better.


I don't think it's a huge advantage, more just that it's a bit more widespread and (I think) allows for some more build targets that producer misses, although none that I use. Likely just being able to take advantage of the cmake language to add custom functionality to a build (ie get the latest versions of sub repos before beginning builds), eliminating the need for any 'true' prerequisites (license pertaining ofc)


----------



## chrisboy (Feb 15, 2022)

> eliminating the need for any 'true' prerequisites



Ah ok, I see, but there are a lot of prerequisites anyways (eg. having a HISE build and IPP installed on each build node) anyway, so the build server setup is already a mess and only switching the Projucer won't help too much. Once it works though -> super nice letting robots do the work.




> Which is fine if HISE is a hobby project (which I suspect it is), but if gaining traction amongst developers is a goal, then there needs to be a fundamental rethink of how it's set up.



Lot to unpack here and I'm a bit late to the party, but, nope, HISE isn't a hobby project - it's used by many companies already and products based on it generate a few million of annual revenue and I intend to keep developing it for many more years to come. This would be more obvious if I wouldn't be a complete and total failure in marketing but as Lindon said, I chose to allocate all my available HISE time to development. However I can totally understand how this decision does vastly undervalue the perception of HISE at the current phase and by judging the book by its cover it's totally valid to make the assumptions you did. 

The level of mental gymnastics required to find a valid argument for an HISE installer that was uploaded pre-Covid is super high, but let's try it:



> gaining traction amongst developers is a goal



That's definitely the goal. The question is "How fast" and "what type" of developers do I want to attract at this phase and I have to say I am super happy about the current growth rate as it is right now (slow enough to not being tied down to tech debt while high enough to not feel like nothing is progressing). So even if it looks like total standstill from the outside I can assure you that it isn't (both in what happens on the development part as well as the adaption by other companies).

And the current pool of developers who made it through the "I need to install IPP but look, now I'm a real developer" phase also make my life much easier than people who expect that everything works like in a closed box environment like KONTAKT. Plus the amount of feedback (and cooperation requests) I get is enough to keep me busy (unlike when it was just David and me in the HISE forum and you could hear the crickets), so if I would start scaling up, I would have to outsource development and resort to some kind of project manager role which I know will suck as much as I do in marketing.

The steps that Mike laid out are pretty much the same ideas that we have if we want to steer HISE into a more commercial direction (it's pretty obvious what to do in order to achieve this goal and I appreciate that Mike puts his thought into something that clearly appears to be my problem). It's just that we would be exchanging freedom of development against revenue and more people nagging me and this is not something that I need to do at this point, which is why the "commercialisation" of HISE does move in this ridiculous pace.

So yes, at some point in the future HISE will probably have a free player that attracts KONTAKT folk, but I don't see it as the most important tasks to put my time into (not because it's not effective but because I question the outcome that it will have). Because to be honest - and since my personal finances have been brought up as possible (de)motivation: whenever I want to make money, I'll rather do a cooperation with another company and make an end user product than trying to make the framework itself financially viable (which is close to impossible due to the monopoly of KONTAKT and the nonexisting void of competing frameworks seems to emphasize my point). 

Not because I'm lazy but because I really think that a framework that's only reason of existence is revenue growth has no chance to compete in the current situation which is completely dominated by KONTAKT (and a few emerging proprietary sample players that are out of reach for the majority of people) so there has to be another motive behind it. I really really like to mention JUCE as an example where one guy (Julian Storer) build the foundation of almost the entire audio software industry as we know today and the development was (and still is) hardly self-funding, yet someone has done it and boy did the JUCE website look ugly back in the days


----------



## EvilDragon (Feb 15, 2022)

chrisboy said:


> so the build server setup is already a mess and only switching the Projucer won't help too much.


It would def help since you could automate getting all prereqs (esp if they're available through some sort of a package manager), so when properly set up to build HISE you can do it basically with one line from terminal/cmd/whatev.

So with CMake you can automate everything (including downloading prerequisites - but you can also do this with git submodules - which you should really do for JUCE IMO).


As for what we did in Surge to enable cross-compilation, it's all CMake trickery. I didn't do it personally, but pull requests are out there in the open for everyone to see:

https://github.com/surge-synthesizer/surge/pull/2342
https://github.com/surge-synthesizer/surge/pull/3881
https://github.com/surge-synthesizer/surge/pull/4831
https://github.com/surge-synthesizer/surge/pull/4903
https://github.com/surge-synthesizer/surge/pull/4989
https://github.com/surge-synthesizer/surge/pull/5163




chrisboy said:


> Maybe I'm failing to see why CMake offers a substantial advantage over the Projucer instead of it being a bit more standardized so "real" C++ developers can integrate it in their workflow better.


It's exactly that - the whole C++ world (or at least a great majority of it) seems to converge towards CMake...



chrisboy said:


> With the Projucer you can hook up a build server that spawns off the compilation for each OS to different systems and you get a "one-click -> signed and notarized installer" workflow which is as smooth as it can get.


You can do the same with CMake, from what I can tell. But AFAIK it's a combo of CMake+Azure secrets+some bash the way it's done for Surge.


----------



## Mike Greene (Feb 15, 2022)

Mike Greene said:


> Or use our qwerty keyboard to type in letters.





EvilDragon said:


> Ummm but this is possible. Or do you actually mean "parse what you've typed to do something with it"?


I did mean _"parse what you've typed to do something with it."_ Specifically for a wordbuilder instrument, so the user can type their phrase, then Realivox converts that to phonetics. My understanding is that's not possible.

Please, please tell me I'm wrong!


----------



## EvilDragon (Feb 15, 2022)

You're not wrong, just wanted to clear that up


----------



## Mike Greene (Feb 15, 2022)

chrisboy said:


> Lot to unpack here and I'm a bit late to the party, but, nope, HISE isn't a hobby project - it's used by many companies already and products based on it generate a few million of annual revenue and I intend to keep developing it for many more years to come. This would be more obvious if I wouldn't be a complete and total failure in marketing but as Lindon said, I chose to allocate all my available HISE time to development. However I can totally understand how this decision does vastly undervalue the perception of HISE at the current phase and by judging the book by its cover it's totally valid to make the assumptions you did.
> 
> The level of mental gymnastics required to find a valid argument for an HISE installer that was uploaded pre-Covid is super high, but let's try it:
> 
> ...


Great response. Personally, I'd still go the full greed route (as if I haven't already made that clear ), because HISE is definitely good enough to be a huge player in this game. But I completely respect your vision, since not only is it your company, not mine, but you also know the nuts and bolts much better than I do. Plus, most importantly, you know better what _you_ want out of it all.

With that said, if I may, here are a few suggestions that you could do in a day or two that would make a huge difference:

1. Create a current download on the home page. I would pay David or someone to update that page every month or so.

2. I think you might already have an instrument creation video, but rather than focusing on "fast," I would instead make it more of a simple tutorial, including how to access the most important screens, which is not obvious. (Like this video that I made for myself, although I think there were mistakes in mine.) I would also include a description of the general folder structure. The terminolgy difference for "group/sampler" (that will confuse anyone coming from Kontakt ... which is everybody) or where are scripts stored, or other basics. A general _"Here's where this is, here's where that is"_ will make getting started so much easier.

2b. Pay David to make that video. Or whoever does it, make sure they do it from a perspective of someone who hasn't already mastered HISE.

3. Add a note on the home page that Lindon (or whoever else) can do the compiling or various other tasks, thus eliminating the need for people to install IPP and XCode and ProJucer and all of that other stuff that has nothing to do the actual HISE application.


----------



## d.healey (Feb 15, 2022)

Mike Greene said:


> thus eliminating the need for people to install IPP and XCode and ProJucer and all of that other stuff that has nothing to do the actual HISE application.


You can't get away from it Mike. If you want to develop with HISE you need to setup your own compiler. How else are you going to debug the compiled version of your project? 

Number 2 is already covered quite well in the documentation (detail may be lacking though) - specifically these pages:




__





HISE | Docs






docs.hise.audio








__





HISE | Docs






docs.hise.audio


----------



## EvilDragon (Feb 16, 2022)

Yeah that step 3 is not realistic considering the way HISE works. You're not dealing with just scripting here, so requirements are way different. However, setting all of this up can and should be more straightforward (hence suggestion for CMake support, which could deal with grabbing prerequisites for building "automagically").

Projucer at least comes along with JUCE so it's not a separate install.


----------



## d.healey (Feb 16, 2022)

EvilDragon said:


> Projucer at least comes along with JUCE


A prebuilt binary for each platform is also provided with the HISE source.

I've seem a few mentions now of prerequisites - On Mac and Windows the only things you need to install are xcode or visual studio. You might want to install IPP on Windows but you don't have to, and it's not needed on Mac. What other prerequisites are you guys referring to?


----------



## Lindon (Feb 17, 2022)

EvilDragon said:


> Yeah that step 3 is not realistic considering the way HISE works. {snip}


I'm not actually so sure that's true. Yes you are right there are dependencies - the users graphics, IRs and Samples are all needed. But essentially they are all in the project folder anyway - or running your product in HISE itself wouldn't work. 

Basically you'd create your samples and sample maps (just like Kontakt), load up your graphics (just like Kontakt) and write some HISEScript (a far more pleasant experience than writing KSP) and then send along your entire project folder. At that point if it loads and compiles in HISE on the target system, and the target system is set up correctly - then it should compile and build a standalone or plugin....

Of course all of this assumes you are prepared to work out where everything lives and what its called in HISE, how to build sample maps and load up samples, how to create images that work in HISE(hint - it's EXACTLY like Kontakt), and how to write HISEScript. Some of these are clearly non-trivial but if this is too big a barrier to entry then really really: Stick.To.Kontakt


----------



## d.healey (Feb 17, 2022)

Lindon said:


> I'm not actually so sure that's true.


The problem is that you don't just build a binary for release. You also need to build it for testing and debugging. Unless you're also offering a binary debugging service


----------



## Lindon (Feb 18, 2022)

d.healey said:


> The problem is that you don't just build a binary for release. You also need to build it for testing and debugging. Unless you're also offering a binary debugging service


really ? I hardly ever build a test or debug version once its working correctly in HISE...sure there are times when something shows up in the compiled product - but its rare....


----------



## d.healey (Feb 18, 2022)

Lindon said:


> really ? I hardly ever build a test or debug version once its working correctly in HISE...sure there are times when something shows up in the compiled product - but its rare....


Yes it is rare, but I wouldn't like to be the customer who buys from a developer that can't debug their own problems. 

Here is one example that happened to me recently.

Everything working beautifully in HISE. But running a standalone build I got an instant crash whenever I did something that opened a dialog. Running a debug build revealed an error caused by one of my LAF functions (ultimately caused by a bug in HISE). This would have been impossible to track down without being able to compile a debug build.

Sometimes a single debug build is enough to solve an issue, but other times it requires multiple iterations as you try to eliminate the cause of a problem.


----------



## Lindon (Feb 18, 2022)

d.healey said:


> Yes it is rare, but I wouldn't like to be the customer who buys from a developer that can't debug their own problems.
> 
> Here is one example that happened to me recently.
> 
> ...


Hmm, I think we are at cross purposes....I'm not proposing in this scenario that its a customer/developer relationship... YOU develop (in HISE) and someone(me in this theoretical example) will compile it for you. And we are ONLY looking at if this is possible - not advisable (in all cases). All I'm saying here is yes its possible... sure there are going to be times where it all falls in a heap - but 95% of the time it will work fine...how you deal with outliers in this scenario is another discussion I think. How do NI deal with it do you think? Where someone sends them a (badly) coded Kontakt instrument and it fails to make it into KPlayer?


----------



## EvilDragon (Feb 18, 2022)

NI has a QA process for each Player library these days (actually for at least 3-4 years IIRC, maybe even more), and apart from general checkup on implementation of NKS they also will note if things are behaving weirdly or in an unexpected way. There's a back and forth process to ensure a decent release.


----------



## modularsamples (Feb 22, 2022)

If I can build HISE from source (not a programmer by any stretch, or even logically minded) anyone who's reasonably technically proficient can. It's really is a refreshing environment to work in, worth the effort IMO.


----------



## d.healey (Apr 9, 2022)

I think Mike had the right idea when he suggested a video aimed at the HISE curious. So I've created an Introduction to HISE video in which I attempt to give an overview of HISE.


----------



## JEPA (Apr 9, 2022)

d.healey said:


> I think Mike had the right idea when he suggested a video aimed at the HISE curious. So I've created an Introduction to HISE video in which I attempt to give an overview of HISE.



Thank your for your awesome description of this impressive program!


----------



## d.healey (May 12, 2022)

Nice article about HISE









Create Your Own Plugins And Sample Libraries | Production Expert


Plugin development is a tough task, something that many of us have often dreamt about but considered too difficult even to think about. But what if I told you that you can do it without too much effort with a free, open source tool which is straightforward to use?




www.pro-tools-expert.com


----------



## Lindon (Sep 10, 2022)

OK so another 6 months has gone by since my last update on HISE functionality, so I thought it would be time to update everyone...here we go: there's been many many hundreds of changes (bug fixes and additions) but here are what most of us HISErs seem to think are the most important;


MIDI out - so you can make MIDI only plugins now...
More LAF. So additional control over existing widgets, things like the ability to control the colour and size of drag-dots in tables, the ability to set colours, backgrounds, fonts and drawn elements in drop-down selector combo-boxes...
OS file management....so more stuff like file moving, deleting, copying
Zip file extraction - the ability to extract a zip file to a named directory, useful if you are building your own installer in HISE - as I did.
Linkwitz Riley filters & a set of templates (for multi band effects..) - so this is a filter type that has a major property - it doesn't introduce phasing effects when used in parallel with others of its kin. So now you can make multiband effects - unlimited bands (tho I'm sticking to 4 band right now)...
Sampler-data based granulator.. so the granulator uses either a single file (loadable) or any of the existing sample maps (groups to you KSP people) - so you can make a granular player based on your existing shipping sample set.
Audio Drag-and-Drop (HISE rendering -> DAW) - so if you have a MIDI file playing you can point it at a sound source (Sampler, synth, whatever) and build an audio file that you can drag to your DAW. So if say you have a drum machine you can drag a rendered version of your pattern to the DAW - or just one track of your pattern - you get the idea I think.
Error Handler - a simplified way to capture errors and display message boxes to the end user.
Build M1 native/universal audio plugins - HISE still runs itself under Rosetta but the things it builds on macs (with XCode 13.1+) are universal binaries that run on any Mac.
Broadcaster - an easy way to get a call when an event happens - so the Observer pattern if you are into the correct architectural name - this improves the structure a LOT in complex projects.
Improved library support: Include third party C++ DSP algorithms as node with a template that demonstrates the API. So now if you have 3rd-party stuff you want to add to HISE - you can.
hardcoded FX modules: load compiled scriptnode networks as native C++ DSP modules - so this is about speed but you also got ScriptNode FX Slots so now you can dynamically load your in-house built effects into effect slots.
As I say there's been a lot of tweaks and fixes and generally it continues to evolve at pace...


----------



## Lindon (Sep 13, 2022)

Another day another (set of)feature(s) in HISE. Now we have:
13. OSC(Open Sound Control) - if you dont know what it is try googling...or read this:





Open Sound Control - Wikipedia







en.wikipedia.org




14. Fast Math Approximations. Math.tanh() not working for you? Try the fast math approximations...
15. Regex improvements - did I not mention you can use regex? Well its better now than it was...what is it I hear some of you ask - its pattern matching:








Regular expression - Wikipedia







en.wikipedia.org


----------



## d.healey (Sep 15, 2022)

16. Lambda functions with local variable pass-through.


----------



## d.healey (Oct 12, 2022)

Today we have FAUST integration (effects only for now with polyphony, MIDI, and sound generators on the way).



GSoC: Final Submission – ResonantBytes


----------



## JEPA (Oct 13, 2022)

d.healey said:


> Today we have FAUST integration (effects only for now with polyphony, MIDI, and sound generators on the way).
> 
> 
> 
> GSoC: Final Submission – ResonantBytes


Woah! My prof. at the university showed me FAUST some years ago! I understood that audio processing with FAUST is very very fast, isn't it?


----------



## d.healey (Oct 13, 2022)

JEPA said:


> Woah! My prof. at the university showed me FAUST some years ago! I understood that audio processing with FAUST is very very fast, isn't it?


I haven't played around with FAUST for a couple of years but it was fast enough to run real-time in a web browser, so I think it's plenty fast.


----------

