Viewport

[Lindon]

@Christoph-Hart thanks for this -interesting code.

I'm not sure I understand when you say "you would need to resort to another (hidden) UI element managing the restoring / saving of your current samplemap" - do you mean floating tiles dont have callbacks that can be executed on click - if so I'm wondering how the preset browser manages to load presets when the user selects one. All I was asking for is a version of that I think.

But in any case your code returns a simple list of samplemaps - which highlights I think my problems. Some background: If I am going to port a number of our ROMpler instruments to HISE then I am going to have up to (and occasionally over) 1,000 samplemaps in each product- yeah there are 1,000+ groups in the Kontakt instruments. These are often at least 2 "voice" instruments (sometimes 4) so I need a way to load each "voice"(Sampler in HISE) with a group/samplemap.

Listing them is a nightmare - so I needed a "sound browser" - I built one in Kontakt that is not so far away from your preset browser.

It's a compromise but it works. This is what I was looking for as a floating tile option - because I think a lot of HISE developers will arrive at a place (ROMpler building) where you have a lot of samplemaps - and their end users will need some friendlier-than-a-bald-list approach to this.

But lying awake last night thinking about this problem - what I'm looking for really is more like this:

Which looks similar but is really a meta data based browser. So I need a way to hold metadata for samplemaps (where "favourite" is just one element/attribute of meta-data) and display/filter them based on that meta data.

Again this shows up all the time in (all) the NI products and those from other developers like Arturia etc. so there's a demand. I guess I will have to go build this myself then.

[d.healey]

@Lindon Instead of the user loading sample maps think of it as the user loading presets and each preset is tied to a sample map. I'm doing this now for a synth project. It does mean creating 1000 presets manually though it seems but this allows you to use the standard preset browser to achieve the same goal - no meta handling though.

[Christoph Hart]

Instead of the user loading sample maps think of it as the user loading presets and each preset is tied to a sample map. I'm doing this now for a synth project. It does mean creating 1000 presets manually though it seems but this allows you to use the standard preset browser to achieve the same goal - no meta handling though.

Not sure about this. If you have to create 1000 things of something manually there has to be a smarter way.

I am using something like you are talking about in HEXERACT to display a sound browser and it splits the samplemaps into categories based on their folder, then shows it in two viewports - one for the category, one for the folder. In this case it is only two levels, but it shouldn't be too hard adapting the code to support multiple levels.

However your idea of attaching some kind of metadata to the samplemap makes sense - in fact there is already a bunch of metadata present (multimic IDs, round robin amount, etc), however if I do this I must be extremely careful not to break backwards compatitbility, which would add another pile of mess to the issues with samplemap loading at the moment :)

[d.healey]

@Christoph-Hart Sample Maps can be in subfolders! I never knew that.

[Lindon]

@d-healey Dave this wont work. Even in the "simple" two voice ROMplers, the user selects from 1,000 sounds(samplemaps) for each voice - so that means 1,000 * 1,000 combinations so I'd have a smooth 1 Million presets to cater for all combinations

[Lindon]

@Christoph-Hart Yes its no easy task to decide on the metadata here, and it has to be accessible, filterable, sort-able , useful...

As a starting input can I relate that we had a go at this (well I did) for the Kontakt implementations. It was all too hard in a land with no string comparison, but the one useful piece of information was I decided to define a set of "free-form" text fields, tags really - and I never got beyond 4 or 5 MAX no of tags for any given sound.

Perhaps if you added (say) 4 free-form text based tags to each sample map that would pretty quickly cater for almost every conceivable (reasonable) scenario. Sure there is going to be some ***ker who will start asking for more (likely to be me - fair warning ) but I think its 80-20 rule time for this sort of thing.
So you could "just" put 4 text fields on the Sample Settings tab - so that'd deal with the "manual entry" part of it. And some simple way to set a tag value programmatically:

Sampler.setSampleMapTag(<index>, "value") <--so you can only set a tag for the currently loaded sample map

Then we need a way to harvest these tags for all sample maps in the instrument <--- here I'm leaving you the hard work

I may be waaaaay ahead of where we are at this point and possibly waaay off beam too, so I'll stop designing-on-the-fly and get out of the way.

[Christoph Hart]

I'd rather make an API like this:

// returns the metadata as big JSON object. keys are the IDs, and the value is a object that you can populate with anything that can be converted to a JSON string.
const var metadata = Sampler.getSampleMapMetadataList();

