Syncing in MIDI mode is not recommended. If there is really nothing else than a clock signal, it may work for LSDj, but most likely not with nanoloop. Both take *any* signal for a clock. If a START message is sent, too, for example, the Game Boy is already out of sync. Plus you never know if the host app really just sends sync, there can always be some NOP SysEx bytes for testing for example.
I'll have a look at the nlmidi software later today. It should be possible to port it to any platform that supports the MIDI device.
Offline
Offline
the heart of a mountain
oliver wrote:
Syncing in MIDI mode is not recommended.
So was I right in thinking that I want to be in -SYNC mode for what I want to do...sync nanoloop to MTC?
If you want me to try any revisions of nlmidi...let me know.
Offline
New York City
oliver wrote:
I'll have a look at the nlmidi software later today. It should be possible to port it to any platform that supports the MIDI device.
Did you manage to listen to my example file?
Offline
New York City
eme7h wrote:
Somebody has tried this with OSX?
I did try version 2, it didn't work.
Any news, Oliver?
Offline
I have experimented again with the adaptor, mGB and the following combination:
- GB pocket
- GBA
- Ableton Live lite on OS X
I created patterns in the sequencer for all 4 channels with lots of 1/32 notes. With the adaptor's default throttling, there were no issues as long as
- sync was deactivated,
- not more than one note was playing at once per channel (mGB plays only one note anyway),
- no continuous controller data were sent (edit pitch bend, volume etc only with the pencil tool).
I think the problem lies within mGB, it is simply not fast enough to process a full MIDI stream. When the throttling is too fast, mGB misses notes, when it's too slow, there will be jitter. You can only try to optimise the MIDI output as described above and then find the fastest rate with the throttling parameter at which mGB works reliably for you. I thought I had found this optimum with the preset throttling rate, but it turned out that it's slightly too fast for some setups.
I assume that Arduinoboy adds throttling, too. I asked trash80 about this and he said he doesn't know for sure but would try to measure the output.
Maybe someone can re-write the mGB code for MIDI processing in ASM. I'll also have a look at pushpin again, which was designed to work with real MIDI speed and should have no problems with the adaptor's input.
Offline
Matthew Joseph Payne
oliver wrote:
I think the problem lies within mGB, it is simply not fast enough to process a full MIDI stream.
Yeah, I've had issues just playing mono keyboard parts into the thing - fast passages always get tripped up - it always seemed like note quantity is where it choked. Is this also why pitch bends seem to screw it up pretty badly?
Offline
New York City
oliver wrote:
I think the problem lies within mGB, it is simply not fast enough to process a full MIDI stream. When the throttling is too fast, mGB misses notes, when it's too slow, there will be jitter. You can only try to optimise the MIDI output as described above and then find the fastest rate with the throttling parameter at which mGB works reliably for you. I thought I had found this optimum with the preset throttling rate, but it turned out that it's slightly too fast for some setups.
I'm really sorry, but I don't think mGB is at fault. Why would Trash 80 add a MIDI specification where you can modify all those parameters without the software supporting it at full speed? I know you can brick a DMG with certain things, I've done it on LSDJ, but simple operations like using two pitch bends? Really?
Using an Arduinoboy, commands like pitch bend or volume are totally supported. Then there are the commands to change instrument parameters which you should be able to change in real time as well. And then even if I don't use these things at all, the system is choking on notes.
You wouldn't be able to do this at all if mGB was at fault
When can we expect to get fixed binaries for Windows and OSX already that support throttling tweaking so I can use the device as intended and advertised?
Pushpin runs only on Color Gameboy, which has a clock speed DOUBLE that of a DMG. DMGs are what most people use.
Last edited by akira^8GB (Mar 6, 2012 11:47 am)
Offline
I'll update the utility later today.
I don't see how the adaptor could be the problem. In the default MIDI mode, it's simply an USB-MIDI to SPI-MIDI converter (SPI is the Game Boy serial link format). It does nothing else than forwarding MIDI data received over USB, with adjustable speed. Multiple MIDI bytes can arrive in a single USB packet, the adaptor therefore buffers the MIDI bytes and sends them out at an adjustable rate (=throttling). If this rate is set to the physical MIDI rate, the output should be exactly the same as from an unbuffered (real, non-USB) MIDI-to-SPI converter.
When fed at this rate, mGB misses a lot of notes and runs unstable. When throttling is increased, it gets more stable, but at the cost of increased jitter. This lets me assume that mGB can't handle data at MIDI speed and Arduinoboy does some buffering and throttling, too.
Offline
That video is impressive but the music has a very shuffled rhythm which makes it hard to tell if there is some jitter caused by Arduinoboy's buffering.
Offline
Sweeeeeeden
Remind me to do a GB side utility which measures the exact timings the GB receives.
Offline
New York City
nitro2k01 wrote:
Remind me to do a GB side utility which measures the exact timings the GB receives.
Yes, please
Offline
Matthew Joseph Payne
Man, I wish my Arduinoboy-in-a-DMG-07 looked as clean as that one!
Offline
Unsubscribe
Hey Akira - Maybe you should post your test project and we can test the sequencing on a real aboy and see if it has the same problems.
Offline
I measured the timing of the adaptor's SPI output by simply touching the clock pin with a small jack cable connected to the PC's line in and recording the clock pulses at 44.1 khz. At this resolution, no individual clocks are visible, but each byte gives a spike. At MIDI speed, one byte (the period from one byte's start to the next) should take 44100/3125 = 14.112 samples.
It should be mentioned that the voltage on the clock pin exceeds the standard voltage for line in and may damage the line in. Try it at your own risk.
Last edited by oliver (Mar 6, 2012 2:04 pm)