LinearSmoothedValue setValue deprecated on latest develop

General JUCE discussion
1

Hello,

I seems that LinearSmoothedValue::setValue is deprecated on latest develop branch.

What is the replacement for setValue(val, true) ?
Is this correct?

smoothVal.setTargetValue(val);
smoothVal.setCurrentValueToTargetValue();

Thank you

2

Yes, that’s right. The comment above the deprecated function explains what you can do instead of calling setValue.

3

Thank you.

4

Actually I’ve just changed the interface again. See the updated documentation:

lsv.setValue (x, false); -> lsv.setTargetValue (x);
lsv.setValue (x, true);  -> lsv.setCurrentAndTargetValue (x);
5

Is it the final change? I just want to update dozens places where I used it.
(BTW there was nothing wrong with old interface, you could easily pass through the force flag to nested structures, no I have to use a if()-clause everywhere)

6

It’s very likely to be the final change.

There was plenty wrong with the old interface:

  • LinearSmoothedVaule::setValue - What does this function do? It’s completely unclear. From its name it most likely sets the current value (which is wrong in the default case).

Worse:

  • lsv.setValue (3.0f, true), lsv.setValue (3.0f, false) - This is even less clear what’s going on.
7

There’s nothing to stop you writing your own, although I might pick a better name than setValue, and use an enum class instead of a bool as the final paramter…

void setValue (LinearSmoothedValue& l, float value, bool force) {
  if (force) l.setCurrentAndTargetValue (value);
  else l.setTargetValue (value);
}
8

thanks of course, the reason I am moaning is that these interface changes creates (unnecessary) noise on my repository, which may introduce new bugs. Also I have shared code with legacy products, which I can’t update for several reasons to a newer juce release (fear of incompatibles of existing products which are running on a lot of customers computers), so this is will result in a lot of #ifdef newJuceVersion etc… in my shared code library (and I don’t want deprecation warning in my current products etc, also I don’t want to capsule a lot code in wrappers, which are only exists for compatibility reasons)

9

It’s not entirely unnecessary - it’s an improvement to the interface. When you work on a library there is a constant tension between maintaining backwards compatibility and making the library better.

This class, for example, was flagged up as being confusing. I took a look at it again after not seeing it for a few months and I had to read the docs, quite carefully, to work out exactly what that method was doing. Leaving it in there will cause confusion and mistakes for new code, removing it will mean that old code will need to be updated. In this case switching over to the new code is fairly straightforward, so we made the change.

A bigger, more disruptive, change will be when we move to using std::unique_ptr and friends to indicate ownership through API calls. We’ve wanted to do this for a long time, but are waiting for a moment (probably just after a bugfix release) when it would be the least problematic for everyone. This will, inevitably, bring out some moaning from people with existing applications, but I’m convinced the increase in safety and clarity will be worth it. Similar pain will be necessary to improve the thread safety of all the AudioProcessorParameter handling. The benefits of these changes are probably much more obvious, and you’d be unlikely to argue against them, but it’s all part of the same process.

1 Like
10

Thanks, Could you elaborate the changes to AudioProcessorParameter handling a little bit further?

Currently the “fixed” array structure makes it easy to prevent race conditions, because the current value is stored at one position and the changes are «basically» atomically. (or could be changed to be atomic)
(Not talking about apvts here)

I hope there is no need to introduce complexity, to fix things which could be solved in a simpler way.

11

Well, there’s the problem.

There are a few places where we expose raw floats via the interface and we should change this. They get flagged up the ThreadSanitizer too. See this thread for more info:

(I know you’ve contributed to that thread, I’m posting for the benefit of other readers.)

1 Like