const var currentMetadata = metadata[Sampler.getCurrentSampleMapId()];

// read operation: check the tag for the currently loaded samplemap.
if(currentMetadata["tags"].contains("hardcore")
{
    // Something...
}

// write operation
currentMetadata["tags"] = ["Tag 1", "Tag 2", "Tag 3"];

// "flush" the write operation. This will reload the pooled samplemap (asynchronously).
Sampler.writeMetadata(Sampler.getCurrentSampleMapId(), currentMetadata);

[Dalart]

@Christoph-Hart said in Viewport:

Instead of the user loading sample maps think of it as the user loading presets and each preset is tied to a sample map. I'm doing this now for a synth project. It does mean creating 1000 presets manually though it seems but this allows you to use the standard preset browser to achieve the same goal - no meta handling though.

Not sure about this. If you have to create 1000 things of something manually there has to be a smarter way.

I am using something like you are talking about in HEXERACT to display a sound browser and it splits the samplemaps into categories based on their folder, then shows it in two viewports - one for the category, one for the folder. In this case it is only two levels, but it shouldn't be too hard adapting the code to support multiple levels.

However your idea of attaching some kind of metadata to the samplemap makes sense - in fact there is already a bunch of metadata present (multimic IDs, round robin amount, etc), however if I do this I must be extremely careful not to break backwards compatitbility, which would add another pile of mess to the issues with samplemap loading at the moment :)

The functionality of the viewport you described in Hexeract sounds like a solution I would be interested in and could use for some of the projects Im tinkering with.

Is there an example or snippet around here somewhere for the dual viewport view and category listing ?

[Jay]

@Dalart Following

[Christoph Hart]

Yes I will include a snippet for this in the new fancy documentation I am working on right now.

Also I realized it makes absolutely no sense storing the metadata in the samplemap file - just include a separate JSON file with the sample id as key names and do whatever you need to do using stock Javascript data processing.

[Dalart]

@Christoph-Hart Thank You !
I cant wait to test it out and try to learn how it works =)

[Dalart]

@Christoph-Hart said in Viewport:

Yes I will include a snippet for this in the new fancy documentation I am working on right now.

Is there an ETA for the new documentation and examples or are they on github already somewhere ?

[Dan Korneff]

Is there an API for the Viewport yet?
Trying to figure out how to view the contents of a folder.... ultimately, midi files so I can load them into the new midi player.

[Dalart]

Im also still interested in how to view / sort the samplemaps into folders as talked about in this thread.

[ulrik]

@Dalart @dustbro the "Registers & Chords" is a viewport

I populated it using array
this array

const var ArtList = ["Stradella", "Freebass", "Tenor (Bass)", "Master (Bass)", "Alto (Bass)",
"Low Shift (Bass)", "Master Shift (Bass)", "High Shift (Bass)",
"Bassoon (Treble)", "Bandoneon (Treble)", "Master (Treble)", "Violin (Treble)", "Clarinet (Treble)",
"Major (Chord)", "Minor (Chord)", "Seventh (Chord)", "Diminished (Chord)"];

and making the array readable in the VP

inline function onArtVpControl(component, value)
{
    ArtVp.set("items", ArtVpList.join("\n"));
    uaccVp.setValue(uaccUserList[value]-1);
};

and accessing the value from another array called uaccUserList and sending it to the "uaccVp" which is an ComboBox

So the "ArtVp" is the ViewPort now populated with the array "ArtVpList" and clicking on any of the items in the ArtVp will get you a value, the same value as the index of the array, if I remember right, maybe the value starts with 1 (and the first index in an array is 0)

[Dan Korneff]

@ulrik How do you populate it with the contents of a folder?

[ulrik]

@dustbro if you mean without having the folder content already in an array? I don't know. :(

[ulrik]

@ulrik I found this line in "ScriptingApi.h" from the source code

/** Returns a list of the sounds selected in the samplemap. */
		var createListFromGUISelection();

and

/** Returns an array with all available sample maps. */
		var getSampleMapList() const;

maybe this has something to do with it?

[ulrik]

@dustbro This will get you an array of all sampleMaps, then you can populate the ViewPort with the array.

const var list = Sampler.getSampleMapList();

I don't know about getting midi files from the folder, sorry.

[Lindon]

@Christoph-Hart yes it would seem we need a generalised way to get the contents(a list of files) from a named folder - by type(e.g. *.wav, *.mid)

Of course it would be nicest if this was a FloatingTile with a content type of FileList