Custom Preset Browser example



  • i´m working in a new Clarinet instrument project and trying to create a custom preset browser. I´m using the newest posibilites of latest Hise , with "Engine.getUserPresetList" and "Engine.loadUserPreset" as Crhistoph suggested , all it´s ok but I have a problem with " Engine.saveUserPreset" because when I used seems it does not save the changes in preset really...
    alt text

    alt text



  • If I remember correctly the save preset command needs to have an entire path including the {PROJECT_FOLDER}, category, bank, preset name. I experimented with this a few months ago but can't remember much about it. There might be a forum post somewhere that has the info you need.



  • @Christoph-Hart I can't get the saveUserPreset to work either.

    None of these combinations seem to work

    Engine.saveUserPreset("{PROJECT_FOLDER}/ "+ Engine.getUserPresetList()[0]);
    Engine.saveUserPreset(Engine.getUserPresetList()[0]);
    Engine.saveUserPreset("");
    Engine.saveUserPreset();
    Engine.saveUserPreset(Engine.getCurrentUserPresetName());


  • administrators

    I've looked into the implementation and it seems to require that a preset is already loaded. In this case it will save it as sibling file.

    So in order to make this function work, you need to:

    1. Load a user preset (eg. Bank/Category/Preset1).
    2. Call Engine.saveUserPreset("Preset2"); and it will create Bank/Category/Preset2

    Now the big question here is: why on earth does it work like that, because it's a really shitty behaviour. I think I've needed it for a project where a label was displaying the current preset and you could enter a new name and save it as another preset, but it's definitely not as general purpose as this method's name suggest.

    I wouldn't spend too much time using this functionality, because this should be changed to work as expected by just giving it a reference (the {PROJECT_FOLDER} wildcard is not needed because you can't save user presets outside of the directory, so it's redundant. I'll come up with a clear API for this in the next days...



  • @christoph-hart said in Custom Preset Browser example:

    I've looked into the implementation and it seems to require that a preset is already loaded. In this case it will save it as sibling file.

    So in order to make this function work, you need to:

    1. Load a user preset (eg. Bank/Category/Preset1).
    2. Call Engine.saveUserPreset("Preset2"); and it will create Bank/Category/Preset2

    Now the big question here is: why on earth does it work like that, because it's a really shitty behaviour. I think I've needed it for a project where a label was displaying the current preset and you could enter a new name and save it as another preset, but it's definitely not as general purpose as this method's name suggest.

    I wouldn't spend too much time using this functionality, because this should be changed to work as expected by just giving it a reference (the {PROJECT_FOLDER} wildcard is not needed because you can't save user presets outside of the directory, so it's redundant. I'll come up with a clear API for this in the next days...

    Dear @Christoph-Hart it would be awesome that not using only "bank》category》preset" folder structure. Yes it would be a choice for some cases but sometimes we don't use "bank, category, preset" hierarchy.

    We should be able to load presets directly (without bank and category name, just loading from predefined folder) or we should be able to use 4 or 5 subfolders too (such as "Dave Pensado》Drums》Rooms》Preset... etc) Preset browser should open and show folders of the presets within a cool content browser.

    And please please please make an A/B comparsion button, load, save, next, prev buttons should be customisable (image strip and locating buttons freely).

    If you do that, HISE will have the most powerful preset system, like Kings... 😉 🙂

    For referance: please look at Waves Audio plugins. Simple, powerful and user friendly....



  • @orange You can already implement an A/B comparison, this is the responsibility of the dev not of HISE... I think



  • @d-healey You are right. But it is not only A/B comparsion. I've written all the ideas above 😉


  • administrators

    You have all tools available to build your custom preset browser:

    https://forum.hise.audio/topic/581/custom-user-preset-browser/9

    It may be possible that at some point I add more properties to the PresetBrowser and make it more generic, but the general idea is: use the inbuilt thing until it doesn't meet your requirements anymore, then roll your own solution. This step might be tedious, but I can't put every option that anybody might ever think of in the generic preset browser.



  • A problem with all this is :
    Everytime you need a litle modification of a preexisting user preset you must create a new one because you cant overwrite with this method the user preset file.
    In a few time you´ll have hundreds of user presets, making tedious the action of looking for and selecting them.

    Why is not posible overwrite the user preset file with the Engine.saveUserPreset() method ?



  • @jadg Christoph said he's going to change it this week to do that 🙂

    I'll come up with a clear API for this in the next days...



  • @d-healey
    ok, of course,



  • @christoph-hart Yes man you are right, it's impossible to put everything that anybody might ever think.

    But believe in me, the things that I've mentioned are standarts for a plugin and it will meet everybody's needs. So no one can ask you a different idea. So why HISE doesn't have such generic features / standarts that every plugin developer needs... I'm sure if you would have enaugh time, you would the best bro.... I understand you.



  • Here are just a few different companies that uses this menu structure like other fx plugin developers... 😉 🙂

    alt text



  • @orange I can show you many others that don't 🙂 It is better if Christoph creates an API that each developer can use to make their own preset handling solution rather than having one setup that will suit some people but not others.

    For example for my current project I'm using the preset system to change entire instruments and this reloads all the sample maps, an A/B button would not be very useful for this purpose.



  • @d-healey A/B button is used for fx plugins, not for instruments 🙂

    Yes, it's better to have API so the developers can customize their own preset menus.


Log in to reply
 

0
Online

277
Users

739
Topics

4.8k
Posts

Looks like your connection to Forum was lost, please wait while we try to reconnect.