Universal Sample Player....

[Lindon]

So, over on VI-Control someone posted about the idea of building a Universal Sample Player - essentially replacing each of the proprietary sample players (Such as Sine, Spitfires thing, etc. including Kontakt) in order to offer end users a consistent interface.

Dave, Christoph and I patiently (or not so patiently in my case) went through the essentially benightedly silly proposed approach and pointed out :

1. why it wouldn't work
2. Why the nearest possible solution to this already existed - HISE

You can read the tortured and painful process here, if you have some sort of masochistic tendencies this should satisfy them admirably..:

Universal Sampler

Having read some recent posts about various new proprietary samplers it strikes me that it is a really high-risk commercial strategy because the...

VI-CONTROL (vi-control.net)

You will see that it was filled with the usual level of denial in the face of reason/experience as well as Mikes frankly crazy proposal (which he seems to be pursuing despite my attempts to dissuade him) to take $1Million and rebuild Kontakt exactly so NI dont own it and some small subset of him and his friends do.

There were for me an unusually large number of jaw-dropping moments of incredulity at the naivety involved, and it became clear thru this discussion that almost no one had any coding experience and/or experience of even the alternative tool sets being discussed(HISE, Gorilla etc.)

Despite all this, and at last I'm getting to the point of this post.., there was the kernel of a good idea in there. The idea that some set of sample base products would offer a (partly) consistent interface the users were familiar with that would empower users. Trying to do this with a ground-up build of a standardised sampler engine is nuts and we had good reason to say it was nuts. BUT....

Doing it thru a specification might not be nuts.

Clearly (especially if you read the thread) there are acres of ground within a products functionality that developers want to make their own and NOT have the same as their competitors. But there may be areas where we could define a spec. that covered things like:

• The download process
• The install process
• The Sample(voice/sound) browser/selection process
• The Preset load/save and display process
• The use of key switching
• the interface resizing process

Well you get the idea. At this point there would be a spec and some "badge" that compliant products could display to potential customers that would give them some confidence that the product they are buying would at least have some components/functions/interface that they already understood.

So (some of) the questions for debate:

1. Is this even a good idea?
2. How could/would we "enforce" compliance?
3. Who would "own" the spec.?
4. What could be in it? (and what should def. be left out)

Ok have at it.....

[d.healey]

@Lindon Rhapsody :)

Now let's discuss my idea for a Universal DAW!

[Christoph Hart]

I also think that using Rhapsody (or at least the Rhapsody template that comes with HISE when you create a new project) is the closest we can get to a common ground. It opposes "restrictions" on the interface size, the way the preset browser is handled and the global look and feel while being generic enough to allow customization. "Restrictions" are quoted here, because it's all written in HiseScript so you CAN customize anything you want to your liking, but the starting point is the same and we can trust in the eternal laziness of people that this will result in a similar UX for most projects that start out there (also the default LAF of Rhapsody looks much better than the stock HISE stuff).

However I think that a universal HISE sample player will never outrank the attractively for developers compared to making their own plugins - this is the reason why I never bothered to push the HISE player project forward but instead teamed up with David to make Rhapsody the "official" HISE player as it's not an empty depressing player plugin, but filled with his content to start with.

In the end (and this is the point where the discussion on VI-Control got stuck) is that there is a fundamental difference between the interests of developers (segmentation, sticking out from the competition) and end users (everything looks and feels the same so I can use muscle memory whenever I swap out a sample library), so my best advice is to just stop talking about it as it only reveals you as the scrooge capitalist you are and make money :)

[aaronventure]

Frankly the idea that having a universal UI would make for a better product for consumers is beyond silly. Who decides what goes into that and how the standard evolves?

The mere proposal comes from the assumption that all users are idiots and have trouble navigating VIs. Some designs are dense, yes, but a lot of it comes from Kontakt's limitations. It's up to each individual dev to deliver the best UX possible, whether copying someone else or inventing their own. That's how the overall UX evolves.

Plus, $1mil. to clean-room Kontakt is also a bit senseless. Even if you're making so much as to warrant the HISE Pro license, it would take you 30 years to drop $100k into Chris' pocket, which was the buy-in amount for their idea (or something like it).

