Search options (Page 1 of 3)

You probably have an old version on LSDj. In newer versions, the WAV channel correctly indicates the octave by show C2 as the lowest note, not C3.

So half clocking effectively gives you C1 as your lowest note on the WAV channel, and C2 on the pulse channels.

What kind of waveform does this sound resemble?

Except from what I understand, this is impossible because there isn't enough room in the ROM file for six full-screen images, only three. Unless it's possible to expand the graphics memory on a ROM?

I'm probably going to make a 9-color version of this with three frames at some point.

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

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?

Thank you for making this thread, I was going to bring this up as well. I think it would be great to be able to set the pitch bend resolution higher within mGB, because when you are using higher pitch bend ranges, 32 steps is just not enough.

For arpeggios, the documentation states that if you send another note the same velocity as the previous note, it will not retrigger a note-on message, which allows for the arps you're looking for without any pitch bends required. In my experience, only PU2 consistently demonstrates this feature, and for PU1 you need to mess will the channel parameters a little bit (change pulse with, envelope, sustain on/off) and then the feature kicks in.

I remember somebody saying that the pitch-bend algorithm is particularly CPU intensive, as it calculates the frequency on-the-fly. This might be the reason the PB resolution is so low, so it doesn't affect speed of playback. Would it be possible to: instead of having the DMG calculate the frequencies every time there is a pitch bend into 32 steps, have a table of frequencies built into mGB, dividing each semitone into something like 32 steps? Then even with very high PB ranges (that maximum I believe is ±48) the mGB could start to interpret the finetune low-byte messages and have smooth, non-jumpy, tunable pitch bends.

Not to look a gift-horse in the mouth. mGB is great, however with the event of the NanoUSB being much more accessible than ArduinoBoys, an update would benefit a much larger group of people than in the past.