lfo library improvements

[dndrks]

just wanted to strike up a lil' space for proposed improvements to the lfo library :)

some ideas being passed around with @sonocircuit:

• add saw behavior (and rename current saw to tri, that took a while to catch!)
• add phase offset
• add baseline to the constructor
• spin up some examples (+ maybe in-lib templates/presets) to demonstrate adding lfo movement using a parameter's current value as the baseline

@sixolet , i'm curious if toolkit's brilliant lifecycle has inspired any new ideas for this scripting library?

[dndrks]

addressed by #1692

[sonocircuit]

@dndrks ah right I can see that. a few thoughts:

• the actual value doesn't go below 0 as it's clamped via the parameter's min value. However, the lfo does display negative scaled values.
• I think it's important to keep a good balance between simplicity and flexibility. Personally I wouldn't surface the parameters lfo_min, lfo_max (and probably baseline) to the end user, as the same effects can be achieved with depth, offset and phase. If the script dev sets the lfo_min, lfo_max values to the min/max values of the modulated param the case you described above would not occur and the same lfo behaviour can be set with depth and offset alone. I might be overseeing specific use cases though.
• However, if you feel like keeping lfo_min and lfo_max in the params menu, I'd say preferably both the offset range should be set according to the baseline and clamping min/max output values should happen if we want to ensure that the values don't go out of range.

(I added the offset range scaling to the repo linked above. I'd be curious to know how you would implement it. I'm pretty sure I overlooked something )

[dndrks]

• actual value: ah, right, yes, thank you for reminder!
• you raise a super good point, though i think simplicity all depends on the situation. eg. "i want to use a square wave to flip this parameter between 19 and 46". i'd just set min to 19, max to 46, and depth to 100. or i could set offset to 19 to get my baseline, then depth to 27 (in order to get the scaled value up to 46), which is doable but requires more mental math than i typically want to exercise. having both avenues available helps cover a wider range of uses, so i'd be down for it all to co-exist :)
• since parameters clamp the actual value anyway, i think your changes for the offset range being dependent on baseline makes total sense + feels complete!

in summary: this rips, @sonocircuit ! would you like to submit a PR to the main codebase so your contribution is appropriately annotated in the historical view + add your name to the credits at the top of the file? <33

[sonocircuit]

• simplicity all depends on the situation: absolutely. that would be one of my overseen use cases.
• if the code changes are good on your behalf I'd love to do so. I'm assuming standard procedure would be. fork norns > edit lfo.lua > submit PR?

[dndrks]

code changes look good to me, and are testing well on my side! we can roll 'em into the beta and get some more testing done, though :) stoked for you to get attributed!! <3

that's the process, yeh! maybe reference this discussion in the PR for context?

[sonocircuit]

thanks dan! I'll do so. best sacha

[dndrks]

this got sorted really really well, imo, so closing the convo -- @sonocircuit feel free to reopen w/ further q's / ideas!! thank you so much for the contributions + conversations!!