Wednesday, December 29, 2010

multi-platform MIDI library

I tried RtMidi on Windows and OS X 10.6.5 (Snow Leopard). Unfortunately, SysEx messages sent via RtMidi on OS X would only be sent after starting another application that also uses Midi (SysEx Librarian or MIDI Monitor, both from snoize.com). Otherwise, SysEx messages would simply not be sent, while RtMidi would fail reporting any errors. It seems, RtMidi is skipping some CoreMidi initialization.

I followed this advice how to build portmidi using MinGW on WinXP, and it worked:
http://cratel.wichita.edu/cratel/cratel pyportmidi#build_portmidi_.28MinGW.29
It's unfortunate that this Makefile is not distributed with portmidi.

Sending SysEx with portmidi worked on both OS X and WinXP.

As a side note, one of RtMidi's objectives: "object oriented C++ design" fails to really hold. RtMidi defines a abstract root class RtMidi and extends it by RtMidiIn and RtMidiOut. Defining a common super interface for both sending and receiving midi doesn't hold up very well, as the sample program sysextest.cpp exemplifies:

bool chooseMidiPort( RtMidi *rtmidi )
{
bool isInput = false;
if ( typeid( *rtmidi ) == typeid( RtMidiIn ) )
isInput = true;

What good is the RtMidi abstraction if just a few lines further down you break it again?

Furthermore I'd consider it both from an ethical and an engineering point of view a cleaner design to openly use portmidi instead of cannibalizing some of its code (see RtMidi.cpp):

// This function was submitted by Douglas Casey Tucker and apparently
// derived largely from PortMidi.
CFStringRef EndpointName( MIDIEndpointRef endpoint, bool isExternal )

...

// This function was submitted by Douglas Casey Tucker and apparently
// derived largely from PortMidi.
static CFStringRef ConnectedEndpointName( MIDIEndpointRef endpoint )

Friday, December 24, 2010

Changing default shell in mingw msys shell

I'm using:
MINGW32_NT-5.1 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
on OSX 10.6.5 (Snow Leopard)
And tried to change the default shell from sh to bash.

This didn't seem to work for me:
http://digital.blogsite.org/index.php/2009/07/23/how-to-change-default-shell-in-msys-ming

But this did:
http://oldwiki.mingw.org/index.php/MsysShell

I actually just put a .profile in my homedir with these contents:
#!/bin/sh.exe
/bin/bash

Tuesday, September 7, 2010

MacPorts Perl CPAN on OS X 10.6.4 Snow Leopard

Try to install CPAN Modules in your non-root account for your MacPorts Perl on OS X 10.6.4 Snow Leopard and you're in for some nasty surprise:
You'll find your local MyCPAN.pm will eventually be silently ignored and ~/Library/Application\ Support/.cpan used instead. As much as I detest fiddling with the configuration of standard tools in OS X, I had no choice:
cpan
o conf build_dir /Users/bwagner/.cpan/build
o conf cpan_home /Users/bwagner/.cpan
o conf histfile /Users/bwagner/.cpan/histfile
o conf keep_source_where /Users/bwagner/.cpan/sources
o conf prefs_dir /Users/bwagner/.cpan/prefs
o conf commit
After this change and removing my ~/.cpan and starting afresh, things worked out.
The terrible thing is, this behavior starts only after installation of some particular modules. As it turns out it happens after the direct or indirect installation of File::HomeDir. Good luck trying to figure that one out.

Here are some related posts:
http://www.nntp.perl.org/group/perl.module-authors/2009/09/msg7886.html
http://www.nntp.perl.org/group/perl.module-authors/2009/09/msg7891.html
http://rt.cpan.org/Public/Bug/Display.html?id=32841
https://rt.cpan.org/Public/Bug/Display.html?id=43549
http://jjnapiorkowski.vox.com/library/post/trouble-installing-with-cpan.html

Any user who tries to install modules from CPAN as non-root user on OS X will run into this problem. Apparently it's known since early 2008 ...

Saturday, January 30, 2010

US legal system: what you risk as an employee

comment to Chip Salzenberg's legal issue. A follow-up by Mark Jason Dominus.
Or the David McOwen case, also written up by Ann Harrison, SecurityFocus.