freq2cutoff

[felixroos]

@ahihi made a ugen that translates a frequency to a normalized cutoff:
https://kabel.salat.dev/#YXVkaW8uZmFkZVRpbWUgPSAwOwoKY29uc3QgZnJlcTJjdXRvZmYgPSBhZGRVZ2VuKCJmcmVxMmN1dG9mZiIsIGNsYXNzIEZyZXEyQ3V0b2ZmIHsKICBjb25zdHJ1Y3RvcihpZCwgc3RhdGUsIHNhbXBsZVJhdGUsIHNlbmQpIHsKICAgIHRoaXMucGlPdmVyU3IgPSBNYXRoLlBJL3NhbXBsZVJhdGU7CiAgICB0aGlzLmVpZ2h0aE92ZXJMb2dIYWxmID0gMC4xMjUvTWF0aC5sb2coMC41KTsKICB9CgogIHVwZGF0ZShmcmVxKSB7CiAgICBjb25zdCBjID0gMipNYXRoLnNpbihmcmVxKnRoaXMucGlPdmVyU3IpOwogICAgY29uc3QgY3V0ID0gMSAtIE1hdGgubG9nKGMpICogdGhpcy5laWdodGhPdmVyTG9nSGFsZjsKICAgIHJldHVybiBjdXQ7CiAgfQp9KTsKCmNvbnN0IGZyZXEgPSBpbXB1bHNlKDQpLnNlcSgwLDcsMTIpLmFkZCg2MCkubWlkaW5vdGUoKTsKY29uc3QgYSA9IG5vaXNlKCkubHBmKGZyZXEuZnJlcTJjdXRvZmYoKSwgMC44KTsKY29uc3QgYiA9IGZyZXEuc2luZSgpOwoKaW1wdWxzZSg0LzMpLnNlcShhLGIpLm91dCgpOw%3D%3D
think about how this could be integrated to the standard lib

[ahihi]

i guess options are

1. keep it as a separate ugen
   • pros: modularity
   • cons: specific to the current "1-RC and C" filter implementation, not compatible with possible other future filters
2. add ugens like lpfhz, bpfhz, hpfhz that do the conversion internally
   • pros: can be done for any filter implementation
   • cons: proliferation of ugens
3. add an optional parameter to the current ugens which toggles the conversion
   • pros: same as 2 but no extra ugens
   • cons: tiny performance hit from always having to check the flag?

[ahihi]

cons of option 1 might be alleviated by having a clear naming convention for different filter types.. e.g. the existing lpf/bpf/hpf would be of type f and have a conversion function freq2cutf (or something). then for a future type of filter such as 4pole you might have lp4pole/bp4pole/hp4pole and a conversion function freq2cut4pole. idk, maybe the names would get too complicated. just an idea :D