FabFilter User Forum
Pro-Q 3 Suggestion: previous- and next band buttons
I’m guessing here, but I think this is due to automation... if you automate one band, then add another but the number changes, this will screw up your automation. Or, if you would have different id’s only in the GUI, make you guess which band you have been automating.
At least in VST2 an automation parameter is remembered by its index, not an id. Reordering/adding new parameter in between is therefore not possible and would mess up all automation data.
It would be very confusing having a band reordered/renamed to #3 in the interface, but its automation is still the parameter for band #7.
Seems like both of you are right about the lack of internal IDs in VST2.
VST3 is providing this feature - as long as the information an KVR is right.
"A really nice feature is the fact that parameter are referenced by a unique id, and not a zero-based index as in VST2. Makes it very simple to add/remove parameters without breaking compatibility and automation especially."
www.kvraudio.com/forum/viewtopic.php?f=33&t=204365&start=60
("funny" how everybody is complaining about VST3 in the linked thread :D)
Explains why this feature is missing in VST2. But would be nice to implement it to the VST3 version. :)
Bram is right, we are doing this so existing automation keeps working correctly. Even with VST3, it wouldn't be possible to do this. It doesn't really matter whether the host is referencing parameters by index, id, or name: when you delete say band 2, and you want band 3 to become band 2, you're essentially changing the meaning of the parameters. So any existing automation on band 3 would no longer work. This is actually how Pro-Q 1 worked and you had to remember to never delete bands if there was any recorded automation.
@NK: Numbering from left to right would even be more problematic. What if you move bands past each other? Would their number change in this case? This is only feasible if the numbering in the interface would be different from how the host sees the parameters, but that, in turn, would make automation very difficult to understand since the parameter names in the host would not map to the names in the interface.
Cheers,
What if you changed only the function of the arrow buttons so they would always go to the lower or higher band and ignore the index / ID?
This shouldn't break any automation or old projects.
Good point Antti! Dont use the number at all, just go for the frequence.
About the internal ID: of course an internal ID and a caption would let you take care of adding, deleting and editing/changing frequency.
Simple example:
Add 3 Bands, following order:
Band 1, frequency: 100Hz
ID: 001_freq
Caption: Band 1, frequency
Band 2, frequency: 200Hz
ID: 002_freq
Caption: Band 2, frequency
Band 3, frequency: 300Hz
ID: 003_freq
Caption: Band 1, frequence
Change Band 1 to 400Hz
Band 2, frequency: 200Hz
ID: 002_freq
Caption: Band 1, frequency
Band 3, frequency: 300Hz
ID: 003_freq
Caption: Band 2, frequence
Band 1, frequency: 400Hz
ID: 001_freq
Caption: Band 3, frequency
Add Band 4, frequency 250Hz
Band 2, frequency: 200Hz
ID: 002_freq
Caption: Band 1, frequency
Band 4, frequency: 250Hz
ID: 004_freq
Caption: Band 2, frequency
Band 3, frequency: 300Hz
ID: 003_freq
Caption: Band 3, frequency
Band 1, frequency: 400Hz
ID: 001_freq
Caption: Band 4, frequency
So everytime you add/delete a band or change a frequency you would sort them again and change the captions only. And if you want to be really comfortable you provide the user with a ascending/descending/no resorting option.
Actually this is standard design when coding (at least I thougt so) - I am quite astonished it doesn't seem to be standard for VST interfaces.
But never mind, definetely not the most important feature - there are other things to concentrate on.
Best regards
NK
@NK: The problem with your solution is that in the host, when editing or viewing parameters, you would see "001_freq" as the parameter name, which could e.g. map to Band 4 Frequency. That would be very hard to work with when editing automation.
@Antii: The prev/next buttons in the band controls in Pro-Q already work like this and will go to the band directly to the left or right. :)
Cheers,
What can I say - blame on me. Sorry for the confusion!
Somehow I overlooked, that the bands are already sorted by frequency for the previous/next buttons. I just focused on the numbers, my fault.
I am still wondering about the poor interface design, which won't allow plugin developers to provide the host with internal ID + caption (this makes a lot of sense for macro controls of synths e.g.) - but that's another topic and nothing FabFilter can do anything about.
There would be only one thing to consider - may be add a small number to the EQ band dots, like other companys do? So you always have at sight, which number you are searching for in the parameter list?
Cheers,
NK
Hi there,
Request: I would like to see the bands be numbered from left to right - no matter of the sequence I add them.
Right now I can't imagine somebody is able to use this button and know the order for each EQ instance in the project.
Quoting the manual here:
"Note: When creating new bands, they will be numbered 1, 2, 3 and so on. But when you delete a band, the others won't renumber, in order to ensure that currently written automation in your host still controls the correct band."
I understand what you are saying here - I do not understand, why.
As a programmer I am used to have internal IDs for objects, which are fixed and refered to by other parts of the code - and by interfaces as well. Further there are descriptions/names, which are editable (in this case 1 could turn into 2, if a low cut is added). Ideally this second information is provided to the interface as well.
I do not know how those interfaces are designed here and if you can't change stuff because of the interface design. But it does not feel like the "FabFilter-way" right know. May be there is a way to change things?
Best regards and keep up the good work,
NK