AutoHotkey Community

TomB · Joined: 14 Jan 2005 Posts: 17

I know there has been some interest in the past in AHK supporting MIDI I/O. I have a real need that cropped up for MIDI output from AHK, which has turned into my little project from hell for the week. The bottom line is that I finally have it working, which I guess isn't too bad since I hardly new what a DLL call was before Monday. It has been a long and difficult process for me, but I am really excited to have this working, and I know some of you could benefit from this as well.

Below are three scripts. The first and most important contains the MIDI functions, which to a large extent are just wrapped versions of the DLL functions found in winmm.dll. However, in many cases, my functions incorporate several dll calls into one function. The latter two scripts provide examples of how to use the functions to actually output MIDI data.

I should point out the limitations:
1- There is no MIDI input here, which I suspect is more important to many of you than MIDI output. There are two good reasons for this - first, I currently only need MIDI output, and it was a big enough struggle getting this to work so I have no current plans to address MIDI input. Secondly, I am not sure MIDI Input is even possible in AHK right now, because I don't believe AHK is capable of handling callbacks from dll functions. This is required for MIDI input, since windows needs to callback to your script to let you know when MIDI data has been received. Callbacks are possible with MIDI output, but not required, which brings me to point 2:

2- There is no callback mechanism. IOW, the midi data is sent out and you just have to trust that it went. The only real issue I see with this is that you are practically limited to sending a single buffer of midi data. You can make that buffer as big as you want, but sending successive buffers would require a callback notifying you when to send the next buffer. However, if you are doing that kind of midi output, you probably ought to be using something more powerful than AHK!

3- SysEx data is not supported by this script. SysEx requires it's own special handling since it involves large, variably sized messages. I am confident that this could be done from AHK, but haven't tried it.

4- I am a big-time novice at programming, so my code is probably not as clean and efficient as it could be. If anyone wants to clean it up, I am totally open to that.

Note that there are two methods of sending midi output. The first is designed to send individual messages. Script #2 below shows how to do this. The other method involves filling a buffer with a series of midi events, which includes timing information for those events. That buffer is then sent to windows, which handles sending out the individual events at the proper time. This is a much better way of sending multiple events since it is less CPU intensive and is the only way from AHK to make sure the timing of the events is precise. This method is illustrated in script #3 below.

Finally, if you plan to use these functions, I highly recommend checking out this site:
http://www.borg.com/~jglatt/tech/lowmidi.htm

It is designed for C programmers, but it provides a great explanation of how the windows midi functions work, and how to use them. I don't know C from Q, but the examples here helped me tremendously in figuring out how to do this in AHK.

I hope this helps someone. I also hope this motivates someone to look into midi input and sysex.

EDIT: 4/30
I just discovered (the hard way) that when using the midi stream method, windows expects to receive a steady stream of midi buffers. If it doesn't get any for about 1s, the stream output goes to sleep. One nasty side effect (bug?) of this is that the next buffer you send it gets all of its events output at the exact same time. There are two ways around this - send buffers with "NOP" events, which are basically just dummy blank events, or stop or pause the stream after you send each buffer. For my purposes, and probably most practical applications involving AHK, the latter method makes more sense, so I have updated the MIDI Functions script to automatically stop the stream after sending the buffer. This cannot be done until the buffer is done being played, which means you now need to pass the duration of the buffer (in ms) to this function, so it knows how long to sleep. This is another case where having callback functionality would be helpful, but sleep does work. One slightly annoying "feature" of the midiStreamStop and midiStreamPause functions is that they automatically send out cc64 0 (turn off sustain pedal) on every midi channel. This kinda makes sense but I wish there was a way to bypass it. It should be harmless for most purposes, though.

TomB

MIDI Functions

Chris · Site Admin Joined: 02 Mar 2004 Posts: 10667

Great presentation and comments. You packaged evreything up very nicely.

This looks like it will be a great asset to users of MIDI.

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

I tried with the only MIDI playback device I have: "Microsoft GS Wavetable SW Synth", but the script gives an error message (There was an error opening the midi port…). Do I need a physical midi device? Other SW, like NoteWorthy Composer Version 1.75c happily plays back midi music through the speakers connected to sound output of my laptop.

TomB · Joined: 14 Jan 2005 Posts: 17

Laszlo,

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

I removed-reinstalled the audio driver (SigmaTel C-Major) and started the script before any application, still I only get the error message. Is there a way to take control forcibly over the midi driver? Or, to find out what uses it? Every music player I have plays back my midi files, even if there are more than one of them open.

TomB · Joined: 14 Jan 2005 Posts: 17

Laszlo,

majkinetor · Joined: 24 May 2006 Posts: 4114 Location: Belgrade

I will check it out with some of the number of virtual synts I have here.

Thx.
_________________

Sean · Joined: 12 Feb 2007 Posts: 2185

TomB · Joined: 14 Jan 2005 Posts: 17

Thanks Sean - I wondered if the callback to a window would work, but didn't look into it much since callback isn't required for midi out.

You are right about midi mapper. I forgot all about that since I never use it.

Tom

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

Device -1,0,1... all give error code 2 (bad device ID), although the Select Midi Port inputbox lists ID: 0 --> Microsoft GS Wavetable SW Synth

Sean · Joined: 12 Feb 2007 Posts: 2185

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

I guess the MS Wave device needs other parameters, than the SONAR fader. Does anyone know them?

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

There are a number of other bugs in the Streaming script, too. For example, the midiOutputBuffer function is called with one too few parameters, the second event is set up with dwMidiLowWord, which was never set, and therefore the dwEvent value becomes empty, but it is not used later.

Could someone, who knows about midi, fix the script, so it plays on midi device 0?

As I understand, the following should produce a beep, without all the fancy stuff, but it is as silent as the script in the first post.

Laszlo · Joined: 14 Feb 2005 Posts: 4502 Location: Boulder, CO

After a couple of days debugging I ended up rewriting the whole code. Now it works with the default midi device: ID 0: Microsoft GS Wavetable SW Synth. Most of the changes were bug fixes and simplifications, to reduce code size. The hardest part is TomB's original discovery work, which made midi output possible from an AHK script.

The general functions: