OK, so that’s enough development already. No. More. Functionality. Is that the end of the line? I so wish it was that easy to ship a product. Experience tells me there is easily as much work still to come after development stops as there is already completed, basically all the sampling needs doing now. So just enough time to think about some of the development edge issues, like what version of Kontakt should this get shipped in? This is a bit of a contrived question really, because if I don’t know this by now I’m more than a little foolish . Here’s the general rule I use: Ship in the oldest (reliable) version that supports all the functionality you need, or worst case ship in the version you built it in, but these SHOULD be the same.
For me this is Kontakt version 5.5. Sure Version 5.6 has been out a few months by now, and the additional screen real-estate it offers along with the changes in KSP looked mighty tempting at the time. But for a change I held off, I didn’t *need* extra screen real-estate or the KSP changes. I’m glad I did, as there were lots of complaints about 5.6 and it seemed an above average number of problems. This made me think it wasn’t so reliable – It might be rock solid but that wasn’t the impression I was getting, or have got. I think I will wait until 5.6.7 at least if not later.
Next issue is: Kontakt or Kontakt Player? Again this is a no brainer (but sadly so in this case). I cant afford Kontakt Player – it would make Orbiter available to a MUCH wider audience, add in Native Instruments authorisation system, protect my IP and generally make Orbiter seem much more professional – and I suspect it would be the only way it would get reviewed by any of the ink-based press. But its many thousands of dollars to roll out in this format.
I can’t risk it and I don’t have the money lying around, I wish I did, and even if I did I don’t think I’d spend it this way. I’d pay an extra amount and get it coded as a VST.
So a Kontakt only product it is. Which makes the IP much more vulnerable.
Speaking of IP protection, and authentication and authorisation as we were, in passing: Lets start with the obvious: Yes every authentication system is breakable – the NI one has been broken before and will be again I guess. But….
I’ve built “in-KSP” authentication systems for 3rd-party products. They got broken – eventually, and that’s the important word — “eventually”. The best system I built took nearly 12 months before someone got round to breaking it – not because it was so good, but because it defeated amateur-hackers and the pro-hackers were busy with more high profile products. But those products with NO protection? Well they got loaded on the warez sites within a few days of release, effectively killing sales. Should I add in the authentication system and make the distributors lives more complex? (Sending authorisation codes separately to downloads via email) Would they even accept this complexity or decide not to carry the product? Dunno, but I suspect they wont be set up to handle it.
There’s a 3rd party download and authorisation system for Kontakt libraries from a company called Continuata that looks like it might fit the bill perfectly, download system, audio watermarking etc. but its not cheap to set up(again thousands of dollars).
So this might mean being back to(forced into) distributing only from channelrobot.com, and that hasn’t gone well in the past, so I’d really like to keep some distribution flexibility here. Sigh, EVERYTHING is a trade off it seems.
One nice thing (in the longer term) is that Kontakt/KSP is no longer the only viable game in town for building audio products, there’s a few. They will take some uplift effort to get up to development speed but they offer many features that Kontakt and Native Instruments doesn’t/wont. I’m keeping a close watch on them all. But truth is, I’m moving on – KSP moves slowly, and hasn’t added anything I care about in a long while, and the non-functional issues with the development environment are holding back sales for me I think.