The math just doesn't work. At least I don't see it. Everything they could possibly want is here, in one way or the other (still some bits missing that you'd find in the requests section but generally HISE is pretty much there).

[d.healey]

@aaronventure said in Universal Sample Player....:

Frankly the idea that having a universal UI

The OP in the VI thread said that he definitely didn't want a universal UI. But he did want the underlying interface to be the same. What I think he meant was basically how in Kontakt the edit view, the settings, the instrument header, the "shell" effectively is the same for all instruments. While the instruments themselves can be individual.

And of course this can be achieved with Rhapsody. Here is a nice example from Virtuscape - https://www.virtuscapeaudio.com/products/p/rhodecase88-1

I also think Mike's idea is a strange one. Why spend a $1m + 5-10 years on development, instead of just learning HISE script and porting your instruments over, or paying someone else to. It would be cheaper and faster. But maybe the control aspect is more important as I know Mike isn't a fan of Christoph's business model.

[Lindon]

@Christoph-Hart Yeah I get that Rhapsody is a well defined and usable solution - but I think that, in the balancing act between user needs and developer needs you so eloquently characterise, then Rhapsody leans too far over into the users domain. I'm unsure how a 10 voice sampler/synth/loop player, or a drum machine might be implemented in Rhapsody. In fact almost everything I've built doesn't fit in the Rhapsody model, take this loop player:

Elitist Loop | Modern Vocal Hook Generator | Music Software Instruments | Sound Effects | Professional Audio | Ava Music Group

Elitist Loop is a modern vocal engine that features 480+ unique vocal chops. Choose from over 250 premade loops. Change rhythm and pitch in just one click. With highly customizable features and endless combinations to choose from, ELITIST gives you vocals you won’t hear on anyone else’s track.

AVA MUSIC GROUP (avamusicgroup.com)

So whilst this isn't (I think) a good fit for Rhapsody the kind of "standardisations" I was suggesting would still be applicable.

[aaronventure]

@d-healey said in Universal Sample Player....:

I also think Mike's idea is a strange one. Why spend a $1m + 5-10 years on development, instead of just learning HISE script and porting your instruments over, or paying someone else to. It would be cheaper and faster. But maybe the control aspect is more important as I know Mike isn't a fan of Christoph's business model.

I think Mike just might be dissatisfied with the HISE onboarding . David, post a YouTube short about building HISE on Windows with a high pitched voice. Download visual studio, Git clone, open Projucer, click open in IDE, select release, click build, launch HISE.exe. Should be like 10 seconds.

There could be a GREETINGS KONTAKT DEVELOPERS document outlining all the paradigm changes and things to look out for. You can pretty much outline one from all the questions I asked on this forum in the past few months :grinning_face_with_big_eyes:

@d-healey said in Universal Sample Player....:

The OP in the VI thread said that he definitely didn't want a universal UI. But he did want the underlying interface to be the same. What I think he meant was basically how in Kontakt the edit view, the settings, the instrument header, the "shell" effectively is the same for all instruments. While the instruments themselves can be individual.

Aren't we all already doing that? Software is all very similar. VIs are no different. There's a settings icon in the upper corner, tabs are wide and have some indentaion, controls are all knobs and sliders because that's what the original synths back in the day had. Mic mixer is a group of sliders or knobs. Even the mic naming has gotten defacto standardized. Dynamics CC1, volume CC11, etc.

The differences are in the exact layout, the design language, and then in the amount of features available.

[Christoph Hart]

@Lindon Have you taken a look at the Rhapsody template? Create a new HISE project, but click on Rhapsody template instead of Create a new empty project. This is super generic and in the case of your example, it would just require reshuffling of the main elements and removing the keyboard on the bottom.

But that yields another big disadvantage: usually the UI design is finished (or in the process of being finished by an external graphic design team), so if the developer sends them a template of "hey nice what you're doing, but please use this as starting point for your layout", all you'll get is awkward silence and then their next iteration of the interface as they have planned it.

[Lindon]

@aaronventure said in Universal Sample Player....:

The differences are in the exact layout, the design language, and then in the amount of features available.

and currently in:

The download process
The install process
The Sample(voice/sound) browser/selection process
The Preset load/save and display process
The use of key switching
the interface resizing process

[Lindon]

@Christoph-Hart said in Universal Sample Player....:

@Lindon Have you taken a look at the Rhapsody template? Create a new HISE project, but click on Rhapsody template instead of Create a new empty project. This is super generic and in the case of your example, it would just require reshuffling of the main elements and removing the keyboard on the bottom.

But that yields another big disadvantage: usually the UI design is finished (or in the process of being finished by an external graphic design team), so if the developer sends them a template of "hey nice what you're doing, but please use this as starting point for your layout", all you'll get is awkward silence and then their next iteration of the interface as they have planned it.

yeah precisely....so maybe we avoid all the stuff they UI designers want to exercise their photoshop skills with and focus on the "shell"

But this is partly missing the point of a specification, which would be implementation independent - you could comply with the spec. if you built in HISE, Gorilla or C++ or any other tool set...(except Kontakt of course...)

Rhapsody - perhaps great for HISE developers, useless for anyone else.

[Christoph Hart]

I think Mike just might be dissatisfied with the HISE onboarding

And to be honest that has changed quite a bit since we've talked about it. I don't have that as my number one priority, but I'm also not an ignorant idiot who is sticking his head into the ground:

• there is a new and shiny website with clear licensing information now
• there is a somewhat up-to-date downloadable build of HISE whenever the version changes.
• there is a route for publishing HISE build projects without touching a compiler once by using the release build of HISE alongside with the RHAPSODY player - the GPLness of the entire process might be off-putting for most commercial developers but an evil genius might even get the idea that this is intentional :)

[Christoph Hart]

But this is partly missing the point of a specification,

I think that's the key problem. It's hard enough if not impossible to specify what the specifications are, let alone specifying the specifications themselves because there is not a common goal that all VI-developers share - just to take you and Aaron as example, and you are two just random dudes, every single developer will have a different opinion of what needs to be standardized and what not.

