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 🙂



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



  • @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



  • @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.



  • 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);


  • @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 ? 🙏



  • @Dalart Following



  • 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.



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



  • @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 ?


 

5
Online

426
Users

1.5k
Topics

10.7k
Posts