View Issue Details
|ID||Category||Date Submitted||Last Update|
|0004442||features||2011-11-03 16:41||2012-05-31 23:24|
|Fixed in Version|
|Summary||0004442: streamlined MIDI plugin browsing|
|Description||As it stands, when you insert a MIDI plugin into a MIDI track its a case of right-clicking in the MIDI track processor box -> New Plugin -> By Category then you browse either the 'Instruments', 'linuxVST' or 'VST' (or whatever the Category name for the wine VST plugins is called now). This isn't ideal from the start because the two VST menus show both audio (only) as well as MIDI plugins when of course you cannot insert audio only plugins into a MIDI track.|
What I'm proposing is that for the 'New Plugin' sub-menu within the processor box context menu for MIDI tracks we retain both 'Favorites' and 'Plugin Manager' as the top two options but then below that we get rid of both the 'By Creator' and 'By Category' submenus and replace these with having direct access to the 'Instrument' (which I'd like to see renamed 'LV2 instruments' or 'LV2 plugins' or even better just 'LV2'), 'linuxVST' (if I'm getting pedantic then I'd point out it should really be LinuxVST and LinuxDSP with a capital L but whatever), 'VST' and 'AU' submenus as appropriate.
I don't think the LV2 Instruments submenu requires any filtering but for both the VST submenus and the AU submenu the user only needs to see plugins that have a MIDI input when adding a plugin to a MIDI track.
|Tags||No tags attached.|
||clearly you've not tried this on OS X. under "By Category" there are up to a dozen different entries. does this change your position?|
Not at all because I mainly expect to be using A3 under Linux where I won't even be able to use AU plugins- the main problem here is not being able to easily distinguish which VST plugins you can use in a MIDI track but ideally you should only ever be presented with valid (MIDI) plugins anyway.
It may be useful to retain these AU categories and have them as submenus below the AU plugin menu if these categories apply in a useful way to AU MIDI plugins.
i think you missed my point.
the point is that on OS X you get to see the effect of plugins coming with category metadata, which is slowly arriving for LV2 as well. except that for AU's, the number of categories is tightly constrained. "Instrument" is just one of a potentially very large number of potential categories. I can see no justification for giving it special status compared with "Dynamics Processor" or "Delay" or "Reverb". Can you?
I forgot to mention how I've always used Ardour. When inserting plugins I have categorically always used 'By Category' to locate the desired plugin. Seeing this method has been in place for a number of years for the audio plugins then maybe we could retain this menu layout for audio plugins in A3 but maybe it could fall in line with what I'm proposing here for MIDI.
I've been thinking on this some more and if we're trying to streamline this process as I said in the subject line then actually I think 'Favorites' would do well to be moved from within the New Plugin submenu to being the second menu item down on the top level of the context menu instead, then Plugin Manager can become an option within the Favorites menu.
I'm glad to hear about AU the category metadata Paul, thats great, but surely it has categories that are relevant only to audio plugins? Within the New Plugin -> AU menu I would only want to see any plugins that have a MIDI input, whatever AU metadata category they might be classed within, but only the categories that contain valid plugins.
I think that you're still missing my point. You say you have "categorically always used "By Category" to locate the desired plugin". This is all very well IF the plugin you want has category meta-data. Nothing requires this. In the case of AU, almost all plugins do NOT have this data (yeah, unbelievable but thanks Apple). By Category becomes useless without category metadata.
Maybe we do it differently on different platforms.
I'm not suggesting there is any need to do it differently on different platforms- just as it is now the only real difference between browsing plugins under the Linux and OSX builds will be that under Linux there will be no AU submenu under New Plugin and, at least for 3.0, OSX users won't see any VST submenus.
I don't see the fact that not all AU plugins have category metadata being any real problem in this restructure. The top submenu under New Plugin -> AU should be 'All plugins' which would list every plugin installed alphabetically and then also within New Plugin -> AU you would have as many additional submenus as required to display any plugins that do contain category metadata. As I keep highlighting, all these submenus should only display plugins compatible with the track in question.
I see no reason why this same menu structure couldn't be applied to LV2, VST and LADSPA plugins too but maybe I'm missing something?
||i'm fairly strongly opposed to encouraging the notion of "browse by type". users don't care about plugin APIs. they care about functionality.|
There is a very good reason why we need to be able to see what type plugins are in/by the menus and that is interop.
What users of A3 need to be made aware of is that if they create sessions that use AU plugins these will be missing if that same session gets loaded on a Linux machine and the same being true for VSTs under OSX.
If the plugins are listed in menus by type then the user knows that if they just stick to LV2 and LADSPA plugins they can be pretty certain that session will open under both Linux and OSX provided those plugins are installed and working.
I wouldn't want plugins listed within type submenus below the 'Favorites' processor box context menu but I would still want to be able to see at a glance what type of plugin I was adding to a track so maybe it'd be best if the plugin type gets displayed in brackets after the name of the plugin under the Favorites menu? Displaying the type in brackets after the name would of course be redundant under the Add Plugin menus if they were already categorized into submenus by type.
|2011-11-03 16:41||danboid||New Issue|
|2011-11-03 17:08||cth103||cost||=> 0.00|
|2011-11-03 17:08||cth103||Target Version||=> 3.0|
|2011-11-03 21:53||paul||Note Added: 0011900|
|2011-11-03 23:45||danboid||Note Added: 0011903|
|2011-11-04 01:30||paul||Note Added: 0011904|
|2011-11-04 08:44||danboid||Note Added: 0011907|
|2011-12-02 02:31||paul||Note Added: 0012267|
|2011-12-02 11:27||danboid||Note Added: 0012272|
|2011-12-02 11:29||danboid||Note Edited: 0012272|
|2011-12-02 11:30||danboid||Note Edited: 0012272|
|2011-12-02 12:21||paul||Note Added: 0012273|
|2011-12-02 14:14||danboid||Note Added: 0012276|
|2011-12-03 14:31||danboid||Note Added: 0012289|
|2011-12-03 14:33||danboid||Note Edited: 0012289|
|2012-05-31 23:24||cth103||Target Version||3.0 => 3.X|