So, if a general UI starting point (like the Rhapsody template) isn't the way to go, then what? A framework of HiseScript classes that give you an API for managing downloads? Fine, then that's only useful for us HISE folk, the rest will stay out in the cold. Do you mean a general way to get files from another location? Nice one Lindon, you just reinvented the INTERNET :)

[aaronventure]

@Lindon said in Universal Sample Player....:

The download process
The install process

True, probably the most annoying part.

@Lindon said in Universal Sample Player....:

The Sample(voice/sound) browser/selection process
The Preset load/save and display process

Isn't this also "standardized" to a point? It's usually a button or a dropdown in the top? If it's a button, it opens a menu similar to the preset browser in HISE (don't know who came up with that first, was it NI?) where you move from categories to individual presets from left to right.

@Lindon said in Universal Sample Player....:

The use of key switching

That's either a key on a keyboard or a certain CC# with each value being a different articulation. There's room for setting up a standard for the CC# values. The Spitfire UACC is a good starting point but you'd have to wing it a bit for something like an electric guitar. https://spitfire-webassets.s3.amazonaws.com/pdfs/UACCv2spec.pdf

@Lindon said in Universal Sample Player....:

the interface resizing process

I feel like this is always in the bottom corner, either drag or a click-menu. Sometimes it's in the settings.

[d.healey]

@aaronventure said in Universal Sample Player....:

David, post a YouTube short about building HISE on Windows with a high pitched voice. Download visual studio, Git clone, open Projucer, click open in IDE, select release, click build, launch HISE.exe. Should be like 10 seconds.

That's actually a good idea.

@Lindon said in Universal Sample Player....:

I'm unsure how a 10 voice sampler/synth/loop player, or a drum machine might be implemented in Rhapsody

A Rhapsody project is just a HISE project. There are a few limitations but I see no reason you couldn't make a loop player or drum machine.

I mean I have made a loop player for Rhapsody already :) Single voice, but it could easily have more if I wanted to build it out.

[Lindon]

@Christoph-Hart said in Universal Sample Player....:

But this is partly missing the point of a specification,

I think that's the key problem. It's hard enough if not impossible to specify what the specifications are, let alone specifying the specifications themselves because there is not a common goal that all VI-developers share - just to take you and Aaron as example, and you are two just random dudes, every single developer will have a different opinion of what needs to be standardized and what not.

So, if a general UI starting point (like the Rhapsody template) isn't the way to go, then what? A framework of HiseScript classes that give you an API for managing downloads? Fine, then that's only useful for us HISE folk, the rest will stay out in the cold. Do you mean a general way to get files from another location? Nice one Lindon, you just reinvented the INTERNET :)

No!!! I mean a text document that says something like:

PRESETS
Must present as a Text name centred on the Main UI in the header in a "box" of a contrasting colour
Clicking on the name opens the preset browser

THE PREST BROWSER

• Must display presets in a 3 column browser (Folder>Category>Preset)
• Must offer the user the ability to add, delete and rename existing presets
• must offer the user the ability to add new presets with a button labeled " Add New"

So this may all seem obvious - until its not - but its a set of UI guidelines that assure users this product xxx complies with these guidelines.

Everyone is out in the cold here, its not about providing a set of implementation examples - tho clearly we could do that for HISE easily enough - its about defining some rules for everyone no matter what dev environment/platform they are using .

[d.healey]

@Lindon I don't think that will work, even with this incredibly simple example I see issues.

[aaronventure]

@Christoph-Hart There could be a consortium, a board of sorts, that decides on a single service to host the files, single service to process payments and to manage customer data. We could then decide to use that implementation (with a small degree of freedom depending on library size) for each product.

Maybe we could take it even further and join up legally. We could be a legal establishment, an organization with a recognizable name. A company! Of course, not one of us should take fire for the general output, so we should probably limit the liability of that company.

Wait...

[Christoph Hart]

Man this forum topic got chaotic pretty quickly, but anyways:

There could be a GREETINGS KONTAKT DEVELOPERS document outlining all the paradigm changes and things to look out for. You can pretty much outline one from all the questions I asked on this forum in the past few months

That's also a good idea (I was a bit hesitant about doing stuff like this because it creates strong Burger King vs. McDonalds vibes), but since this comes up again and again, why not address it directly.

However I think I would vastly benefit from the input of you guys as I don't have any experience with working in KONTAKT for the last 10 years. Maybe we make a spinoff thread where you can just post the things you noticed were non-trivial issues when migrating over here, then I'll make a nice chapter in the docs about it and maybe David can then make a video out of the content too.

[Lindon]

@d-healey said in Universal Sample Player....:

A Rhapsody project is just a HISE project. There are a few limitations but I see no reason you couldn't make a loop player or drum machine.

I mean I have made a loop player for Rhapsody already :) Single voice, but it could easily have more if I wanted to build it out.

maybe I'm not being clear :

This has NOTHING to do with any given implementation. Great Rhapsody is the solution for all us HISE people - now I want to include every C++ and Gorilla developer too.

[aaronventure]

@d-healey said in Universal Sample Player....:

That's actually a good idea.

Don't forget the funky background music!