How to construct AudioProcessorValueTreeState::SliderAttachment with std::unique_ptr<juce::Slider>

The Projucer
1

Hello,

I have only recently started implementing in Projucer / Juce.

I have one problem that I’m trying to solve:
1- I use the GUI Editor in Projucer to create knobs and sliders
2- I want to use AudioProcessorValueTreeState::SliderAttachment for the parameters.

The problem is that Projucer GUI Editor creates unique pointers such as

std::unique_ptr<juce::Slider> m_sineSlider;

which SliderAttachment constructor does not accept since it is expecting a reference to a slider:

new AudioProcessorValueTreeState::SliderAttachment(m_processor.m_treestate, m_sineSlider->getName(), m_sineSlider); // Does not compile

Since last parameter of the constructor is pass by reference:
SliderAttachment (
AudioProcessorValueTreeState& stateToUse,
const String& parameterID,
Slider& slider );

I prefer not to go back to manually generating UI so I’m wondering if there’s a way to do this?

Thank you.

Cheers,
Aram

2

To get a reference to the unique_ptr you simply dereference it adding an asterisk ˋ*m_sineSliderˋ

1 Like
3

@aram depending on your needs, you may be quite restricted in what you can achieve with the Projucer layout tools. If you want to do anything of complexity you should develop your skill set in manual layout… or, use more powerful like Plugin Gui Magic

1 Like
4

Thank you Daniel for the suggestion.

I have already tried that but the application crashes upon closing in juce::HeapBlock and that’s why I thought to ask how anyone is using the Projucer GUI Editor with parameter support.

5

Thanks for the comment @cpr2323 . I don’t think that manual creation of gui is the better equivalent of WYSIWYG.

Plugin Gui Magic looks very appealing, however it costs.

I am certain there must be a way to use Projucer GUI Editor and properly generate parameters without issues. I’m hoping someone on the forum has done this before.

I spent most of the 2 3 days manually creating knobs and sliders, creating labels, images etc before posting this so I really am looking for the right way to make GUI, using GUI.

6

I didn’t mean to imply that manual is better than a WYSIWYG editor, only that the Projucer editor is old and crufty, without much new work having gone into for a while. At one point (not sure if this is still the case, it was considered deprecated) I would hate for you to get frustrated trying to do creative things that the editor can’t do for you. although, a quick search does how there are people who are happy with it, so my comments are likely biased by my own preference. :slight_smile: And I am sure someone who is using it could answer your actual question. Are you also learning C++ while you learn JUCE?

7

It’s all good @cpr2323 :slight_smile: The fact that I received responses under an hour from JUCE community is a gem itself. I use C++ on daily basis.

1 Like
8

Dereferencing the unique pointer should not be the reason for that. I suspect that the order of destruction is what could be problematic here, if you declare your attachment as a member before the slider itself or if you explicitly reset the slider member before destructing the attachment this can lead to an attachment calling a slider it references to that no longer exists. To make things easier, I created a helper class template for my projects that groups a widget with the matching attachment (the matching attachment type is selected automatically through std::enable_if) so that you can just write e.g.

jb::AttachedWidget<Slider> m_sineSlider { apvts, sineSliderID, /* slider constructor args here * /}

This makes sure that the destruction order is always right. You can find it here:

However, this is not exactly matching the auto generated gui editor code. But as others said above, I’d advise you to try to avoid it as it is not supported anymore and is quite unflexible. Building GUIs from code is much more powerful at least with the current state of JUCE and what most pro users I know do. If you use JUCE_LIVE_CONSTANT polled in a timer to set sizes and positions it’s not so hard to tweak parts of the GUI at runtime :slightly_smiling_face:

2 Likes
9

Thank you @PluginPenguin for the explanation!

One of the GUI Editor generated limitations is that there is only a limited number of locations things can be written (ie, the bracketed code is before the auto generated code etc) and makes it harder to play around the orders. As you mentioned, some listeners are being destroyed before the attachments are done with them.

I think I’ll take another direction that still may be good enough:

  • Use gui and generated code
  • Move the generated code to bracketed area
  • Delete gui that removes the original code
  • Change the content as needed.

I might also look into a Xaml to Code I wrote a while back or something similar to help make the boilerplate parts faster.

By the way I noticed you have a Preset Manager in that github, I hope you don’t mind me looking around that as I noticed that’s another thing missing from the Juce framework.

Cheers!

10

Sure, look around as much as you want and use everything you find there according to the licenses the individual projects are released under if you want to :slightly_smiling_face:

If you are interested in the preset manager, you might also want to check out my PluginAudioProcessorBase class that avoids a lot of boilerplate code for my products, by setting up an AudioProcessor along with the preset manager and an apvts and overrides several member functions in a senseful way… example usage of all this can be found here GitHub - JanosGit/Schrammel_OJD at develop

1 Like
11

Thank you, will do!