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

CLAP: add macro to use MIDI MPE dialect #443

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

CLAP: add macro to use MIDI MPE dialect #443

wants to merge 2 commits into from

Conversation

jfrey-xx
Copy link

@jfrey-xx jfrey-xx commented Dec 9, 2023

This is related to #441

In the end I could not help but try a little something. At first I wanted to let people select any of the different dialects, but I was not sure how to properly retrieve the definitions in DPF (include the corresponding CLAP header or duplicate its #define somewhere? Neither seemed pretty). So I settled with just the "MPE" option for now, especially considering that the other dialects (MDI 2 or CLAP) might need to be properly parsed to reach the plugin.

Then I started to add flags to let user configure MPE for input or output separately, to declare it as supported only (and not "preferred")... but that started to look bloated without other use cases.

Hence the trivial modification. I still hope that can be of some help. I tried my best to mimic how the flags are set. Tell me if I can improve something.

@falkTX
Copy link
Contributor

falkTX commented Dec 9, 2023

While I agree with the base idea, I think making this clap specific is wrong.
Best to me seems to have a generic hint (0/off by default if unset) to report a plugin as supporting MPE. Then DPF takes care that the host knows about this, which is already covered here for CLAP.
The value is only a hint anyway, so it is fine to be generic.

1 similar comment
@falkTX
Copy link
Contributor

falkTX commented Dec 9, 2023

While I agree with the base idea, I think making this clap specific is wrong.
Best to me seems to have a generic hint (0/off by default if unset) to report a plugin as supporting MPE. Then DPF takes care that the host knows about this, which is already covered here for CLAP.
The value is only a hint anyway, so it is fine to be generic.

@falkTX
Copy link
Contributor

falkTX commented Dec 9, 2023

also please make the PR target develop branch, not main.
new commits should always go into develop first. thanks

@falkTX
Copy link
Contributor

falkTX commented Dec 9, 2023

actually I think the best is to have default value as "undefined", where we do nothing special if unset.
but plugins can manually specify through 0 or 1 value that they support MPE (or not)

most plugin specs dont have a way to report this property anyhow

@jfrey-xx jfrey-xx changed the base branch from main to develop December 10, 2023 09:21
@jfrey-xx
Copy link
Author

jfrey-xx commented Dec 10, 2023 •
edited
Loading

Thanks for the feedback! I rebased on develop and used a generic name for the macro -- maybe there is a better name for that (DISTRHO_PLUGIN_USE_MIDI_MPE?), maybe you wanted no default value in DistrhoInfo.hpp.

@falkTX falkTX force-pushed the develop branch 3 times, most recently from 7599a6e to 52c2e78 Compare May 17, 2024 13:39
@falkTX falkTX force-pushed the develop branch 2 times, most recently from 59cc6ed to 470c5b7 Compare July 14, 2024 11:06
@falkTX falkTX force-pushed the develop branch 8 times, most recently from 8507aec to 7cd4819 Compare October 6, 2024 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@jfrey-xx @falkTX