pd-else branch: sfont~issue (erratic pitch bends)
agraef opened this issue · 2 comments
Pitch bends don't sound right. This is only when sfont~ is used in Purr Data, pitch bends work fine in vanilla, so there's probably an incompatibility of some internal API with vanilla at play here.
Most likely this is because of internal changes to properly map incoming pitch bend messages to values -8192..8191 instead of vanilla's (broken) 0..16383. This bug was fixed some years ago in pd-l2ork and purr-data, but never was and never will be fixed in vanilla. Thus we either need to change the internal API to make it vanilla bug-compatible again (and fix the range elsewhere, where it doesn't affect externals written for vanilla), or deploy a work-around in sfont~ itself, by checking whether the host environment is Purr Data.
There's no internal API involved here, so this can only be fixed at the patch level. Issue is with the bendin object in the sfont~-help patch. This needs to be patched up to enforce vanilla behavior in Purr Data (#X obj ... bendin; -> #X obj ... bendin 0 1;). ELSE's midi.learn.pd abstraction is most likely affected as well. midi.learn.pd not actually affected because bendin is only used to detect the control type to be learned, so the actual range is inconsequential. But we're fixing it anyway.