Viewport

[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

[Christoph Hart]

Nah, I won't do more FloatingTiles unless absolutely necessary - the overhead of adding the text colour for the directory name is killing me.

What I can do is adding two simple function calls:

/** Returns the folder that contains the application data of your plugin. */
Engine.getAppDataFolder()

/** Returns a list of filenames in the given folder (non-recursively). */
Engine.getDirectoryContent(String filename)

This way you could create a file browser for yourself by grabbing the list and throw it to a viewports items property. But I won't add more Norton Commander features to HISE, from there you're on your own (but file filtering can easily be done using standard Javascript methods).

[Lindon]

@Christoph-Hart sounds good I assume this:

Engine.getDirectoryContent(*.mid)

would work? - of course as you say I could filter with javascript but then what would be the point in having "filename"