[p5.js 2.0 Bug Report]: noiseDetail(1) triggers Friendly Error even though second parameter is optional

[shuklaaryan367-byte]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.1.2

Web browser and version

Google Chrome Version 143.0.7499.170

Operating system

Windows 11

Steps to reproduce this

Steps:

1. Open the p5.js Web Editor

2. Ensure Friendly Errors are enabled (default)

3. Run the sketch below

4. Observe a Friendly Error warning in the console

Snippet:

function setup() {
  noCanvas();
  noiseDetail(1);
  console.log(noise(0.5));
}

Expected behaviour:

According to the documentation, the second argument to noiseDetail() (falloff) is optional because a default value (0.5) is defined. Calling noiseDetail(1) should therefore be valid and should not trigger a Friendly Error warning.

Actual behaviour:

p5.js displays a Friendly Error warning:
“Expected number at the second parameter in noiseDetail()”
even though the call is valid and the sketch runs correctly.

Additional confirmation:

When p5.disableFriendlyErrors = true is set, the warning disappears, confirming this is an FES validation bug rather than a problem with noiseDetail() itself.

I’m happy to help implement a fix if this is approved.

[davepagurek]

Thanks @shuklaaryan367-byte! Feel free to take this task on. While the text of the reference mention it being optional, the @param line of the docs needs to wrap the argument in square brackets (ideally also providing a default value after an = sign) to document that it is optional.

[davepagurek]

Hi! I'm noticing a few things. First, while the call does work without a falloff, looking at the code, it doesn't assign it a value of 0.5, it just doesn't update the falloff from whatever its last value is. On closer inspection it also doesn't appear that the text of the reference actually says it's optional at all. So we can either remove the =0.5 and update the documentation to indicate that if it's not provided, it doesn't update the last value, or we could update the code for noiseFalloff to also have = 0.5 in case a value isn't provided.

Was there a tutorial or something that you saw that mentioned explicitly that it's optional that we would have to update?

Also, one last note, right now your PR is into the main branch, which is for p5 1.x. If the tutorials and reference all are consistent (indicating that falloff is not optional) then we should likely just leave 1.x alone, as it only receives bug fixes now, and instead make updates to dev-2.0 for 2.x releases. But if we do indicate elsewhere that this parameter is optional, then we should probably update both branches (i.e. making a similar PR into dev-2.0 after this.)

[shuklaaryan367-byte]

Thanks for the detailed feedback.

You’re right, looking closer the current behaviour doesn’t reset falloff to 0.5 when omitted, it just keeps the previous value. My original assumption was based on how the docs describe the default, not on the internal state behaviour.

I didn’t see a tutorial explicitly calling it optional; I was inferring from the reference text mentioning a default. If the intended behaviour for 1.x is “falloff is required to change it,” I’m happy to update the reference wording instead of changing runtime behaviour.

And thanks for pointing out the branch, that makes sense. Let me know whether you’d prefer this as a documentation fix for 1.x, or as a behaviour change targeted at dev-2.0.

[davepagurek]

Given that the original documentation states that both parameters are required, allowing one to be optional with a default value counts as being backwards-compatible. So I think updating both the docs and code in the 2.x branch to have a specified default of 0.5 would be good. Let's leave 1.x alone then, and just make this change in 2.x.

[shuklaaryan367-byte]

Thanks for the clarification, that makes sense. I didn’t realize main is treated as 1.x-only and that API improvements should go into dev-2.0. I’m happy to retarget this change to the 2.x branch instead. I’ll create a new PR against dev-2.0 with the same default-falloff update in both code and reference, and leave 1.x unchanged as suggested. Thanks for pointing me in the right direction!