Audacity Forum

solanus wrote: - People are far more likely to complain than to compliment, so I suspect that you will always have a vocal disgruntled minority and a silent satisfied majority with categories.

Actually solanus it was mainly Audacity testers, QA, documenters (mainly power users) who complained about the increased clicking that was required that led to its removal as an experimental feature.

IIRC the code for this still exists in Audacity, but turned off, but really can't be turned on again until the further flexibility discussed in the Wiki proposal is tackled.

Peter

waxcylinder wrote:Actually solanus it was mainly Audacity testers, QA, documenters (mainly power users) who complained about the increased clicking that was required that led to its removal as an experimental feature.

For the record, I was, and still am, very much in favour of grouping plug-ins, though I agree that the first attempt at implementing this was awkward to the point of distraction.

solanus wrote:On Linux, if the list of effects runs offscreen, it automatically creates generically named submenus that allow you to mouse over them and open them horizontally, so at least you can see the effects on screen with a simple mouseover and click instead of scroll scroll scroll scroll scroll scroll.

In one way the way it works on Windows is better than how it woks on Linux. If, say, you want to use the Vocoder effect, on Linux I have to scroll down the list and try to remember which of the numbered groups it is in. On Windows I can just type "V" and immediately the list is scrolled down to plug-ins beginning with V.

solanus wrote:even if most of the developers work exclusively on Linux,

They don't. Most of the developers work on Windows.

solanus wrote:and I expect that there are at least as many (if not more) users running Audacity on Windows.

Yes, there are a lot more downloads for the Windows build than any other.

solanus wrote: I take issue with this statement there: Categorisation has a penalty in more difficult navigation.

That certainly was the case with the original implementation, though I agree that it does not have to be (and should not be) the case.

solanus wrote:I really wish the Audacity developers would take this seriously.

It's not a question of taking it seriously. Creating a cross-platform solution is not easy, and there are a limited number of developers with a limited amount of time.
Fortunately, some of the obstacles for achieving a good solution have now been resolved - handling the loading of VST plug-ins has been improved, as has the handling of keyboard shortcuts to effects. Achieving a good solution is not just a matter of wanting a solution, but also having the resources to develop the solution. As Audacity is a free program, its resources come primarily from the time, effort, skills and money that users donate.

steve wrote: ... As Audacity is a free program, its resources come primarily from the time, effort, skills and money that users donate.

My understanding is that if any user felt strongly enough to want to pay, probably at commercial rates, an Audacity developer for a new or modified feature then it would probably get picked up (provided the feature was feasible, useful and didn't cause a regression)

WC

solanus wrote:I do think it is insanity.

You're on Linux. Exactly what it is stopping you compiling Audacity with the feature turned back on? Do you need help compiling Audacity? What version of Linux do you have?


Gale

Actually, my Linux box is dead, and I'm back on Windows.
Sorry if I seem like I'm ranting. I love experimenting with effects, and there are so many out there that I'd love to work with, if they were only more easily accessible.
I'm not much of a coder, and the original categories were kind of clunky, so I don't know how much good it would be to turn on the old code, anyway.
I know you don't have many developers, which I find a little baffling, because the project is so cool; I'd think more talented people would have wanted to be a part of it.
I guess I'll just wait until you have the time.

Thanks for an excellent app.

solanus wrote:Sorry if I seem like I'm ranting.

This isn't "ranting" - this is debate, and useful debate too

Also for the record, like Steve I too am in favour of grouping plugins and structured/tiered effects as the list is quite long now. But as Steve pointed out the original test implementation in a Beta version of Audacity had its shortcomings (not least for visually impaired users).

The problem in moving this forward is that I don't think the details of how the ideas for required changes (toggle list/tiered, favourites, user-modifiable groups, optional plugin management etc) have been thought about and hammered out.

For my money just moving to the simple expedient of having a toggleable choice between the current long list and structured/tiered groups would be a good first move. But I suspect that if changes are made a developer is likely to want to consider the whole issue in one go rather than taking a baby-steps approach.

WC

@Solanus: if you have a small group of effects that you want to experiment with at any one time you could always consider setting temporary keyboard shortcuts for them, as that will make access to them quick and easy.

BTW if you are up for using the alpha version of 2.0.6 then you will find that we have a revised version of the interface for management of keyboard shortcuts which I, personally, is much improved over the current interface.

WC

Thanks. I suspect that had I easy access to all the effects, I would eventually settle on a smaller subset that I find more useful than others.
I think I'll have to set up a list of all the effects on a spreadsheet for reference, and take a few weeks to try out them all to weed out the redundant or less useful ones. When I end up with a list of favorites, I'll just uninstall the ones I don't want, to make the menu a bit more manageable.
Keyboard shortcuts are a good idea, but I prefer to also have them in a menu, or a toolbar with popup descriptions - that way I can see the name and rely less on my less-than-stellar memory.

If this was only about "Nyquist Plug-ins", then it would be an easy problem to solve. The Nyquist Plug-ins are invariably open source, and we can modify them to set a category/group for each effect. Audacity then just reads the category/group "tag" and could move it into the appropriate sub-menu. It would even be possible for Audacity to modify that "tag" and so make user custom groups possible. The big problem comes from the fact that there are lots of plug-ins that are not open source, not from Audacity and cannot (legally or practically) be modified. That's why, even when we had categories, a lot of plug-ins were in one big "unsorted" group.

The problem is not impossible, but it's not easy either.

The solution may well be that the user is given a method to group their own plug-ins if they want to, by drag and drop and/or a dialogue, then user must by definition be satisfied with the grouping.

The original implementation ignored VST's altogether so it was fatally flawed from the outset. Audacity could do some kind of crude grouping with VST's based on the vendor name or plug-in name (without modifying the plug-in), but that will never be perfect.

The idea of Audacity recognising a user-created folder structure in its Plug-Ins folder is attractive, but partial. Plug-ins in system folders couldn't be grouped, notably Mac OS X Audio Units which can only be in system folders.


Gale