LOOP_PHASE_LENGTH doesn't look right, subtracting a negative number with unsigned integers doesn't make sense in this case.I am wondering if this bit might have something do with itCode:((uint32_t)2048 - 1) << (32 - 12), // MAX_PHASE ((uint32_t)2047 - 1) << (32 - 12), // LOOP_PHASE_END (((uint32_t)2047 - 1) << (32 - 12)) - (((uint32_t)0 - 1) << (32 - 12)), // LOOP_PHASE_LENGTH
((uint32_t)2048 - 1) << (32 - 12), // MAX_PHASE
((uint32_t)2047 - 1) << (32 - 12), // LOOP_PHASE_END
((uint32_t)2047 - 1) << (32 - 12), // LOOP_PHASE_LENGTH
LOOP_PHASE_LENGTH doesn't look right, subtracting a negative number with unsigned integers doesn't make sense in this case.
This seems to remove the artefact:Code:((uint32_t)2048 - 1) << (32 - 12), // MAX_PHASE ((uint32_t)2047 - 1) << (32 - 12), // LOOP_PHASE_END ((uint32_t)2047 - 1) << (32 - 12), // LOOP_PHASE_LENGTH
I neglected to mention that the offending code is generated by these single cycle special cases in the soundfont decoder. I will upload a fix to the python code as soon as I have time to review it.
Good to see the problem was solved!
You better fork https://github.com/PaulStoffregen/SoundfontDecoder to make the fix, commit it and push it to your github fork and then send Paul the pull request and he will decide what to do with it (isn't this the workflow?).
Now when you have got the single cycle loops working I'd like to suggest implementing Transwaves - a single cycle loop with a modulated loop point inside a real wavetable (array of single cycle waves with different harmonic content). You can get some from Ensoniq firmwares from MAME project or generate using Audioterm: https://www.facebook.com/Audioterm/