Open tresf opened 6 years ago
Ok, just a guess.. there are 500+ controls in zasfx A doable approach could be to set automation-options for the Instrument page controllers. Even that would be a huge improvement. UI-pages Voice and deeper UIs will be daunting And old related to this one would be #1965
Just as a note, maybe not all parameters should get automatable, since some can produce clicks. See, e.g., the effect controllers documentation. It's, however, a task zyn has to do, not LMMS.
One idea would be to forbid automizing parameters by adding a dedicated macro in the metadata. I guess blacklisting parameters would be preferable. @fundamental what do you think?
there are 500+ controls in zasfx
~4,000,000 uniquely controllable parameters if the last estimate was accurate.
One idea would be to forbid automizing parameters.
I wouldn't bother. As long a an OSC port exposes the 'parameter' property, then it should be expected to behave reasonably. If it doesn't, then that should be regarded in bugs/enhancement requests IMO (for many, but not all cases). There are some cases where it's practical to coarsely document the behavior, but I don't see the utility of putting the information in the metadata.
@fundamental ! 4 mio ! woooow That i would never have thought, but the number i guess is created, because of combinatoric relationships between 2 or even several individual controllers. How about the Actually physical controllers (dials sliders buttons) eg the types that are automated in lmms, do you have an estimate of that number?
With only one part, one kit, one voice, one oscillator harmonic, etc the number of controllable knobs/sliders/buttons/etc is somewhere between 400->1,000. I think the last time I ran a script on the OSC metadata it was mid-800s (see http://zynaddsubfx.sourceforge.net/zyn-ports/ to get a feel for the scale of things).
@fundamental Thanks! I have always felt i learned something new, each time i opened zasfx, and has often said, that a complete reference for zasfx would grof to several hundred pages. I guess that is a low estimate. Amazing synth and amazing job you do in your project!
I just wanted to add that this would likely be fixed by #6707 . If Lv2 would work on Mac and Windows (which it does, according to google, but that's the theory), then Lv2 will enable automating all controls.
If not, then Lv2 UI will only solve the issue on Linux. Though I do not know if VST/VST3/CLAP solve the problem for Mac and Windows.
I just wanted to add that this would likely be fixed by #6707 . If Lv2 would work on Mac and Windows (which it does, according to google, but that's the theory), then Lv2 will enable automating all controls.
If not, then Lv2 UI will only solve the issue on Linux. Though I do not know if VST/VST3/CLAP solve the problem for Mac and Windows.
Is LV2 planned to allow the existing ZYN presets to preview like they do today? Is LV2 the ultimate replacement to the ZYN integration code? If not, it may be trading one problem for another. If so, great. ♥️
I doubt it is possible to have all zasfx controllers on our VST-UI There are factual 1000'thds. A LMMS-UI would not only be HUGE, it would also be impossible to comprehend Zasfx are using really cryptic names -It is almost obfuscating worthy. Long ago i suggested that the empty tab on zasfx could contain like 12 dials, just as the ones we have on Tab-1. The huge and almost impossible question is What should be selected Choices must be made, because all will just be a mess
From https://zynaddsubfx.sourceforge.io/zyn-ports/, it appears that all controls have a path with "/" separators. This is similar to CLAP where parameters can specify a module path which allows them to be organized into a tree-like structure.
If I'm following this discussion correctly, a major issue with allowing users to automate all Zyn controls is the question of how all 1000+ of them would be presented to the user? If we organize them into a tree-like structure, this problem could be solved.
For example, here's the CLAP reference host neatly displaying hundreds of parameters from Surge XT in a tree structure:
I would love to see something similar in LMMS instead of just dumping all the controls into one space. There's a lot of room for improvement in the way we do things currently.
I think what we really need is a common way for all plugin controls to be organized and displayed. A plugin controls window that can be used by all our supported (or soon-to-be supported) plugins - LV2, VST2/3, CLAP, etc. One that organizes the controls into a tree structure for all plugins that support it.
Moved from https://github.com/LMMS/zynaddsubfx/issues/8, related to sourceforge/zynaddsubfx#41.
Quoting the original bug report;
Also related: #4179