LookupTable floating point error Sonoma (revisited)

Deleted my initial post in favor of better reproducability.

First things first, I have recently updated to Sonoma. I’ve gotten everything to build. However, my Oscillators are causing crashes because calculating the first index of the lookupTable leads to a floating point error that makes the index become negative. This happens in the processSample (FloatType value) of juce_LookupTable.h at this assert:

jassert (isPositiveAndBelow (index, FloatType (lookupTable.getNumPoints())));

where index has a value of “index float -0.0000103…”. I am on Juce 7.0.9, not following the dev branch using XCode 15.1 beta. I managed to reproduce the error in a Projucer project by making a barebone Oscillator:
In the prepare(…) function:

    lfoOsc.setFrequency (0.5f); // lfoOsc is a juce::dsp::Oscillator private member variable
    lfoOsc.prepare ({44100 , 128, 2});
    size_t sinewaveResolution = 22050; // Depending on this value it may work or not
    lfoOsc.initialise ([] (float x) { return std::sin(x); }, sinewaveResolution);

In the processBlock(…) function:

lfoOsc.processSample (0.0f);

Before the whole upgrade procedure everything seemed to be working fine. For now, I have gotten things to run by choosing a different sineWaveResolution but I doubt that this “fix” is consistent across different environments, as it seems to be at the mercy of the floating point error.

Though I suspect that the issue has something to do with the updates, I cannot exclude that it is some embarrassing oversight on my part (it mostly is). In either case, i would be grateful if someone could shed some light on the issue!

Hi there!

I am having the same exact issue. Everything works perfectly on my Mac Intel, but now on my other machine which is a Mac M1 I always get stuck at this point!

My first index value is -0.0000011715… etc. which triggers the jassert and crashes the plugin.

Any help/hints?

no, unfortunately I have nothing new to report, except maybe that I updated from XCode 15.1 beta to 15.2 and the issue still persists. I am still rolling with simply having some sineWaveResolution where this doesn’t happen. While it feels a bit eery there have been no further instances of this issue, though I have yet to expose this workaround to a wider range of environments.