Custom browser - custom preset file format???

[Orvillain]

I'm being asked about building a custom browser. They want to show a ton of meta-data for a preset or a sound (any individual samplemap). They want a ton of search functionality too.

They also want to be able to export a preset, and include any sample content with the preset - ie; bundle the custom loaded .wav file, or the samplemap, with the preset. For personal sharing purposes.

So RE: Browser. My first initial thought was to build a custom browser, with custom panels that paints columns and labels, and various visual widgets. These would all get populated from data parsed from JSON. Every samplemap would have an associated JSON file with the relevant meta-data next to it. On plugin load, this data is injested and stored in the main local database. Meaning when they add samplemaps down the line, the database can grow.

This would allow me to parse JSON according to their filter selections, and update panels, labels, paint routines. It's a good chunk of work, but I don't think it is particularly difficult.

The other requirement, of exporting a preset with its associated samples.... that feels likre I'm going to need a custom preset file format, to be able to store the actual names and guid's of sample-content. Which can later on be used to rebuild a sample map.

Any thoughts on this kind of thing?? I've only really just started thinking about the requirements here.

[d.healey]

@Orvillain said in Custom browser - custom preset file format???:

Any thoughts on this kind of thing

Sounds like a lot of work.

@Orvillain said in Custom browser - custom preset file format???:

bundle the custom loaded .wav file, or the samplemap, with the preset.

What do you mean by bundle?

[Orvillain]

@d-healey said in Custom browser - custom preset file format???:

@Orvillain said in Custom browser - custom preset file format???:

Any thoughts on this kind of thing

Sounds like a lot of work.

Yep it is! But they're paying for it....

@Orvillain said in Custom browser - custom preset file format???:

bundle the custom loaded .wav file, or the samplemap, with the preset.

What do you mean by bundle?

I'd probably settle for a preset file and accompanying .samples folder that sits next to it, with the preset file being updated to no longer include hard-paths, but relative ones instead. The enforcement being that the .samples folder HAS to live next to the preset file on disk.

[d.healey]

@Orvillain said in Custom browser - custom preset file format???:

I'd probably settle for a preset file and accompanying .samples folder that sits next to it, with the preset file being updated to no longer include hard-paths, but relative ones instead. The enforcement being that the .samples folder HAS to live next to the preset file on disk.

That sounds like the simplest solution. So then it's just additional lines to add to your preset json file.

[Orvillain]

Right so it looks like there's quite a few ways to potentially address this. But probably the most flexible is using the UserPresetHandler API:
https://docs.hise.dev/scripting/scripting-api/userpresethandler/index.html

This function seems extremely relevant:

UserPresetHandler.setUseCustomUserPresetModel(var loadCallback, var saveCallback, bool usePersistentObject)

It takes two functions - onPresetLoad and onPresetSave.

So in theory, I write a custom namespace for handling my custom preset format. It needs to be able to this kind of stuff:

• Gather all loaded samplemap names and any relevant identifiers
• Gather all parameters and their values
• Construct a sensible JSON array of all of the above
• Save it to a file on disk, using the FileSystem API coupled with the UserPresetHandler API.
• Use the onPresetLoad() method to reconstruct a selected preset in full.
• It also needs to be able to flag when sample content cannot be found.
• It needs to be able to also save and restore modulator states
• Any internal values for midi processors also need to be stored
• Arpeggiator patterns also
• Any routing matrix changes
• Maybe sample map details beyond names - root notes, velocity splits, etc?
• Add a version number to the file for future use
• UI states for selected tabs
• Provide some kind of sample relink method in situations where a samplemap or individual sample cannot be found
• For saving a preset, I should plan to allow custom meta-data to be added to a preset; things like author, style, type, etc...

Need to do some heavy thinking about this. Because the clients requirements are definitely quite a bit more expanded in scope than I initially thought.

[HISEnberg]

@Orvillain It's definitley a big task. Out of curiousity have you considered just "hijacking" HISE's preset system using the UserPresetHandler API? This is what I am testing out currently in a project that demands more from the preset browser than is currently available.

My idea is to let HISE's preset system to handle all the heavy lifting while I just define custom save/load callbacks that embed extra metadata as necessary. So instead of creating a completely separate file format, I'm using UserPresetHandler.setUseCustomUserPresetModel() to replace HISE's default data structure with my own while keeping the standard .preset file format.

As an example I am trying to define my own Tagging system and adding that information into the .xmls found in the UserPreset folder.

It might breakdown in your use case given the client requirements here, but may be worth investigating.

[Christoph Hart]

That's the right direction, but I would also try to stay within the HISE user preset system so you get the intended loading prodecure (kill voices, load the preset on a background thread, then unsuspend the audio processing).

With the custom data model you can define the layout of the user preset file as you wish. Note that it will be converted from JSON to XML at some point though (which is a bit weird).

They also want to be able to export a preset, and include any sample content with the preset - ie; bundle the custom loaded .wav file, or the samplemap, with the preset. For personal sharing purposes.

I would detach this from the user preset system. A preset with sample mapping data and samples should be

1. The preset file
2. The JSON (or SFZ or whatever) mapping file
3. The audio samples

all in one folder.