osc: Send /select/plugin plugin_id feedback #897
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'm also working on making the documentation on plugin parameters in the manual complete, I'll add a commit (or maybe separate PR) to document this change as well when it is merged. edit: Initial documentation PR is here: Ardour/manual#266, documentation for plugin_id feedback can be added on top of that later. |
Previously, this happend in _sel_plugin when the selected plugin
changed (which was called at the end of _strip_select2 too). By moving
this code:
1. The list of plugins is only updated when the strip changes, and not
when just the selected plugin changes (in which the case the
selected strip and list of plugins remains the same, so this saves
unneeded work).
2. The list of plugins is updated earlier, which allows it to be used
by OSCSelectObserver (in the next commit).
3. The list of plugins is cleared when no strip is selected.
There are two ways to identify a plugin:
1. The user-visible number, usually named "piid". This is a 1-based
index into the list of visible, non-channelstrip plugins only.
2. The plugin id. This is a 1-based index into the list of all plugins as passed to nth_plugin
The sur->plugins vector is used to translate the former into the latter.
Previously, the latter, already translated, index was passed to
OSCSelectObserver to indicate the currently selected plugin. To prepare
for sending the piid of the selected plugin in a feedback message (in
the next commit), this commit moves the translation of piid to plugin id
into OSCSelectObserver.
To emphasize the new meaning of the plug_id variable, it is renamed to
selected_piid. Also, since the piid is 1-based, change it to a uint32_t
and use 0 to mean "no plugin selected" instead of -1.
This commit is expected to subtly change behaviour: When selecting
a different strip, OSCSelectObserver would (via OSC::_strip_select2 and
refresh_strip) send feedback for the plugin with the same plugin id as
the previously selected plugin. Then OSC::_strip_select2 would do the
piid to plugin id translation for the new strip and call set_plugin,
causing a second round of feedback for the plugin with the same piid as
the previously selected plugin.
If the new strip has hidden plugins (i.e. piid and plugin id do not
match), this could mean that you get feedback for two different plugins.
With this commit applied, the translation happens in both cases and the
feedback returned should be for the same plugin twice.
Whenever the active plugin changes (because the plugin changes or the selected strip changes), the name, some other properties and parameter values for the newly selected plugin is sent as feedback. However, there was no clear indication of which plugin was selected exactly. Applications or surfaces that need to know the active plugin could track the currently selected plugin by remembering the most recently selected index, but unexpected plugin changes (e.g. when switching to a strip with fewer plugins) and the asynchronous nature of OSC messages make this more complicated than it should be. By sending the active plugin id as feedback, clients do not have to guess. When no plugin is selected (e.g. on startup or when no strip is selected) or the currently selected index is not a plugin (but a some other kind of processor), a value of 0 is sent. This uses the `/select/plugin` message, which is also used to change the selected plugin. There is a slight discrepancy: the control messages accepts a delta on the selected plugin, while the feedback sends an absolute value.
matthijskooijman
force-pushed
the
add-select-plugin-feedback
branch
from
748d8e6
to
b786aa7
Compare
|
I realized that there are actually two ways to identify a plugin:
The I've added two additional refactoring commits to this PR to fix this and make sure that the right identifier is returned. I have not actually been able to test this, since these two identifiers are usually the same, except for:
Any suggestions on a way to trigger situation 2. are welcome. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whenever the active plugin changes (because the plugin changes or the selected strip changes), the name, some other properties and parameter values for the newly selected plugin is sent as feedback. However, there was no clear indication of which plugin was selected exactly.
Applications or surfaces that need to know the active plugin could track the currently selected plugin by remembering the most recently selected index, but unexpected plugin changes (e.g. when switching to a strip with fewer plugins) and the asynchronous nature of OSC messages make this more complicated than it should be.
By sending the active plugin id as feedback, clients do not have to guess.
When no plugin is selected (e.g. on startup or when no strip is selected) or the currently selected index is not a plugin (but a some other kind of processor), a value of -1 is sent.
This uses the
/select/pluginmessage, which is also used to change the selected plugin. There is a slight discrepancy: the control messages accepts a delta on the selected plugin, while the feedback sends an absolute value.