BACKGROUND: Too many 'enabled' plugins eat up DSP; so logic was created in LP to make plugins 'IDLE'. The documentation literally says, and I quote: "Audio Units that are muted", will enter idle (state)...... This isn't clear. My audio units, and I have over 50, do not have inherently have a mute button on them. I kind of assume the documentation means that Audio Units in a channel, where the channel is muted are put into an idle state.

 First Issue: this creates what appears to be 3 states for plugins. From the UI perspective there are "enable" and "disable" states, but there is nothing in the UI about "idle" - this is very confusing.  I can assure you - this will be confusing to many users, not just myself. 

Second Issue:  The idle functionality "seems" (not certain on this) based on an assumption that a user will ALWAYS mute a channel if they do not want to use the plugins in that channel. This is simply not true. I send audio to a channel with a plugin a called A2M (Audio 2 MIDI), and I send the audio to turn it the audio into a MIDI note. I do not want audio to come out of the channel, I only want it turned into MIDI notes.   I hope this helps show that this "assumption" that muting a channel means the plugins should be idle. 

Third Issue: The idle functionality doesn't even reduce the DSP as much as it could. EXAMPLE: I have 4 audio buses that I use as presets. Each audio bus has 4 -8 plugins. I use a router on the input channel to route my audio to the one audio bus I want to use as my current preset.  All of the other audio busses not being currently used are not muted, so based on the documentation (and I could be wrong, because it's not clear); none of the plugins in the other audio channels get set to idle.  So I contend that you are not getting the expected benefit out of idle.... UNLESS, a user knows about it, understands how it works and mutes something (exactly what isn't clear)

I WANT TO APOLOGIZE:  I spend 20 minutes sending audio to a plugin (the Audio 2 MIDI plugin) that the LP logic had set to IDLE and I couldn't get the plugin to work because the channel the plugin was in (an audio bus) was muted.  So I sooOOOo frustrated, and I posted a rant on FB.  But PLEASE, PLEASE - read my comment above "Second Issue". The logic or assumption that if a channel is muted means the plugins should be idle, is not valid. 

 OVERALL - Here's the reason for this feature request. There is NO WAY or no logic that can figure out HOW people (users) are going to use the software. Wanting to conserve DSP is noble, good, honorable. But you CAN NOT somehow "know" what users will or won't do. As new features are added, this becomes even more and more true. I see other feature requests like routing an audio bus to another audio bus. There's no way to tell what users will do.  MORE IMPORTANTLY: As I understand the documentation, there may be very little tangible benefit or DSP reduction from this feature; and zero compared to the confusion it causes.       

       THEREFORE (since you have no idea what users will do or not, and since you shouldn't assume they will mute something or not): You should: 

(1) Show the DSP usage on the screen [AUM does this now] - a CRITICAL must have

(2) When, and only when a project is saved; it saves the enable and disabled state of every last plugin in the project

(3) There are ONLY two states of a plugin: enabled or disabled (get rid of the idle state, and it is a state of a plugin)

(4) The state of each and every plugin is determined by user action (to some extent it is right now, but the idle state doesn't appear in the UI, and isn't explained well in the documentation, and if /when a user doesn't know how a plugin became idle they will get irate because they themselves didn't ask for it, or "set" the state of the plugin to be idle, the software did it)

4a) When a user saves a project; the state (enabled or disabled) of every plugin is the state the plugins will be at when it is opened up; the user can see the DSP usage and "buyer beware".

(4b) When a user creates an action in the UI, or a MIDI command to trigger the action - to enable or disable a plugin (or toggle) it will change state

(5) VERY IMPORTANT - allow groupings of plugins in a single channel, where channel means: audio bus, input channel, master channel, loop color grouped channel; such that the group behavior affects all of the plugins in a group. NOTE that there is already a feature request for this I believe - something allow grouping to plugins to allow one action to be applied to all the plugins in the group. Make it easy for a user to change a group of plugins to/from enabled or disabled.

5a) Remember that some plugins can be used in more than one channel; it would seem prudent to exclude these plugins or give the user the option to exclude these plugins from the group.

        EXAMPLE: Audio Bus D has 7 plugins. The first 3 plugins which are in Audio Bus D, are also on Audio Bus A and are enabled and being used. The user executes a single action, as in STEP 4 above, to disable all of the plugins in Audio Bus D, in this one action the remaining 4 plugins not already in use in Audio Bus A are disabled.

         looking back at item number 1) the user can see the DSP usage and so "buyer beware"

(6) Simplistic visual recognition of the state (enabled or disabled) of a plugin. This is a previously requested feature. In AUM where there is more screen real estate, they have disabled plugins off to the side of the channel. You can decide how best to implement this, but if I look at an channel and there are 9 plugins, or let me say 9 plugin ICONS are visible. There MUST be a way to instantly recognize which are enabled or disabled. There are LIMITS to this, as many times I have too many plugins in a single to visually see them all in one glance. But it should be easier than "opening up" each plugin to see it's enable or disabled state.

ALL of these steps MUST work together to adequately manage the enabled /disabled state of all plugins in a project. I feel like the current logic around making a plugin idle:

* is confusing at best, even with the documentation  - see the attached picture which talks about muting a plugin??

* provides little if any benefit

* creates what is really a tri-state plugin (this is very confusing)

* isn't seen or understood or even expressed in the UI at all (more confusion)

ESPECIALLY as more features are added to the software, like routing audio from one audio bus to another..... the above statements become even more valid. While the concept of trying to have the software manage DSP, or help to manage it, is good; you really have to give the user tools to make it easy, and put it onto their plate.

Currently (12/09/23) the user CAN NOT instantaneously tell what state plugins are in by glancing at the screen. The user CAN NOT tell how much DSP is being used.

Thank You!!

Attachments