Romplerz
-
-
@modularsamples @cassettedeath I don't mean to pick on you—I just don't think it's responsible to promise new developers that they can use all these things, when there are so many problems—especially if you try to use all those things together—you can get several months into a project, and then realise things either don't work, or don't work how the API implies they do—and there is nothing you can do about it. HISE is a really cool thing for experimenting and/or people who don't need to meet deadlines that involve other people. It is not a robust, consistent and reliable API for every business.
I think that we should be up-front with people about this. Welcoming, but candid.
-
@clevername27 what do you mean by the API is not reliable for business?
-
@mmprod I've amended what I wrote to say "…every business." Pretty much what I wrote. You need to know what you're getting into. @Christoph-Hart says it right on the front page that if there's a problem, don't expect it to be solved.
For example:
-
I have one plugin that's six months overdue because of problems with HISE—problems that largely, it is beyond my (or anyone's) capacity to solve. (But I knew what I was getting into.)
-
I have another plugin that's less complex, but still substantial. In this case, everything I wanted to do is something that HISE's API is tuned for, is properly documented, and works correctly. I wrote that plugin, start-to-finish, in two days. I could not have done that with anything but HISE.
My point is, this isn't Kontakt or JUCE (representing two ends of a spectrum). There is no support whatsoever—only what other developers know and are willing to share. I would never promise a HISE-based plugin to be completed on a specific schedule—or with a specific feature set—within a corporate context. If those things are important to me, I should use a more "on-rails" system (e.g. Kontakt) or a mature, generalised, documented API (e.g. JUCE). If Kontakt doesn't work, it's NI's problem, and there's a billion JUCE developers.
But, if you're not afraid of getting my hands dirty, and on your own schedule, then nothing comes close to HISE.
-
-
@clevername27 Not at all, it's a fair point, new users should be aware that certain things don't work. Though I'd say if you are methodical, test often and are willing try different approaches to things, it can go a lot smoother.
-
@modularsamples Also a fair point.
-
What are some things to avoid having in a commercial product?
My plug ins are fairly simple sample based instruments - romplers with the basic effects - and another sample based instrument using multi mic and containers to send multi mics to effects…
-
@cassettedeath I'm probably not the best person to ask, my projects are open source, occasionally with a commercial component (extra sounds, presets). Releasing commercially is an entirely different proposition, I suspect.
Keeping things simple is a good idea. avoiding scriptnode, FAUST etc. will probably result in a more stable instrument, follow your dreams but try to balance them with your abilities. You know, 3 years on, and I've still no idea what a multi-mic is (hello, is this thing on?).
-
@cassettedeath said in Romplerz:
What are some things to avoid having in a commercial product?
My plug ins are fairly simple sample based instruments - romplers with the basic effects - and another sample based instrument using multi mic and containers to send multi mics to effects…
the short answer is - if you are doing something not so esoteric (@clevername27 's stuff is often pushing the boundaries) then using faust, ScriptNode, SNEX etc. should all be fine.
I have a range of commercial products out there that use some or all of these and those products have a reasonable profile, e.g. Horizen which we sell thru Tracktion, and if you get your product to compile and pass all its tests (AUVAL and pluginval, beta testing across OSes and platforms etc.) then there is nothing inherently unreliable about HISE.
HISE Development for hire.
www.channelrobot.com -
@Lindon @cassettedeath Lindon speaks truth.
