Very small FR for SmoothedValue

Feature Requests
1

It would be great if we can access the current countdown value:

--- a/modules/juce_audio_basics/utilities/juce_SmoothedValue.h
+++ b/modules/juce_audio_basics/utilities/juce_SmoothedValue.h
@@ -67,6 +67,8 @@ public:
     /** Returns the current value of the ramp. */
     FloatType getCurrentValue() const noexcept           { return currentValue; }

+    int getCountdown() const noexcept               { return countdown; }
2

Also, make it virtual so I can

int getCountdown() final;

:stuck_out_tongue:

2 Likes
3

I am a little skeptical about these “Feature Request”-vote counters.

If they are sensible changes that are very unlikely to have any consequences, but at the same time are not very popular (like vulkan support), then there is a danger that these small everyday improvements will be lost. Maybe these vote-counters are not a good tool for such small changes.
@t0m

PS: Also the limited number of votes is a problem too, I guess most users already spent all their votes.

3 Likes
4

You should probably open a new thread in the site feedback category to not hijack your own FR.

Anyway i share your skepticism.

5

You might get a better response if you give a little more context to why you want this feature.

I find a good feature request should be written like a story - setup, conflict, resolution. Give an example of what you’re trying to accomplish, highlight why you can’t achieve that with the current set of features, then introduce the solution.

I can’t really think of any reason I’d ever need to access countdown from a smoothed value - if you can explain why you need to access it, I might find I could make use of it too and give you a vote.

6

For me it would have made the test driven development easier. I ended up just changing the JUCE code myself because as it was already pointed out its a very tedious process to get through with those feature requests :confused:

7

if you give a little more context to why you want this feature.

Okay, I will do it. Although I am very afraid that this will lead to a discussion whether my approach “is the right one” :wink:

I have a complex signal flow in my plugin, with a lot of different parameters and SmoothedValues and audio-streams.

Some of these audio-streams are oversampled, some are not.

Depended on signal-flow or possible programming mistakes these SmoothedValues may not actively used in runtime, which can let to synchronisation issues in my complex algorithm.

I tend to write a lot of self-checking code, which give me asserts in debug-builds at runtime (of course I prefer compile-time checks, but sometimes these are not practicable )

I set all target values of all SmoothedValues at the start of every processBlock call.
At the end of processBlock I want to check if all SmoothedValues have been used.
I do this by controlling the countdown, if the countdown at the start of the processBlock is more than 0, it should be smaller the end of the processBlock-method.

I do this with a Scoped-checker class. Sounds a bit complicated, yes, because may algorithm is complicated, but that’s exactly what I need.

#ifdef JUCE_DEBUG
template<typename SmootherType>
class ScopedSmoothedValueChecker
{
public: 
    ScopedSmoothedValueChecker (SmootherType& smoother_,int id_)
        :  countdownToTarget (smoother_.getCountdown()),id (id_) ,smoother (smoother_)
    {
            
    }

    ~ScopedSmoothedValueChecker()
    {
        if (countdownToTarget > 0)
        {
            // Synchronisation problem
            jassert (smoother.getCountdown() < countdownToTarget);
        }
    }

    int countdownToTarget;
    int id;
    SmootherType& smoother;
};
#endif
8

I suggest doing it the same way I did: just add the countdown method to the JUCE code. Either completely manual or make it with a Fork of their repository.

9

Thanks, I already do.
I always try to keep the number of custom modifications low, to be future-proof.

10

If you make more than one or two you should consider doing the fork I suggested and let git do the heavy thinking. I think that would require you to bypass Projucer entirely, but (maybe I’m doing something wrong?) that proofed to be completely useless for my projects anyway as I’m definitely not creating all my cpp/h files in there.
If thats not an option I highly recommend adding some preprocessor checks to be informed as soon as possible when you miss one of your changes after an update. Add a #define directly above your changed code and an #ifndef … #error where you’re using your custom additions.

11

Thanks for your tips. I know what git does and know about merging. I use it every day.

I use juce more than 15(!) years, during this time I have suggested innumerable changes and fixes.
I have very good reasons, why I want to have these changes in the original repo (so they are considered when parts of juce are refactored - yes its selfish, but I think 95% of these suggested changes are to the advantage of most here, and this openness is what makes the framework so good after all)

I have the feeling that it used to be easier to make such suggestions (specifically these minimal changes), but maybe that’s not the case.

My original reason for my comment about the voting counter (which was added by an admin) was frustration that comes with it, and the message implied by it, “zero - please don’t bother us” (I am a bit dramatic here, and I am sure it is not meant that way)

While back in the days Jules could add this in a few minutes, now it seems impossible.

But - I can’t complain, juce helped me a lot, its great! I just wanted to say that once.
Okay, back to work.

1 Like