Skip to content
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.

Sign up for GitHub

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

Jump to bottom

implement realtime extension support: AAPXS SysEx8 #169

Closed
10 tasks done
atsushieno opened this issue Sep 5, 2023 · 6 comments
Closed
10 tasks done

implement realtime extension support: AAPXS SysEx8 #169

atsushieno opened this issue Sep 5, 2023 · 6 comments
Labels
extension

Comments

@atsushieno
Copy link
Owner

atsushieno commented Sep 5, 2023 •
edited
Loading

As it has been written in several issues and documents (e.g. issue #73, issue #145, issue #158), current Binder-based extension() support does not cover realtime usage scenario and they should be covered as in MIDI2 system exclusive messages at process().

Now that we have refresh implementation for plugin manager with aap::MidiDestinationNode which is ready to be used in aap::PluginPlayer, it is time to actually implement it.

There are handful of blocks that need new code:

  • `PluginPlayer needs to provide users ways to handle its MIDI2 outputs, either via event handler or provide direct buffer to MIDI outputs.
  • cmidi2 needs sysex8 data extraction feature
  • implement MIDI2 AAPXS SysEx8 parser and generator
  • MIDI AAPXS service needs to parse MIDI2 sysex8 inputs into extension invocation, serialized as extension bytes.
  • aap::LocalPluginInstance needs to integrate this MIDI input parsing support.
  • MIDI AAPXS client needs to generate MIDI inputs from extension invocation, serialized as extension bytes. -> post-0.7.8 task
  • aap::RemotePluginInstance needs to integrate this MIDI output generation support.
  • the new plugin manager needs to implement realtime extension invocation. MIDI Program Change is a good example for this (involves preset setter).
  • There should be asynchronous callback support in every async-ified (non-RT) extension function, and they need to be invoked at each AAPXS implementation.
  • C++ wrappers in standard-extensions.h and its implementation also needs async-ification.

Unless it is going to be too complicated, it should be done before 0.7.8 release.
@atsushieno
Copy link
Owner Author

A few additional notes:

  • a host that supports MIDI2 realtime extension needs to "copy" the parsed data into AAPXSServiceInstance, as the AAPXSServiceInstance might make use of the shared data within its context.
  • likewise, the host would need to retrieve the "result" data AAPXSClientInstance shared memory.

atsushieno added a commit that referenced this issue Sep 6, 2023
@atsushieno
bump cmidi2 and add AAPXS MIDI2 sysex8 parser and generator (WIP).
ebc7664 
context: #169

The SysEx8 parser and generator implementation is still standalone.
They need to be integrated to `AAPXS[Client|Service]Instance`.

It makes use of new cmidi2 functions for SysEx8 parser, so bump cmidi2 too.
@atsushieno atsushieno mentioned this issue Sep 8, 2023
Closed
atsushieno added a commit that referenced this issue Sep 8, 2023
@atsushieno
implement AAPXS SysEx8 generator support, up to the new plugin manage…
1663b90 
…r (WIP)

context: #169

Unlike service side, the client side needs to handle it at app level.

It is still not verified, as it turned out that we do not have any feature
that triggers preset setter in the current manager UI. We need to add it.
@atsushieno
Copy link
Owner Author

Unless it is going to be too complicated, it should be done before 0.7.8 release.

As issues #171 is post-0.7.8 work, the entire work is inherently moved to post-0.7.8 as well. Until then, we will have proof-of-concept setPresetIndex() call at aap::AudioPluginNode::setPresetIndex(int index) to conditionally generate AAPXS SysEx8 and send it.

atsushieno added a commit that referenced this issue Sep 13, 2023
@atsushieno
bump cmidi2. Implement realtime-safe-ish set_preset operation in Plug…
c88c596 
…inPlayer.

Everything is still hacky; we should bring in another wrapping layer around
AAPXSClientInstance. context:

- #170 (comment)
- #171
- #175
- #169 (comment)

The code still does not bring in fairly good RT safety because it looks up
interned URI (because we cannot intern extension URIs that are sent by the
client). We will have to come up with something like LV2 URIDs and/or
reserved extension URI mappings (like well known TCP ports).

As for 0.7.8, this PoC would suffice.
atsushieno added a commit that referenced this issue Sep 29, 2023
@atsushieno
[WIP] async realtime AAPXS work.
fd1e00f 
It implements basic workflow for asynchronous realtime AAPXS support. context:

#169
#176
@atsushieno atsushieno changed the title implement realtime extension support implement realtime extension support: AAPXS SysEx8 Oct 7, 2023
atsushieno added a commit that referenced this issue Oct 13, 2023
@atsushieno
async-ify get_preset() and implement the rest of realtime AAPXS stuff.
fe77786 
Regarding these issues:

#182

`get_preset()` now takes async callback arguments, so every relevant parts
needed to be updated too. This was a big chunk of breaking changes.

#176

Since our AAPXS client handler API is not async-ified, it still works in
synchronous mode, but the extension functionality is basically back (in that
preset list retrieval is fully functional again).

We likely need to revamp the overall AAPXS stuff (especially the whole
foundation behind StandardExtensions is synchronous), but we recover the
basic functionality first in this commit.

#169

The client side code is, as explained above, hacky overall, but there is
certain progress.
@atsushieno
Copy link
Owner Author

Most of the work is now done in aapxs-v080 branch, but I noticed that binder-client-as-plugin's get_extension() requires public extension API implementation for each AAPXS. It also needs to be provided by each AAPXS developer.

It is possible to achieve that by TypedAAPXS implementation classes, but that requires AAPXSDispatcher and its instantiated shared memory buffers, while AAPXSDefinition itself is basically all statically resolved. We likely need to provide another way to instantiate the registry, kind of.

@atsushieno
Copy link
Owner Author

^ is resolved as get_plugin_extension_proxy() member function in AAPXSDefinition.

@atsushieno
Copy link
Owner Author

We can close this issue once aapxs-v080 branch is merged to main.

@atsushieno
Copy link
Owner Author

It is now merged into main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
extension
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@atsushieno