-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update plugins to work as AudioPluginService.V2 plugins #116
Comments
It is a more fine-grained task list compared to #80. |
Here is a draft documentation for: AAP V2 Protocol changes RationaleAAP is going to support decent parameter changes with unified MIDI2 input events. It is a paradigm shift from traditional LV2 port to LV2 Atom or CLAP unified events. There are handful of reasons to make this change, but namely:
AAP uses MIDI 2.0 UMPs, it reuses the standard technology, compared to other technology like LV2 Atom or CLAP events. Parameter changs are sent as MIDI 2.0 Assignable Controllers. Breaking ChangesThis change leads to the new V2 protocol because it breaks plugin compatibility. AAPs that implement V1 is fundamentally incompatible with V2, and therefore they are not returns for V2 plugin queries (and vice versa). The details:
AAP-LV2 implementation
aap_metadata mappings
ports and events mappings on instance
AAP-JUCE implementation
|
For more details on how ports will be populated, see atsushieno/aap-core#116 (comment)
context: atsushieno/aap-core#116 The port mapping in the new `resetPorts()` does not crash MDA Ambiance (and probably a lot more in aap-mda-lv2) anymore. The actual process() needs rewrite as well, as it does not really translate parameter change MIDI2 events to ControlPort value changes.
aap-lv2 depends on #118 (need to retrieve ports). |
A fundamental problem was raised - Assignable Controllers are used for parameter changes, but when we convert MIDI1 bytes to UMPs, they are also used to achieve NRPN (and DTE) replacement, and it is kind of mandatory as the UMP specification states those MIDI1 messages SHOULD be translated to ACs. And mixing MIDI1 channel voice messages and MIDI2 channel voice messages is not MIDI2 compliant. The alternative method is to use universal sysex8 for those parameter changes. It is actually what atsushieno/augene-ng does for audio plugin parameter changes within UMPs. |
Some issues I found during migration from ACC to Sysex8:
|
context: #116 (comment) If we use Assignable Controllers (NRPN) to manipulate parameters, we will run into an issue: the plugin will not be able to receive NRPNs anymore. Assignable Controller message in UMP is new, but MIDI1 NRPN messages via Control Changes (NRPN and DTE) are supposed to be translated to them, which means that MIDI1 inputs to AAP (which is to be translated to UMPs at the entry gate) will be thrown into conflict: what is this AC? For parameters? or translated NRPN message? The latter is most likely just killed. This problem is just like how VST3 killed control changes: https://forums.steinberg.net/t/vst3-and-midi-cc-pitfall/201879 (though the impact is smaller) This will kill synths like traditional MIDI device emulator (like Roland Sound Canvas VA). Actually I once prepared for the possible conflicts and had an unused property (or function or whatsoever) in Parameters extension. There was `aap_parameters_mapping_policy` which indicates that the mapping is straightforward AC, or AC with the flipped top bit, implying that no one would use parameter index >32768. But it's still not a safe guess. Any plugin could use parameter index identity like that too. Therefore, this changeset contains an anternative fix: use sysex8 instead. The actual sysex8 format is described in `parameters.h`. And since syse8 does not contain "channel" and "key" (note), they are added as part of the sysex8 message content. It is still put within a 16 bits packet.
It seems aap-lv2 had regressed in main branch, aap-ayumi is not generating any output. |
^ is fixed. aap-fluidsynth works now. But aap-sfizz MidiDevice crashes. aap-string-machine plays well as a plugin, but MidiDevice generates super simple tone, which likely means that it does not set correct parameters. |
The latest status: aap-juce-obxd and aap-juce-dexed seem to work with aap-juce-plugin-host. aap-juce-hera seems broken, even on aaphostsample. |
|
|
We have aap-juce-frequalizer working. aap-juce-simple-reverb still does not reflect parameter changes on AudioPluginHost, maybe neither frequalizer (APH too crashy to connect multiple plugins and test outputs and parameter changes) though. We can investigate after the final 0.7.4 release work. |
With the latest 0.7.4 release I'm finally closing this issue. Those remaining tasks are logged as ^. |
On
main
branch, aapinstrumentsample is implemented to work as MIDI 1 synth. Other plugins are either not updated or cause runtime crashes. They have to be either fixed or rewritten to work as V2 plugin.Though, it kinda requires updating to the new scheme for parameter changes i.e. interpret MIDI2 inputs in realtime manner. That brings in unified event processing model with MIDI1 based inputs, and not everything is ready for that yet.
There are couple of sub-tasks:
PluginPreview
(and thus samples-host-engine and aaphostsample) to work with the new scheme if (1) there is a MIDI2 in port and (2) there are "parameters" (it was only partially implemented).PluginPreview
gets fixed and starts working fine, then it should also support (send) unified MIDI2 inputs to the instantiated plugin.The text was updated successfully, but these errors were encountered: