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.

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

Add APVTS parameter integration #156

Closed
ImJimmi opened this issue Oct 10, 2024 · 3 comments · Fixed by #168
Closed

Add APVTS parameter integration #156

ImJimmi opened this issue Oct 10, 2024 · 3 comments · Fixed by #168

Comments

@ImJimmi
Copy link
Owner

ImJimmi commented Oct 10, 2024

Add a real-time-thread-safe way of connecting a JIVE GUI Item to a parameter in an audio processor and/or the APVTS.

This will likely work by passing the APVTS to the jive::Interpreter, and a "apvts-id" property specified on the widgets to specify which parameter from the APVTS they should connect to. This would also use the parameter to decide things like the range of a slider, the choices in a dropdown, etc.

@forestbond
Copy link

forestbond commented Jan 16, 2025

Hi @ImJimmi. I'm not sure this is really the right place to mention it but I tried integrating JIVE into a simple plugin project today and failed miserably. I have seen the View way of handling parameter attachments but in practice I found it difficult to understand and make good use of. I take it from this ticket that this is an area still needing some development? It would be very instructive if there was a functioning example plugin that uses JIVE with parameter attachments. I don't think the trivial example in the docs will compile.

EDIT: The trivial example does compile, I'm not sure why I was running into problems with makeView. In any case there are some usability challenges with more than one attachment (how to search for the correct GuiItem?) and a working full example would be helpful.

EDIT2: Ok actually the example does not compile. I get an error stemming from the makeView call:

error: no matching conversion for functional-style cast from 'juce::AudioProcessorValueTreeState' to 'tuple<typename __unwrap_ref_decay<AudioProcessorValueTreeState &>::type>' (aka 'tuplejuce::AudioProcessorValueTreeState')

I found I can get it to compile if I make the EditorView constructor take a pointer instead of a pass-by-reference juce::AudioProcessorValueTreeState.

@ImJimmi
Copy link
Owner Author

ImJimmi commented Jan 16, 2025

Hi @ImJimmi. I'm not sure this is really the right place to mention it but I tried integrating JIVE into a simple plugin project today and failed miserably. I have seen the View way of handling parameter attachments but in practice I found it difficult to understand and make good use of. I take it from this ticket that this is an area still needing some development? It would be very instructive if there was a functioning example plugin that uses JIVE with parameter attachments. I don't think the trivial example in the docs will compile.

EDIT: The trivial example does compile, I'm not sure why I was running into problems with makeView. In any case there are some usability challenges with more than one attachment (how to search for the correct GuiItem?) and a working full example would be helpful.

EDIT2: Ok actually the example does not compile. I get an error stemming from the makeView call:

error: no matching conversion for functional-style cast from 'juce::AudioProcessorValueTreeState' to 'tuple<typename __unwrap_ref_decay<AudioProcessorValueTreeState &>::type>' (aka 'tuplejuce::AudioProcessorValueTreeState')

I found I can get it to compile if I make the EditorView constructor take a pointer instead of a pass-by-reference juce::AudioProcessorValueTreeState.

Ahh thanks for reporting - I hadn't thought to check the examples in the docs. I'll go through them and update where needed.

@ImJimmi
Copy link
Owner Author

ImJimmi commented Jan 18, 2025

@forestbond v1.3 adds support for parameter attachments as well as a new gain plugin example that utilises this feature. The outdated example in the docs was also removed, thanks again for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants