WOOOOOOOW! Super niiice! Also with the existence of fl.lookupstring~ it makes much more sense to me to have fl.makestring~ too (in terms of naming).
If it’s not much work, I would love the option. But it leads to the question of how many elements you can define as arguments, probably something in the 10s? I guess the normalized lookup will be more useful when you’ll implement the large lookup table/dataset for strings.
A (possibly dumb) question: where can I get the fl.makestring~ and fl.lookupstring~ externals for Windows? I see @james.bradbury is already using it, and I am drooling… :)))
There aren’t VS projects for the new objects yet. I’ll try to get that done soon.
Currently you can do up to 32 strings for lookupstring~ because each string is a parameter. That to me would cover all the cases where you’d be mapping enums in a specific way. For super long sample lists etc. there will be another object that works differently. I’m imagining though that often you’ll want to randomise the strings, so normalised lookup might be neat - it’s maybe 3-5 lines of code, so easy to do.
Yes, sorry, it was just my GitHub-rookiness, then I found the dev branch, which I have cloned now. Not pretending that I know what I’m doing, but I’ll google and try.
I’ve now added a normalised mode to fl.lookupstring~ which is good for randomising parameters easily (fl.random~ into fl.lookupstring~) - set by the scale parameter.
If anyone here had (or wanted to make) some examples of the two string objects for use in help files that would speed up release. Also let me know if you want to get builds with the new feature (all work is on a branch called “develop”)