extensions should provide message size for appropriately sized AAPXS SysEx8 [BREAKING CHANGE] #171
Labels
Comments
|
At this state, this should be done as post-7.8 task. |
|
One thing to note here is that "MIDI2 or Binder" implementation should be kept host implementation agnostic; we cannot add any code that references |
10 tasks
atsushieno
added a commit
that referenced
this issue
Sep 13, 2023
…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 25, 2023
…sage() context: #171 Since this did not break ABI compatibility with aap-core 0.7.8, there is no changes in those extension URIs this time. Verified interoperability between 0.7.9-pre aaphostsample and 0.7.8 aap-lv2-mda plugins. It is still breaking API change and aapxssample is indeed affected.
|
This particular task is done as ^ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally noted at #170 (comment): we need "size" of extension data to be transferred to the recipient as well as realtime-safe AAPXS client host so that it can generate AAPXS SysEx8 messages without unknown sizes.
This will involve API breakage in AAPXS (but we do not have to break the V3 protocol unless we add size information to the AIDL level, which is unnecessary so far - we do not dare to break the protocol with past plugins).
Changes are e.g.
void aap::RemotePluginInstance::sendExtensionMessage(const char *uri, int32_t opcode)-> addint32_t sizeparameter.The text was updated successfully, but these errors were encountered: