tests - marcosassis/gamepaduino GitHub Wiki

tests

tests made

tests with SNES and N64 controllers converting to USB HID and USB MIDI.

[new] tests with USB MIDI

this is HIGHLY experimental (although already shows good results)

refer to this thread for more details/motivation

'proof of concept'

a midi interface agnostic about MIDI transport

(i'm only sending commands, as it's what i need for now.)

this is midi_interface implemented for USB using MIDIUSB library:

midi_usb_interface

tested on

(windows7 64) MIDI-OX and Ableton* with success (no latency perceptible)

*(this a friend of mine, Monty Cantsin, tested for me)

this was one of the most funny things I ever did with arduino =]

and that's why

this is a N64 controller (original) playing MIDI notes AND pitch-bending then (analog x axis)

(i'm also happy because i really like template programming, so please don't judge my tastes =S.)

midi_usb_interface is used as

todo: move to examples wiki page and link here

// this uses an 'interval map + tone' method for playing MIDI notes as buttons are pressed
typedef midi_instrument<N64_gamepad>  N64_midi;

// this pitch bends any midi_instrument passed as parameter (type and base object)
typedef pitch_wheel<N64_midi>         N64_bender;

// this is midi_interface implemented (only send for now) for MIDIUSB (library adapter)
using   meta::midi::midi_usb_interface;

// initialization of everybody
int8_t note_map[N64_gamepad::N_BUTTONS]={0,1,2,3,4,5,6,7,16,9,10,11,12,13,14,15};
midi_data_t                                      basetone=69; // A4
midi_usb_interface            midiusb;
N64_midi           p1midi(p1, midiusb, note_map, basetone);
N64_bender         p1bender(p1midi);

bender is read on loop (and automatically play MIDI notes and commands when button pressed/released)

and, after all buttons->notes where processed, only then, communication is flushed. so, loop is:

  p1bender.read();
  midiusb.flush();

SNES MIDI (or general play MIDI notes)

pitch bend is crazy!! =D and it's a nice way to flood this MIDI communication and feel(as we're not measuring yet) the real time behavior of this thing

but if one doesn't have a N64 controller, but luckily have a SNES controller, they can test playing notes with gamepad too moved this example to x-area

tests todo

code todo

- try gamepad id 0 hehe
- 

things to test

here, we're first oriented by (physical) things, not by modules of software (see other wiki pages)

- test [3x] N64 c. + [2x] SNES c. on same board
- 

controllers

mine and tested

  • [_x] i have (first is number of items)
    • tests
      • code modules
        • boards
  • [3x] N64 controllers
    • tested simultaneously: [2x] : OK
      • with midi_instrument (over my prototype midi_usb_interface) : OK
      • with gamepad_joystick_adapter (USB HID) : OK
      • both with my [16MHz] pro micro board
  • [2x] SNES controllers
    • tested simultaneously: [2x] : OK
      • with midi_instrument (over my prototype midi_usb_interface) : OK
      • with gamepad_joystick_adapter (USB HID) : OK
      • both with my [16MHz] pro micro board
    • tested simultaneously: [4x] : OK
        • with previous versions / prototypes : OK
          • now everything is much more optimized, i'm anxious to buy more controllers and test full load multiplayer
          • (possible: [5x] for MIDIUSB and [4x] for JoystickArduinoLibrary)
  • heterogeneous controllers tests/setups
    • with [2x] two [16MHz] pro micro boards : OK
    • with [2x] SNES controllers on 1 pro micro and [2x] N64 controllers on another : OK
      • with gamepad_joystick_adapter (USB HID) : OK
      • in this test i could play multiplayer on ZSNES using N64 gamepads with almost as same mapping than SNES ones. (you can see respective files for details on ::bid 's of these interfaces.) opposite is also same (on P64), except that it makes no sense (since N64 games are designed to expect more kinds of inputs than with SNES).
      • [plugged on same PC]
          • it's important to notice that IDs on JoystickArduinoLibrary are the USB HID related IDs, so you have to define non-conflicting IDs, even on different boards, and that is it
          • besides this, JoystickArduinoLibrary limits the effectively number of possible endpoints to 4 (different joysticks showed by the same board)
          • the number of endpoints ATmega32u4 allows are 6, one i don't remember, other i think is for serial port(so if you don't want to program your device externally...)
          • gamepad HID classes IDs allowed are 1 to 4
            • this turns on USB/HID IDs as hidReportId=gamepadobj.id+2
⚠️ **GitHub.com Fallback** ⚠️