Re: playing a MIDI-file

> At 05:59 PM 2001-01-20 +0100, Michael Koenig wrote:
> > I would like to write a perl-script where 
> > I would like to play a midi-file.
> >
> > Is there any possibility to do so 

The short answer:  yes.  

Basically what's needed are 

(1) an API to send bytes to MIDI devices.  MIDI::Realtime appears to 
offer some of this, though only on Unix boxes with a /dev/sequencer
--- has anything further been done on MIDI::Realtime since 1999?  

Windows has its own MIDI API which is accessible to Win32::API
but is mostly different, of course.

(2) a high-resolution (<1msec) timer, i.e., not just being able to 
get system times at that resolution, but also being able to reliably
schedule interrupts with that resolution (which usually means being 
able to bump up the process priority),..

... and of course Timer::HiRes doesn't work on Windows because Windows
doesn't grok select() or signals, however Windows has its own notion of 
"multimedia timer"; API is, again, competely different.

(3) some kind of timer loop

As it happens, I actually have this much working in ActivePerl under
Win2k/NT, and while I have this strong sense of Having Reinvented The
Wheel, I don't see anything similar advertised on CPAN anywhere so,...

... is it worth the effort for me to get this from its current
cobbled-together state to something vaguely releaseable, or are
people completely happy with their external programs or using
Something Else that I've completely overlooked?


> > or do I have to start the midi-player of my OS.
> 
> From: "Sean M. Burke" <[email protected]> 
> Just out of curiosity, what would be the advantages of not using an
> external program?

Various problems with external programs in no particular order:

(0) external programs can be buggy in various ways.  I've noticed that
with Creative/Soundblaster's player (and perhaps others), if you give
it a standard MIDI file having a SMPTE division parameter rather than
a ticks-per-quarternote division parameter, COMPLETELY IGNORES the
frames/sec portion, assuming what appears to be 29 or 30; even if,
say, you wanted 24 or 25 --- the difference is quite noticeable.

(1) It takes time to fire up an external program.  At least, with the
some of the ones available under windows (*), there's a noticeable 
delay while they paint their silly GUIs.  This is particularly annoying 
if you want to loop something or chain stuff together.

(2) One might desire some kind of control over the progress of the
playback, e.g., being able to mess with tempo or various control
settings as the playback progresses, perhaps synchronizing this with
events in the playback stream.  

(3) Under Windows, whoever opens a MIDI device gets exclusive access,
so if the external program gets to fire messages at it, the parent 
process does not.  (No idea whether this is OS braindeath or 
soundcard driver braindeath).

(4) Are there players that let you introduce new data mid-play?  
If not, then if you want to play something that's being generated on
the fly, you lose.  (I'm guessing most of the Windows players use
Microsoft's Media Control Interface (MCI), and MCI doesn't seem to
allow this, it being a bit of work and probably not justified for the
typical home user who merely wants to play mp3s, CDs or whatever...)

(4a) There's a certain annoyance/latency in having to generate actual
files on the disk.  Granted, MIDI files are usually so small and the
disk cache might work well enough that you don't notice.  (yes, I know
about pipes, but that assumes the existence of a nonbraindead player
that can accept MIDI file data on stdin; see (2)).

  - - -

In my case, I wanted to be able to do loops or merges of various event
sources and play along with them; external programs are probably not
the way to go for this.


(*) w.r.t. the "why don't you switch to Linux?" solution to some of
these problems; that's a complex issue that's arguably outside the
scope of this list.