Question regarding assertions

1

grafik
grafik.png800×55 3.96 KB

As seen in the image above I’m hitting an assertion regarding duplicated parameters. I’m hitting it exactly three times in a row.
I have a bunch of questions:

  1. this should be fairly obvious but the string in the data field is the parameter we’re looking for (“amount_1_[0]”)? I checked like 20 times and I don’t see how this one could be duplicated…
  2. We are talking about duplicated AudioParameterFloat and not duped Identifiers or something? Also, the “ID” part of the parameter is its string?
  3. Anything further to go on as to where the duplicated error might be?
  4. Will plugins crash on these kind of assertions when loaded into a DAW? Mine crashes and I’m wondering if these assertions are the reason.
2

Ok I got it. This assertion is not about parameters, but about identifiers…
If you create two identifiers with the same string you’ll hit it, and for some reason you only hit it three times in total (it should hit me 200 times at least lol)

I think the description is a bit misleading, as it says you have two or more parameters

anyway - solved :slight_smile: onto the next issue

3

Ok but is this the thing crashing my DAW? (after all it throws exceptions in the debug config…)

If so, can I disable this assertion? I checked the code, but I’m quite certain I do want the duplicate identifiers.

4

You sure about that? I have a feeling most DAWs wouldn’t handle duplicate parameters very well… plus how do you differentiate which parameter then when you try accessing them via one of the getParameter(const juce::String &paramID) or related methods?

5

Like I said, this is not about actual parameters beign duplicated, but about Identifiers.
https://docs.juce.com/master/classIdentifier.html

6

Looks to me like the assertion is the one in juce_AudioProcessor.cpp:746 which is actually complaining about duplicate parameter IDs (the function name is checkForDupedParamIDs). When the assertion fires, you should be able to log ids[i] in the debugger to find out which parameters are causing the problem.

7

jep exactly! I found which it is, but I am not duplicating any parameter.

I have a parameter with id “m_amount_1_[0]”.
Second, create an Identifier (no parameter) with the same id.

What’s the harm in doing so?

8

Somewhere a parameter is being created with that ID again, that’s what the assertion is checking for. Just creating a duplicate identifier object by itself is fine, but once you call AudioProcessor::addParameter() or AudioProcessorValueTreeState::createAndAddParameter() using the identifier more than one time, you’ll run into that assertion.

9

Note that creating two identifiers with different variable names but the same string means they are duplicate, as they both resolve to the same hash. The identifiers you create for parameters cannot have the same string value, they must be unique.

10

Im using neither of the two functions in my entire codebase, but you got me to the right point anyway. The point that is triggering it apparently is some place where I call

m_value_tree.getParameter(m_amount_1_identifier0)->setValueNotifyingHost(((float)p_value + 1.f) / 2.f);

Which begs the question, why would getParameter() create a new parameter?

11

How are you adding parameters to your APVTS?

12

It doesn’t, it will return nullptr if a parameter isn’t found with the given ID. Is it segfaulting at that call?

I’m assuming you’re just using the AudioProcessorValueTreeState constructor? You will want to check that and make sure the parameters being passed in don’t end up with the same strings for their parameter IDs.

13

Ok I mixed things up while being too hasty. The getParameter() call is innocent! Sorry for the confusion.

Yes I’m using a bigass initializer list, like I learned from some tutorial… The thing looks something like this:

m_parameters(*this, nullptr, Identifier("Odin"), {
    std::make_unique<AudioParameterFloat> ("amount_1_[0]", "amount_1_[0]", -1,1,0),
})

although wayyy longer. And in this list is non other param with ID “amount_1_[0]”

14

There’s probably some other duplicates somewhere further down the list then. To find out the ID that’s being problematic:

When the assertion fires, you should be able to log ids[i] in the debugger

15

You mean see all of them at the same time? Like the picture I postet in the very first post I know which ID is causing trouble, but I simply dont see where I create it twice…

16

If you’re referring to your screenshot, I believe that identifier just happens to be the first in the ids array, as the data=0x...{text=... section is referring to the pointer to the beginning of the array

Did you check which ID it’s referring to (i.e. DBG(ids[i])) when the assertion hits?

17

THANK YOU! :heart:
All the time I was chasing a ghost, when in reality it wasn’t the amount_1_[0] but some other parameter. Ok now I have something to wokr off :smiley:

1 Like