MIDI input support

[GoogleCodeExporter]

As posted here: http://www.fretsonfire.net/forums/viewtopic.php?f=11&t=32478
"This is a patch for "Frets on Fire : My Fingers Hurt 3.0" to allow the
player to use a MIDI device as input without removing any existing support
for other input devices.
...
This patch will attempt to use ALL MIDI inputs as valid inputs. Then, to
associate the input to a pad (for drums) or any other instrument for that
matter (midi guitars?), just go to the options and configure them normally.
Hit the pad you want to use for the appropriate pad, and it'll identify it
as "Midi #x-y" where 'x' is the input used (or 'port') and 'y' is the pad
on the device itself. In other words, if you 'move' the drum set, you'll
need to setup your pads again. This is because in the world of MIDI the
drums don't identify themselves uniquely, just what they are, so I'm afraid
that's just how it is. On the other hand; if you have, say, 8 pads and two
pedals, you could move them around and allow two players to share one set.
(That's right, this will work!) Groovy.
..."

Original issue reported on code.google.com by death.au on 9 Jan 2009 at 9:56

[GoogleCodeExporter]

Nice... I have applied this patch to the Input.py, so MIDI support should be in 
FoFiX
now.  Looks like we'll have to add the MIDI module to the required source 
modules
(with a note that it's only required if you want to use MIDI inputs):

http://trac2.assembla.com/pkaudio/wiki/pyrtmidi

Original comment by chris.paiano@gmail.com on 10 Jan 2009 at 4:45

• Changed state: Fixed
• Added labels: Milestone-Release-3.100, Type-Enhancement, Usability

[GoogleCodeExporter]

Original comment by chris.paiano@gmail.com on 10 Jan 2009 at 4:46

[GoogleCodeExporter]

Committed in r734 (after completing the fallback logic that the author started 
- it
must work without the pyrtmidi module!)

Original comment by chris.paiano@gmail.com on 10 Jan 2009 at 4:59

[GoogleCodeExporter]

So what about keyboard support now...?

Ha ha. I kid, I kid.

Original comment by lysdestic@gmail.com on 10 Jan 2009 at 5:04

[GoogleCodeExporter]

I just noticed this and the fact that there seems to just be the svn repository 
of
this module and no builds or even source releases available anywhere.

As a result, I made builds of the latest svn and posted them in my mediafire.  
I make
no guarantees as to whether the builds will actually work as I have no MIDI 
stuff to
test with.

Original comment by john.stumpo on 11 Jan 2009 at 1:26

[GoogleCodeExporter]

I just tried the rtmidi installer 0.1 for 2.4 and the game always crashes with a
segfault - sources or from exe.  Uninstalling seems to be the only way forward 
here,
no log entry either.

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 1:36

[GoogleCodeExporter]

Actually, it works fine on my desktop - my laptop crashes.  I suspect this is 
because
the laptop has 0 midi ports... I'll fix this.

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 1:38

[GoogleCodeExporter]

Well, it looks like I can't fix this... when the rtmidi module is present on a 
system
with 0 MIDI ports available, FoFiX can't start up.  Always crashes with a 
segfault.  

Guess I'll take a look at the rtmidi source code... I can't create a beta 
release
with the rtmidi module unless this is solved.

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 2:49

• Changed state: Started

[GoogleCodeExporter]

Interesting snippet from the RtMidi.cpp - I still don't know how to fix this 
but:

1426    void RtMidiIn :: initialize( void )
1427    {
1428      // Initialize the Irix MIDI system.  At the moment, we will not
1429      // worry about a return value of zero (ports) because there is a
1430      // chance the user could plug something in after instantiation.

but here with FoFiX, we need to worry about a return value of zero ports -- 
because
it causes a segfault!  hmm...

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 2:52

[GoogleCodeExporter]

According to my trusty debugger, it's happening when the error handler tries to 
write
stuff to std::cerr.  This probably is doing bad things because of some 
interaction
between the way gcc (which I used to make my build) does things and the way VS 
(which
Python was built with) does things.

I've successfully used modules containing C++ code that I built with gcc 
(indeed,
this describes all of my pitchbend builds), but none of it ever tried to use the
standard iostreams since in a Python module you're really supposed to go 
through Python.

Now experimenting with potential fixes...

Original comment by john.stumpo on 11 Jan 2009 at 4:46

[GoogleCodeExporter]

The module has been rebuilt and reuploaded with the writes to std::cerr 
commented out
(wiki link updated, patch posted as well), and things are looking up.

Original comment by john.stumpo on 11 Jan 2009 at 6:05

[GoogleCodeExporter]

Indeed - uninstalling the old rtmidi module and installing the one you just 
fixed and
uploaded and linked in the Wiki fixes the problem on my laptop; I can now 
enable the
rtmidi module initialization code and my laptop still starts playing FoFiX just 
fine.
 Even has the correct log entries and all.

Committed in r751:

rtmidi module is enabled if found now, as having 0 midi ports no longer causes a
crash with js's latest build of it.

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 6:27

[GoogleCodeExporter]

Original comment by chris.paiano@gmail.com on 11 Jan 2009 at 6:27

• Changed state: Fixed

[GoogleCodeExporter]

Crash caused by a missing MIDI decode function should be fixed in r775.

Original comment by chris.paiano@gmail.com on 13 Jan 2009 at 3:36

[GoogleCodeExporter]

http://www.dogsbodynet.com/fileformats/midi.html#EVENTS

MIDI event numbers for NOTE ON and NOTE OFF events fall within a range, and they
change for each of the 16 channels.

I will attempt to write some Python code to properly handle the incoming MIDI 
events
for everyone.

Original comment by chris.paiano@gmail.com on 15 Jan 2009 at 11:20

• Changed state: Started

[GoogleCodeExporter]

New library.zip for 3.100 beta 1 can be downloaded here to test this new MIDI 
logic
(built from SVN r785):

http://www.mediafire.com/?3hzo122dnxf

Original comment by chris.paiano@gmail.com on 15 Jan 2009 at 11:37

[GoogleCodeExporter]

Oops - forgot the velocity = 0 note on = note off event thing.  
Committed as r786.

New library.zip download link (inside the RAR):
http://www.mediafire.com/?mudnzmye0w3

Original comment by chris.paiano@gmail.com on 15 Jan 2009 at 11:45

[GoogleCodeExporter]

Here's something else you may want to add:

Codes 0xb0-0xbf are MIDI controller events, which some MIDI stuff uses for 
various
things, especially out-of-band stuff that is musically significant.  The next 
byte
identifies the control event, and the byte after is the associated value.  (By 
way of
example, a keyboard pedal on channel 1 will send 0xb0 0x40 0x7f when the pedal 
is
pressed, and 0xb0 0x40 0x00 when it is released.)

You may also want to include the channel number (which is (midimsg[0] & 0x0f) + 
1) in
the encoding of the events when they are passed to the input layer.  Some 
people may
find channel separation useful.

(For curiosity purposes, 0x00-0x7f are invalid, 0xa0-0xaf are note aftertouch,
0xc0-0xcf are instrument change, 0xd0-0xdf are channel-wide aftertouch, 
0xe0-0xef are
MIDI pitchbending, and 0xf0-0xff are control messages and other miscellany.  
None of
those are particularly useful to us, so we should probably just ignore them as 
we
already do.)

Original comment by john.stumpo on 16 Jan 2009 at 3:18

[GoogleCodeExporter]

All good general MIDI information... but I believe everything that is needed 
for this
particular function is now implemented.  Channel information isn't needed at the
moment, MIDI notes are just mapped to inputs.  

However, should the need arise, your comment will provide useful info to further
expand the capabilities of this feature.

I have heard from a user with a MIDI drumset that this is working fine as-is.  
I'm
going to mark this as "fixed" until I hear otherwise from someone with a MIDI
instrument that isn't behaving correctly.

Original comment by chris.paiano@gmail.com on 16 Jan 2009 at 6:54

• Changed state: Fixed