Cabbage Logo
Back to Cabbage Site

Presets.. once again.. again

#21

Yes, that looks quite nice. A one stop shop for all preset functions. I never thought of that :rofl:

[edit] So I guess all we really need is a single preset button that launches a menu that contains the various different bits of pieces. :thinking:

#22

I think that with a couple of directories, one for the factory and one for the user, it would be very comfortable.

You’ve summed it up perfectly :+1: It is the most comfortable and it is the system implemented in practically all plugins.

#23

I’m just working on this now. The cleanest way to provide sub-menus is to automatically create one for each folder in the current preset directory. If people foresee a potential problem with this approach let me know.

Also, the menu above doesn’t have any mechanism for removing presets, which can be useful, especially in the development stage. In this instance, the simplest thing to do would be to provide a ‘remove’ menu command that would open the preset directory, and let users select the preset file/files to remove.

I’m not sure about the copy and paste from clipboard stuff. Probably not applicable in our case.

#24

The number of folders will be generated at will?
In principle, these will be for factory service?
Could the user settings also have a different directory?

I think it will be comfortable for the user to open the root directory of the presets to remove them easily

It is not very necessary, and you can assess whether it is worth it by the degree of complexity it may have.

#25

yes, the developer can create a number of folder, or the end-user can create more folders as they wish.

Do you mean the presets that ship with a plugin? If so, yes.

It’s going to be completely dynamic so yes. Every time you hit the preset button it updates the menu with whatever it finds at that point of time in whatever folders are passed to it. We just have to make sure we can protect the ‘factory’ presets so that users can’t accidentally remove them.

So should I add a unique identifier for

userFolder("dir", "presetExtension")

and

facoryFolder("dir", "presetExtension")

with a special protectFactory(0/1) identifier that devs can enable before publishing a plugin? This would disable any modification of the factory folder by end-users.

#26

I have caught you on the fly :wink:

An extension for each file type would be convenient to differentiate the source and user presets.

That option always worked very well for me :+1:

#27

That will be up to you to decide. In this new system you can use whatever extensions you like. :+1:

#28

Great for conveniently organizing the entire preset system :+1:

Some kind of line of separation can be implemented?

#29

Yes, I already have line separators in :+1:

#30
  • If users don’t define a factoryFolder or userFolder, it will default to the current .csd directory.
    • On second thoughts, I think there shouldn’t be any default directories here. I think it’s best to have to define one or both. Otherwise you run into the issue of unwanted items in your current directory being loaded.
  • If users don’t define factory or user extensions, ‘snaps’ will be used
#31

Very logical! It is impossible something easier :grinning:

1 Like
#32

I see the menu for now …
new-presets

#33

Yes @Gerbo, much work yet to be done before you get to test :+1:

I’m guessing that the Load Preset Folder button should let users add a custom folder to the presets? So if, for example, one sets /User/home/presets for factory, and User/home/Document/presets for user presets, should the Load Preset Folder add yet another folder of presets to the menu, or replace the current user directory with another folder?

#34

More or less, this is what a majority of manufacturers do, at least on:

  • Mac:
    / Library / Application Support / Company Name / Plugin Name / FactoryPresets / “Different Instruments folders”

/ Library / Application Support / Company Name / Plugin Name / UserPresets /

  • Windows:
    C: / User / AppData / Roaming / Company Name / PluginName / FactoryPresets / “Different Instruments folders”

C: / User / AppData / Roaming / Company Name / PluginName / UserPresets

If there was the possibility that users could also create folders to organize their presets better than better :hugs:

#35

At the top (which could be the same surface to click), could there be some sort of display with the name of the preset? :thinking:

#36

You mean that the preset button might show the current preset name? That should be possible. I would like for users to be able to control the appearance of the preset button with Csound, as they can other buttons.

And this is exactly where I would recommend users to save presets. I think it’s up to the plugin installers to create these default locations, which Cabbage can then pick up.

#37

For example, on Mac with Packages, there is no problem for installation in Application Support.
In Windows with Inno Setup and in the Roaming folder, I have presets hosted in that directory working without problems.

It would be very good, if it could have the same settings as any button, as long as it is continuously active :rofl:

#38

Another issue has surfaced here. When I select ‘save preset’ where should it save? In the user folder, or the factory folder? I’m starting to think that the factory folder should be read only.

A developer who is creating presets for their synth can save presets in the user folder. When they are ready for distribution they can move them to the factory folder. This would mean I don’t have to add any protection to the factory folder, as it will always be read-only. Moving your presets is a slight inconvenience, but it makes things simpler in Cabbage, which makes things easier to maintain, and less prone to bugs. @gerbo, what do you think?

#39

The settings to save are those of the user. Factory folders are read-only. If instead of protecting them with the previous system, they are implemented directly read-only, much better.

That we have to move the presets from the user folder to the factory folder is a lesser evil. Don’t worry @rorywalsh because that’s not inconvenient.

1 Like
#40

Ok @gerbo, I have something for you to test. I just triggered a new build now so it will take about 30 minutes to cook. The new presetbutton widget comes with a few new identifiers:

  • textColour() - sets the colour of the menu items text (fontColour() is still used to set the button font colour
  • highlightedItemColour() - the colour of a menu item when the mouse is hovering over it
  • highlightedTextColour() - the colour of a menu item’s text when the mouse is hovering over it
  • presetNameAsText(val) - sets whether the presetbutton will have its text set automatically when a user changes preset. This will cause the button text to update regardless of whether Csound is running or not. So users of plugin effects in Logic and Cubase can see what preset is selected even if a session if not running.
  • userFolder("folder", "extension") - a user folder for saving and reading presets from. This can be passed a folder macro, which makes managing preset locations a little easier.
  • factoryFolder("folder", "extension") - a factory folder for presets. This is read only and can’t be modified by Cabbage. This can also be passed a folder macro.

The following example illustrate:

  • Loading and saving presets
  • How submenus are created from sub folders
  • Dynamically setting a presets from the Csound orchestra (especially for @flaviogaete) -

    must be given a full path…

  • Retrieving the current preset

    will always return a full path…

  • Dynamically updating a label with the current preset name

Let me know how it goes. I don’t think it’s anywhere near production ready, but it’s a good start :wink:

3 Likes
Confused about presets