More forgiving functions

[unlessgames]

It might be a good idea to be more forgiving with arguments for functions instead of throwing an error to ease the friction when live-coding.

For example Note:panning(-2) could just clamp the input to -1 instead of crashing the sketch, the same thing is applicable to other functions that expect ranges, this is especially handy if you are doing something where the argument comes out of some complex calculation, or trying to plug the same thing into different places while experimenting and so on. Having to write defensive code is a bit antithetical to live-coding.

[emuell]

That's definitely a good point regarding live-coding, but magically clipping values also hides bugs.

As long as we're consistent here, I'm all for doing this.

Should definitely only be functions which are mostly evaluated in the runtime stage, and not the compile stage, e.g. when constructing the initial pattern. Type conversions mostly are fuzzy already, so you can e.g. pass a string as number argument as well in many cases.

Which functions other than the note properties do you had in mind?

[unlessgames]

In other contexts I'd vote for the transparent errors, but here I think the magic would help the user to keep moving in cases where that might be a bigger concern than enforcing correctness.

I only thought about the note properties yet.

[emuell]

I only thought about the note properties yet.

To be consistent, the note table constructor should clamp values then too, so those two are pretty much interchangeable:

pattern {
  event = note("c4"):volume(1000)
}

and:

pattern {
  event = { key = "c4", volume = 1000 }
}

The note string attributes definitely should NOT clamp, to catch typos, as this most likely will be a compile error and not a runtime error.

pattern {
  event = "c4 v1000.0" -- ERROR
}

---

That said, I'm OK with it, but don't really like it, as those rules seem fuzzy. A cleaner approach would be to introduce new functions that clamp, or an extra argument, but it's difficult to come up with easy-to-read and -write name: e.g. volume_clamped is ugly.

Either way, it would definitely be worth adding a new math.clamp function to the standard Lua math library, to make clamping easier in general and to avoid the min(max()) magic.

[unlessgames]

In my opinion the fuzziness here fits the context. Having separate x_clamped feels off to me, the api should have the least amount of functions necessary.

Having a clamp function built in is useful regardless, but I still think these functions shouldn't crash on out of range input, when you add together values to create modulations it's very common to go out of range but be fine with clamping, the overhead of having to write clamp all the time makes you want to experiment less.

If anything I guess the ideal way to go about this would be to have logs other than errors, then out-of-range here could just show a warning but still run, but overall I don't think this is crucial either.

[emuell]

What about introducing a new STRICT mode that is on by default and behaves as it does now. When off it's in Live mode and the pattrns Lua API would be as forgiving as possible, spitting out warnings instead of errors everywhere.

Example:

-- globally disable strict mode: 
-- try to be as forgiving as possible everywhere - just keep playing...
STRICT = false

return pattern {
  event = { note("c12 v4.0"), "qwe" } -- clamps first note to 127, volume 1, "qwe" is treated as c4
  this_does_not_exist = false -- ignores unknown properties
}

When strict mode is off:

• All bogus note values are interpreted as c4
• All out of range values are clamped to the valid range
• Invalid properties are ignored
• ... anything else?

In order to implement that, we would need to review every single Lua API binding function and try to apply some sensible functionality everywhere, rather than throwing errors when STRICT mode is disabled.

[shinmai]

personally id definitely prefer an opt-out strict mode, or explicit clamping variants of functions, over hiding incorrect arguments by default

i understand the desire for silently clamping things to sane ranges in a live coding context, but feel like that would almost be something for whatever live-coding tool/platform is being used to implement, rather than a fundamental change to the make in the api, since as mentioned it would very easily hide bugs or incorrect applications of functions in non-immediate contexts