Having the capability to give users the opportunity to reorder or sort the user presets list would be helpful. If you would be able to add the Filterverse version of the preset editing, with its sort routine, it would be advantageous. I currently do this stuff in an .xml editor, Notepad++, but it is tedious and mistakes are easy to make if not paying attention. The Filterverse version makes that work unnecessary.
This same issue exists with Gatekeeper, the factory presets are always at the top of the preset dropdown menu, and there is no method to sort or order the presets. Filterverse’s tool would be great to have here too.
Almost all of the special characters are not allowed in the preset name, at least in Windows version, perhaps this could be changed? When useful, I like to add parameter information into preset names, beyond numbers and colloquial identifiers. Underscore and hyphen are there, but I am hoping for more.
Windows 10 doesn’t allow these
/ \ : * ? " < > |
but tilde, bang, plus, ampersand are useful shorthand, brackets, parenthesis too.
Manipulator has about 200 parameters for MIDI control, Gatekeeper VST3 has about 400 parameters, Filterverse VST3 has about 1900 parameters available in my VST host. Most of those would never be used, but it is nice have the options. Would there be any method available to the user to preliminarily choose to make some of those parameters available and filtering out others, so that the process of MIDI control is a little more simplified?
We already working on the preset browser update for all our plugins. All our plugins will have a similar preset browser and preset sorting capabilities as the Filterverse.
I forwarded this suggestion to the team.
It’s not possible to filter the parameters list displayed in your DAW. This is a feature that DAW developers need to implement.
Thank you Adrian.
One additional comment about Gatekeeper - when in TIME mode, and attempting to enter exact values into the modulation field, the field will not accept “.” (decimal point), and it absolutely will not accept the numeral 9. So a workaround is possible for both of these issues, just adjust the fader to something with a decimal point and use that as a starting point, and in the case of the 9, again use the fader to get a 9, and go from there. Or a more fun method is to utilize the function behind the exposed text box - enter an 8 followed by 2 or more places of 8, and it will round up to 9. The issue with the 9 is more like a bug than a designed behavior, while the decimal point issue seems more like a simple character omission.