Universal Sample Player....

[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!

[Lindon]

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

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

what issues?

[d.healey]

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

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.

Aha I get it now!

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

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

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

what issues?

Not every instrument needs a preset browser.
HISE's expansion system allows for a 4 column layout that isnt applicable to other platforms.
Some might only need 1 column.

[Christoph Hart]

what issues?

So basically, you just want a style guide, like the thing that makes every Apple thing look the same. I can only imagine the pain of getting there through a consortium of equally entitled people trying to fight for their aesthetics making it into the official style guide.

I mean we can try, and if we come up with something good, then I'm happy to change the default HISE appearance and stock UI components to follow that style guide, but I'm modestly pessimistic that we get something usable out of the process.