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

realtime extension controller: support generic bidirectional messaging between host and plugin #73

Closed
atsushieno opened this issue Feb 22, 2021 · 3 comments
Closed

realtime extension controller: support generic bidirectional messaging between host and plugin #73

atsushieno opened this issue Feb 22, 2021 · 3 comments

Comments

@atsushieno
Copy link
Owner

As part of #44, I am thinking of basic bidirectional messaging functionality between host and plugin. It does not have to be implemented by every plugin, but certain kind of plugins will need it.

Messaging was not required in LV2 world, but that was because LV2 can simply use LV2 features with pointers that contain callback function pointers. We cannot use function pointers because the processes are isolated, so we would need AIDL based messaging (on Android).

The actual messaging format needs to be determined, but since we have MIDI 2.0 now its UMP is a good candidate.
@atsushieno
Copy link
Owner Author

Here are some thoughts.

Bidirectional messaging can be implemented just like existing connected ports. But since it does not have to be realtime, also it should be available before activate() step, there should be different messaging channels. A non-RT pair of control input port and notification port would suffice.

They can be also used by inputs from remote UI (or even local UI).

@atsushieno atsushieno mentioned this issue May 4, 2021
Closed
@atsushieno atsushieno reopened this Feb 16, 2022
This was referenced Feb 16, 2022
Closed
Closed
atsushieno added a commit that referenced this issue Feb 20, 2022
@atsushieno
Add a new document on new port design.
21edbb9 
context:

- #95
- #69
- #73
- #44
- #80
atsushieno added a commit that referenced this issue May 28, 2022
@atsushieno
Add setCallback() new operation in AIDL.
f7aa213 
It is to prepare for #73 and #95.

(Though depending on how we actually bind those callbacks, the Kotlin API
may be removed and transformed to hook into native listener.)
@atsushieno
Copy link
Owner Author

atsushieno commented Mar 8, 2023 •
edited
Loading

In 2023 things are clearer; on ACTIVE mode (see #145 for details), plugins do not really use "callback" but send notifications through MIDI2 output port, and on INACTIVE mode it is done via AudioPluginInterfaceCallback AIDL contract (to be verified).

It should be also noted that callback are not RT-safe.

atsushieno added a commit that referenced this issue Mar 18, 2023
@atsushieno
Revised AIDL for callback API.
685ed73 
Now it does receives `requestProcess()` instead of `notify()` that merely
requests host to call `process()`.

It is part of #73
atsushieno added a commit that referenced this issue Mar 19, 2023
@atsushieno
AIDL callback: bring back notify() equivalent, but renamed as hostExt…
e7fcd4e 
…ension().

It will be used if any host extension that should be transmitted to host
appears. So far there isn't.

Note that just like plugin extension() AIDL method, hostExtension() is not
realtime safe, and used only at INACTIVE state.

(context: #73 )
@atsushieno atsushieno changed the title support generic bidirectional messaging between host and plugin realtime extension controller: support generic bidirectional messaging between host and plugin Aug 27, 2023
@atsushieno atsushieno mentioned this issue Sep 5, 2023
Closed
10 tasks
@atsushieno
Copy link
Owner Author

We can finally mark this issue as completed.

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

No branches or pull requests
1 participant
@atsushieno