Attempting to make an array of slider attachments

getting error “/Applications/ No matching constructor for initialization of ‘juce::AudioProcessorValueTreeState::SliderAttachment’”

in plugin_editor.h

    std::array<std::unique_ptr<juce::AudioProcessorValueTreeState::SliderAttachment>, 16> inversionCellAttachment;
    std::array<std::unique_ptr<juce::AudioProcessorValueTreeState::SliderAttachment>, 16> velocityCellAttachment;

in plugin_editor.c:

    for (int i = 0; i < 16; ++i) {
        String invName;
        invName = "INVERSIONCELL" + std::to_string(i);
        DBG("STRANG:" << invName);
        inversionCellAttachment[i] = std::make_unique<juce::AudioProcessorValueTreeState::SliderAttachment>(audioProcessor.apvts, invName, inversionCells[i]);

have you tried &inversionCells[i] ?

if you know exactly how many parameter attachments you need and what they are supposed to be attached to while initializing their component already, you can just initialize them in the initializer list of the component without the need to wrap them around a unique_ptr. i did that in various ways in this video to demonstrate the syntax

the vid is not really handling the issue from the OP.
OP uses a large batch of slider objects, and the problem is a small one. there are mulitple ways to organise params, and there is no need to switch that now.

That did not work unfortunately.

I left out the declaration of inverionCells[I]
it is a

  juce::OwnedArray<juce::Slider> inversionCells;

Maybe it does not need to be an OwnedArray

if you can rule out that is has nothing to do with the pointers by not using pointers you can spot the actual mistake faster as it’s just about the attachment’s constructor itself then. that is why i recommend it, even if it doesn’t lead to the solution immediatly

1 Like

*inversionCells[i] ?

SliderAttachment constructor last arguments expecting reference to Slider, but your OwnedArray object returns with operator[i] is a pointer to Slider.

So either store your Sliders(s) in a container of Slider (not pointer of Slider), or dereference your return object from OwnedArray.


        inversionCellAttachment[i] = std::make_unique<juce::AudioProcessorValueTreeState::SliderAttachment>(audioProcessor.apvts, invName, *inversionCells[i]);

see, everyone? it was just the pointer enforcing its overly complicated and error-prone syntax. so my initial response to switch to normal objects would have actually solved it asap

1 Like

Asking someone to watch a 30 minute video and do things in a completely different manner is perhaps a bit overwhelming, especially if the problem is just a missing dereference sign, even if the video is helpful. Also, anyone who wants to do anything with JUCE will have to understand pointers sooner or later and deal with the warts and moles of C++. So kudos to all explanations in this thread!


yeah i totally get that. i would have expected OP to just skip to the part that matters ofc lol. however i disagree that this is a good opportunity to learn how to use smart pointers. the pointer has no function here, so if this was a lesson the gained knowledge would be “aha, smart pointers exist. idk why i have to use one here but it works so i’ll keep on using it”