Slightly improve our borked Program Change implementation

[mkruselj]

So the way it works currently it just goes from first factory patch if Program Change 0 is sent, onwards, alphabetically as sorted in the patch browser menu.

Let's change this so that it first searches for a user category called "MIDI Programs", if that is not found start from first user patch instead.

[baconpaul]

void SurgeSynthesizer::programChange(char channel, int value)
{
    auto ignorePC = Surge::Storage::getUserDefaultValue(
        &(storage), Surge::Storage::IgnoreMIDIProgramChange, false);

    if (ignorePC)
        return;

    PCH = value;
    // load_patch((CC0<<7) + PCH);
    patchid_queue = (CC0 << 7) + PCH;
}

so I think you change this to

void SurgeSynthesizer::programChange(char channel, int value)
{
    auto ignorePC = Surge::Storage::getUserDefaultValue(
        &(storage), Surge::Storage::IgnoreMIDIProgramChange, false);

    if (ignorePC)
        return;

    PCH = value;
    // load_patch((CC0<<7) + PCH);
    auto nextPatch = (CC0 << 7) + PCH;
    // traverse here
}

that traversal is a bit painful but this is an infrequent operation

basically you travers categories in order starting at the first user vcategory
then you traverse all patches looking for that category
and if you find it increase a counter
when the counter hits the number, that's the id you want

ugh i will write this up more properly if you get stuck. look at the Patch Selector for the data structures

[mkruselj]

Big brain thinking: shall we store a list of patches found in "MIDI Programs" folder in a list when we refresh patch browser instead? Cache it so then it's O(1)?

Then if folder not found just fill it with first 128 ordered patches to keep things O(1).

[baconpaul]

Who really cares about the order - this is an infrequent thing. But I like the idea of looking for a midi category

[mkruselj]

Dunno I think caching is a good idea just to be on the safe side... Also, u-he does it too. Haha. 😛

Can never know if somebody creates a garbled mess of incoming MIDI. Or realtime editing a program change event in a host can be sent in realtime too (esp on mousewheel gesture etc)...

[baconpaul]

so the traversal is the same one we do on every menu build and mouse wheel
as a first pass, i would just make it do the easy thing
then if that doesn't work
we can do the hard thing

alternately we could, in the surge storage scan, build the cache if you want. that's fine too! Just rebuild it in refresh_patch_list and make it a member on storage. midi number to patch id.

[baconpaul]

Link to #576

[baconpaul]

Since there's good action in #576 from 3f72558 I'm gonna close this basically dup (which roughly does what I outlined above, just a bit smarter)