It's most likely because the math exceeds a 16 bit number, thus wrapping the bits and causing the glitch.

It's quite alright. Just find it fascinating that the entire lower half pitch bend goes weird the second the note is a semi tone "too low" especially since the bend would theoretically go through all the same pitches as the one above it except one semi tone at the very bottom of the range.
I don't find this fatal at all, I just don't understand how it happens. I agree that it adds some interesting glitch potential, especially when using it on notes well outside the range below C-3

Yeah as I said before there is no "if" condition to lower bound pitches. Adding it just adds overhead that is easy to avoid. Also it can be seen as a feature for glitchy effects. The large pb range wrap around is probably because it exceeds the 16bit unsigned int, I don't want to move it to a 32 bit, again because of overhead. I think its a fair trade off with the increased resolution.

Tested it. It's much better, again. It still glitches under certain conditions and I think I may have found out what those may be, but they're far less likely to occur in any normal use case I'm assuming.

These are the conditions I managed to find in which it glitched:

- If the lowest possible note in the pitch bend range is lower than C-3 it will glitch below 0% pitch bend but not above (examples: C-3 is the first note it will glitch on with pb range 1, C#3 with pb range 2, B-3 with pb range 12(dec) ...) basically if you subtract the pb range in semitones from the note you're playing and the result is lower than C-3 the pitch bend will glitch the moment it goes below 0%

- low notes at bigger pitch bend ranges... like C-5 with pb range 24(dec) will still exhibit the wraparound problem in the pitch bend values closer to -100% even though the lowest note that should be produced is not below C-3

that first one is definitely odd behavior, though I personally don't see myself using pitch bend of 12(dec) on a note as low as C-4 ... perhaps others might? not sure
I'm also not seeing myself using pitch bend ranges outside 12, so the second one seems to be a non-issue as well for me personally.

tl;dr: Thank you trash80, I'm happy with the result, it seems very usable for me now Bugs/glitches are still present though and somebody else may stumble across them.

Feel free to ask me to test some more. I'll be away for the holidays though and probably without my DMG, so testing may have to wait.

Audio example demonstrating glitch #1: C-4 vs B-3 (only one semi tone apart) with the identical pitch bend  at a range of 12(dec) ... the second note is only slightly deeper but experiences the glitches right as pitch bend goes below 0%, the first note shows no problems at all.

http://wolkenspeicherplatz.de/sound/mgb … ison_2.mp3

Okay updated to 1.3.3 ... Let me know how it goes.

http://code.google.com/p/arduinoboy

Oh wait I see... let me look.

It's not the math, you are hitting the lowest note possible and it's wrapping. I could put in a if condition to avoid the wrapping, but that adds overhead. Every instruction counts to keep up with MIDI data on a DMG.

Thank you for the new version trash80. I've put it through its paces and the pitch bend is really a lot smoother.

Your math seems to be off though, I'm testing with pitch bend range 0C and experiencing weirdness starting at notes below C-5: The pitch bend starts wrapping around at negative pitch bend values. At first only towards the end close to -100%, but the lower the note gets the earlier it happens, and finally at notes below B-3 things are starting to go random, with a random pitch jump for any value in negative pitch bend land. That's also the point where the positive pitch bend starts wrapping around like the negative did for notes below C-5.

I've recorded two simple examples to test the smoothness, when I noticed it happening to me. I'm playing a C-5 on PU2 and a C-4 on PU1 with a PB range of 0C being one octave up and down.
For the C-4 it wraps around at -50%, the next lower value jumping the pitch back to its original pitch. Take a listen. First mgb 1.3.2 and afterwards mgb 1.3.0 for smoothness comparison. Notice that the wraparound doesn't happen in 1.3.0

http://wolkenspeicherplatz.de/sound/mgb … arison.mp3

this is my automation curve for both channels

The shifting is to give some precision to avoid floating point math...

if(pbWheelIn[synth] & 0x80) {
    currentFreq = freq[noteStatus[synth_pitch]] + (((freq[pbNoteRange[synth_note_range+1]] - freq[noteStatus[synth_pitch]]) * (((pbWheelIn[synth] - 0x79)<<7) / 0x80))>>7);
} else {
    currentFreq = freq[noteStatus[synth_pitch]] - (((freq[noteStatus[synth_pitch]] - freq[pbNoteRange[synth_note_range]]) * (((0x80 - pbWheelIn[synth])<<7) / 0x80))>>7);
}

I changed it to +-7 bit precision. Check it out now: (v1.3.2)
http://code.google.com/p/arduinoboy/

And I'll optimize this later and rewrite it in asm. Don't have time lately.

it would be good if somebody could confirm that this also happens with an arduinoboy and is not a problem specific to the nanoloop usb dongle

Well I did some math of my own, and generated a frequency look-up table using MaxMSP, dividing each semitone into 128 parts.

https://www.dropbox.com/s/bgcok8265ixpe … -table.txt

There are 9216 values total. The first value is the lowest C, and every 128th value after that is the equivalent of a non-pitch-bended note one semitone higher than the previous. (the 129th value is C#, 257th value is D, etc).

Not pressuring you Trash80 or anything, I just thought maybe I could help out a bit

What is your current math, out of curiosity?

It may well be 32 steps at the fault of my math. (I do some shifting for precession since there are no floats) It's tricky to get the little guy working properly with as few instructions as possible. Maybe I'll rewrite it at a later time to use some sort of scaled lookup or something else.

Thank you Trash80! I will most likely try it out tomorrow.

The 32-step pitch bend is apparent even on low to mid range notes. Is the NanoUSB at fault here then? Is it only sending mGB a 5-bit pitchbend signal?

Can anyone with an Arduinoboy confirm that mGB will interpret higher-res pitch-bend messages sent from one?

Found the bug on PU1, it doesn't work if the Envelope is set to the 8th setting (the setting that is right before full sustain)
Weird, it may be a compiler issue. GBDK is really buggy- though that code is written in assembly.

*edit* mGB now to version 1.3.1 - Fixed this bug.

http://code.google.com/p/arduinoboy/