Thank you Christoph
-
@d-healey Really? I think KSP docs are solid. In fact I don't think it's even close. The Kontakt edit mode is documented in a different document but is not that complex and you can make sense of it rather quickly. It's a few modulators, each with a table and an intensity slider. Yeah, sure, HISE is orders of magnitude more complex, but the docs should follow along.
I only got on board with Kontakt and KSP in 2017, and the docs were a 250pg+ searchable PDF that was perfectly indexed and rather light so navigating was a breeze. Took a bit to learn where's what, but then it was pretty simple as nearly every single command or functionality comes with an example.
Then, in 2019 or so they published this page https://www.native-instruments.com/ni-tech-manuals/ksp-manual/en/welcome-to-ksp
which is basically the same, but with great search functionality, much faster navigation and is always kept up to date. For nearly anything you're not sure about, there's an example.
The only thing that still baffles me is that they haven't folded SublimeKSP under the official KSP umbrella at least in the way of offering support in the docs for it, but it's instead like this cult thing where you only learn about it if you go on the forums, given how it speeds up and streamlines the development by a factor of 10.
Just a few hours ago I mentioned the modal text input to you in another thread and the doc entry is this https://docs.hise.audio/scripting/scripting-api/content/index.html#showmodaltextinput which does not tell you much. What properties? What are the callback parameters that the function expects? There's so much friction in developing for HISE, mostly introduced by the lack of documentation. I run into cases like this every day.
If you nuke this forum, HISE becomes nearly unusable for professional development for anyone who's not already familiar with it or is not highly proficient in JUCE and C++. Now, you can argue that the forum is part of the experience, but that's only true as long as knowledgeable people are participating.
I have 3 threads total in 6+ years on Kontakt forums asking about something, and all 3 were before I even launched Infinite. I made Infinite in Kontakt and only had to ask 3 questions. I have 52 threads here (not counting feature requests, of course) in less than 6 months, and am way more experienced than I was in 2017/2018.
What happens if you die tomorrow, David? 50% of all future threads go unanswered. Something happens to Chris? What then? This thing is riding almost entirely on the two of you being active here in the forums, even though it's 120% ready for prime-time. I just think that scares a lot of potential adopters.
-
@aaronventure Excellent points.
I do agree that it would be highly beneficial to have more in-depth HISE documentation and additional examples included in it.
-
@aaronventure said in Thank you Christoph:
Really? I think KSP docs are solid. In fact I don't think it's even close.
I started (and stuck with) KSP4. The manual does a good job of listing every function and providing an example. But there aren't many functions in KSP, it's a very simple language compared to HISE. SublimeKSP is also really well documented!
HISE benefits from the snippet system, the tutorials repo, and of course we can look in the source code. I think there are probably more tutorial videos for HISE than KSP too.
For a while there was an official Kontakt development booklet, I think it was put out with Kontakt 2 or 3, I probably have a copy somewhere. And that was very helpful when I was getting started, as was the VI Control forum.
Overall I think HISE is well documented, although it could definitely benefit from more detailed explanations and examples of certain functions and features, and a proper list of all the pre-processor definitions. But all the ground that KSP covers I think is at least equally documented.
Yeah that modalTextInput thing is a good example of where HISE is lacking detail. I ran into the same thing with Loris recently. Often I just go to the source code to find out what these things are.
We as users must take some blame too because the docs are open to be edited by anyone, so if we know something that isn't in the docs we should add it.
-
@d-healey said in Thank you Christoph:
I think there are probably more tutorial videos for HISE than KSP too.
Which is almost exclusively your doing. If you decide, that can stop tomorrow. Then we're back to square one. Unless you're getting paid to make these by someone other than your patrons who, I would dare say, partially number the way they do due to the current state of the docs. You're the number one source of real-world HISE examples, but as the videos (and especially Patreon) aren't really searchable in a way that mentions which methods are being covered in which video, it still introduces a lot of friction when it comes to finding an answer, as I'll remember seeing something in one of your videos, but then have to spend an hour watching 10 of them to find which one was it exactly.
@d-healey said in Thank you Christoph:
Overall I think
Often I just go to the source code to find out what these things are.You've been here the better part of a decade. You watched this thing grow into what it is today and contributed heavily through feedback or even code. There are devs who have amazing memory and can remember all the command names, method names etc. For everyone else, there's the docs. When I work in KSP, I always have the docs open. I forget shit all the time. And I don't bother remembering everything because I know I can just look it up in the docs.
My code is meticulously commented because if it's not and I don't look at it for 2 months, I'll have no idea what the fuck's happening. When I look at the HISE source code I'm amazed at how few comments there are compared to the amount of comments I write for my stuff. This just tells me Chris and I have a completely different approach and he might not realize what an issue the current state of HISE docs is because he just knows all this stuff by Hart (I... could not resist).
I don't know where are you on this scale.
I'm not trying to invalidate your take at all, I'm just providing a perspective of someone new to HISE but still with a lot of experience in VI development to maybe argue as to why this thing hasn't taken off yet when it's around 5 years ahead of Kontakt both in features and in ease of development.
-
@aaronventure said in Thank you Christoph:
Unless you're getting paid to make these by someone other than your patrons
I'm not getting any of the sweet YouTube ad revenue yet, but I don't do it for the money anyway.
@aaronventure said in Thank you Christoph:
it still introduces a lot of friction when it comes to finding an answer, as I'll remember seeing something in one of your videos, but then have to spend an hour watching 10 of them to find which one was it exactly.
Hmmm that's very true. I think maybe if I find the time I'll cut out some short videos and link to them from the HISE docs where appropriate.
@aaronventure said in Thank you Christoph:
I'm amazed at how few comments there are compared to the amount of comments I write for my stuff
You'll find a post on the forum somewhere of me saying the same thing to Christoph when I first started poking around in the code. I used to put loads of comments in my own code too. Now I use hardly any, other than to make it a little easier to jump around sections of my code. I follow a principle called self documenting code.
It works like this. If you have a function called
getWidget, then you don't need a comment that says, "this function gets a widget". Because you already know what the function does from the name.Here's a great video on the subject (all the videos on this channel are worth watching):
https://www.youtube.com/watch?v=Bf7vDBBOBUA -
@aaronventure said in Thank you Christoph:
I'm not trying to invalidate your take at all, I'm just providing a perspective of someone new to HISE but still with a lot of experience in VI development to maybe argue as to why this thing hasn't taken off yet when it's around 5 years ahead of Kontakt both in features and in ease of development.
What would you consider as "taking off?"
I think you are overlooking the most important aspect of why Kontakt has a major share of sampled libraries. It has nothing to do with how good it is but everything to do with the fact that it has been around for much longer than HISE and the fact that it is made by NI, one of the biggest and most recognizable brands in virtual instruments.
Never underestimate the power of a well-established brand.
-
@d-healey said in Thank you Christoph:
It works like this. If you have a function called getWidget, then you don't need a comment that says, "this function gets a widget". Because you already know what the function does from the name.
Here's a great video on the subject (all the videos on this channel are worth watching):
https://www.youtube.com/watch?v=Bf7vDBBOBUAThat's true and quite obvious from method names in HISE, although self documenting code won't give you context for the decisions that were made or tell you how stuff from multiple places sometimes comes together, but now we're going into topic #3
@d-healey said in Thank you Christoph:
I'm not getting any of the sweet YouTube ad revenue yet, but I don't do it for the money anyway.
Who knows what may yet come your way. Kenny Gioia was doing it for Reaper because it needed doing and it wasn't about money, then he got hired by Reaper. It's now at a pretty admirable level.
@gorangrooves said in Thank you Christoph:
What would you consider as "taking off?"
That's a good question. I don't really have the numbers, do I? So I might as well take that back.
I guess I meant seeing a lot more high profile releases from developers that are suddenly releasing a "native VST/AU" versions of their instrument.
As for the effect plugins, who really knows? You can't know whether it's HISE unless you open the dll in x64dbg or a similar app. I think 95%+ of the existing audio plugins could easily be done in HISE and in a lot less time than it took to make them in native C++/JUCE (based on quotes I heard from JUCE devs). So in that way, I meant seeing it a lot more talked about as the starting point for anyone looking to get into audio development.
If you still wanna do drugs and write your algorithms in C++, SNEX is right there, comfortably wrapped into HISE's great IDE features.
-
@aaronventure Since Christoph is not spending money on advertising HISE; its success is going to be gradual and take time. But, the word is spreading and HISE is growing
-
Any classy things doesn't require an advertisement (IMO). HISE is a needs for APD (Audio Plugins Developer). So it doesn't need to compete , doesn't need to prove and show case. As a result it doesn't require any advertisement to stand out.
-
wow, that escalated over night! VI-Control PTSD incoming...
There's too much to address here by now, but I'll try:
- There is no real argument to have against "HISE needs more docs" and I always have that eternal nudge where I try to do proper documentation (and I think that most of the new features I add to HISE are much better documented than the old / existing stuff as I tried to make it a habit of considering the documentation part of the implementation of a new feature). However I consider this forum the main source of information (after doing a quick search around in the docs and watching at least the introduction videos to HISE from Dave). Is this different than with KONTAKT? Yes, but it's a valid approach, there are many people present in this forum (with Dave being the OG) which offer super helpful advice that often goes beyond what a documentation can provide. Does that get me out of the obligation to write proper docs? No, but it's a very powerful band aid :)
- The growth rate of HISE is perfectly fine for my taste - I also think that using the marketing method of people having to find out about HISE instead of it being shoved into their face in their social media feed pretty much correlates with the follow-up user experience during development and the people who made it through this process are kind and smart enough to create a good community like here (just go over to KVR to see what kind of people exist outside our bubble lol). So in my mind the decision between marketing HISE or not boils down to "Do I need more money in my bank account but then having to deal with idiots on a regular basis?". So whenever you see HISE ads popup before a Youtube video you can think "Poor Chris, apparently he got a rent increase and now has to respond to people posting in all caps only"...
- I don't think that there is a single factor that prevents "big" companies from using HISE (and I have adjusted my expectations over time to accept that there is only a fraction of the market that might be interested in / benefit from a platform like HISE). I can imagine that it's simply a combination of a high Bus Factor as well as the availability of C++ developers that can implement things without any outside dependency if the budget is there that makes people avoid relying on a "high level" framework.
-
@Christoph-Hart said in Thank you Christoph:
wow, that escalated over night! VI-Control PTSD incoming...
There's too much to address here by now, but I'll try:
- There is no real argument to have against "HISE needs more docs" and I always have that eternal nudge where I try to do proper documentation (and I think that most of the new features I add to HISE are much better documented than the old / existing stuff as I tried to make it a habit of considering the documentation part of the implementation of a new feature). However I consider this forum the main source of information (after doing a quick search around in the docs and watching at least the introduction videos to HISE from Dave). Is this different than with KONTAKT? Yes, but it's a valid approach, there are many people present in this forum (with Dave being the OG) which offer super helpful advice that often goes beyond what a documentation can provide. Does that get me out of the obligation to write proper docs? No, but it's a very powerful band aid :)
- all true, but there are bits of the HISE documentation that remain patchy at best - we might (As a community) get a list together of what we think needs addressing. But whilst the documentation is better for more recent stuff - there is I think a need for the sort of explanation you get from Dave's videos - to define higher level understanding. For example I'm thinking of the broadcaster and global cable functionality - and I really wish Dave would do videos on them - but they need a "how to" not an API
- The growth rate of HISE is perfectly fine for my taste - I also think that using the marketing method of people having to find out about HISE instead of it being shoved into their face in their social media feed pretty much correlates with the follow-up user experience during development and the people who made it through this process are kind and smart enough to create a good community like here (just go over to KVR to see what kind of people exist outside our bubble lol). So in my mind the decision between marketing HISE or not boils down to "Do I need more money in my bank account but then having to deal with idiots on a regular basis?". So whenever you see HISE ads popup before a Youtube video you can think "Poor Chris, apparently he got a rent increase and now has to respond to people posting in all caps only"...
Yes KVR can be toxic - but if you spend any time in the DSP and Plugin Development area you'll find generally it looks quite a bit like this forum.. so its all about members really. But thats pretty much what Christoph is saying anyway....
- I don't think that there is a single factor that prevents "big" companies from using HISE (and I have adjusted my expectations over time to accept that there is only a fraction of the market that might be interested in / benefit from a platform like HISE). I can imagine that it's simply a combination of a high Bus Factor as well as the availability of C++ developers that can implement things without any outside dependency if the budget is there that makes people avoid relying on a "high level" framework.
It will happen - it is just taking me a fair amount of time to move thru all the "big" companies trying to convince them... :beaming_face_with_smiling_eyes:
HISE Development for hire.
www.channelrobot.com -
@Lindon said in Thank you Christoph:
and I really wish Dave would do videos on them - but they need a "how to" not an API
Duly noted, although I've never used global cable so don't expect a video on that soon. For broadcasters I'm holding off until Christoph finishes his new broadcaster creation wizard.
-
@Lindon said in Thank you Christoph:
It will happen - it is just taking me a fair amount of time to move thru all the "big" companies trying to convince them...
Then they all bail on
Step 1: Build HISE from source
-
@aaronventure but there are halfway recent installers available now - but it‘s a good reminder to launch the build server and do the 4.0.0 release :)
-
@aaronventure said in Thank you Christoph:
@Lindon said in Thank you Christoph:
It will happen - it is just taking me a fair amount of time to move thru all the "big" companies trying to convince them...
Then they all bail on
Step 1: Build HISE from sourceOh I'm not trying to convince them to build and write stuff in HISE, I'm trying to convince them I should build stuff in HISE for them....
-
@obolig I appreciate that @Christoph-Hart has been a lot more active on the forum here. I may be in the minority in thinking that HISE doesn't need any more features – just more information about the ones that already exist. There's more than people realize, with direct access to FFT bins being the universal Turing machine of DSP.
In terms of companies using HISE, within the context of the ones I work with and advise, there is potentially significant interest in the JavaScript engine (not the sampler elements). From my perspective, the outwardly-facing obstacle is that there simply needs to be more than one person behind it to provide the necessary stability, maintenance of knowledge assets, and overall mitigation of inherent risk that is inherent with incorporating external systems into existing commercial ecosystems.
