Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cool project for a Windows programmer with MIDI experience

10 views
Skip to first unread message

ham...@gmail.com

unread,
Sep 20, 2006, 7:01:00 PM9/20/06
to
Hi, a year and a half ago I started this thread in Autohotkey's forum:

http://www.autohotkey.com/forum/topic2831.html

Autohotkey is a free Windows programming language that allows you to
control the computer with the mouse, keyboard an joystick in many ways.
You can automate pretty much everything, and each user uses it in a
different way. One could say it's a bit geek oriented :)

I think adding MIDI input / output capabilities to Autohotkey would
make it a really cool addition for artists. Using any kind of MIDI
controller you could interact with any application: play a game with a
MIDI guitar, control Photoshop with knobs, start programs with your
synth... You could control Windows and any program with MIDI signals.

I know a C program that reads MIDI IN and prints to the console is just
a few lines long, but I don't know anything about compiling.

I think many potential users can't imagine controlling Photoshop or 3D
Studio Max with a 32 knob MIDI controller, but I believe it would be
very helpful, and could open a door to a new way of interacting with
the computer... It's like jumping from mouse and keyboard (maybe tablet
+ joystick) to a huge variety of MIDI hardware (keyboards, guitars,
drum pads, light sensors, motion detectors, distance sensors, flutes...
there are hundreds). I think it could go in the direction of interfaces
seen in Minority Report..

So the question is, is there anybody out there who thinks this could be
a cool idea, and who has programmed MIDI input and output before, and
willing to give it a try?

=)

notejam

unread,
Sep 28, 2006, 10:41:34 PM9/28/06
to
Glatt is working on midi rexx. You might contact him to add this type
of conrtoller to the language midi rexx.

Rexx is a language that can be programmed , but its neat feature is
that it can be used as a script language for communications between one
program and another.

But rexx will not be very usefull, until all program authors are
encouraged to put a rexx port in any programs they write.

A correctly written rexx port allows almost any and all commands, keys
and controllers used by the program to be set remotely from any
language that can drive rexx through a rexx script.

For computer programmers, Rexx allows them to write hybred programs,
for example they might write a program in basic, and then need some
graphic commands, well instead of programming in those graphic
commands, they can have their program give a command to launch the
correct program, and then just give the command to that program.
They can also move results from one program to another, such as midi
files, graphics, gifs, etc.

Now if a midi sequencer is made that also has rexx output, and a place
within it to enter external rexx commands, then it can also drive those
programs that have rexx ports.

This can be quite interesting. Bars and Pipes Pro, an old amiga
computer sequencer was such a program. With it, you could define any
key on your keyboard to launch and play any program, and give a command
you specified to that program.

So you could do neat things like play a song, and have a slide show
program that displayed slides, change every time you hit keys, and thus
have an animated graphic play in sync with your midi keyboard, then you
might have that low note in the song defined to launch a new program,
and it displays maybe kalidoscopes, and now the midi keys control the
design and what color is being used to draw with.

The power of rexx is not that its such a good language. Instead, your
faced with the unusuall situation of having a language that can do
things new with each and every program you buy that has a rexx port
This means the language keeps getting better, because every program
with a rexx port you buy adds new commands in effect to the language.
And the beauty of it is you do not have to program in rexx at all,
instead you can program in your favorite programming language as long
as that language has provision to give commands to external rexx
programs.

Contact Glatt here to add any ideas you want to see in midi rexx, or to
download the current version of midi rexx for ibm computers.
http://www.borg.com/~jglatt/midirexx/midirexx.htm

Message has been deleted

notejam

unread,
Sep 29, 2006, 2:18:28 PM9/29/06
to
Perhaps communication between programs could be handled by a file one
installed on a ram disk, and of course also install a ram disk program,
or worse, the hard drive.. Is that a ram disk on the windows install
disks? Talking about where it copys a lot of cab files to someplace,
then you can use them, think it might setup a ram disk?
Have not seen any ram disk programs for ibm, maybe thats not possilbe
either? Or some way re-direct a com ports communication?


Jeff Glatt wrote:
> >Rexx is a language that can be programmed , but its neat feature is
> >that it can be used as a script language for communications between one
> >program and another.
>

> >Bars and Pipes Pro, an old amiga
> >computer sequencer was such a program.
>

> Ah right. The Amiga version of REXX had the concept of "REXX ports", whereby
> each REXX-capable program had its own port, and a REXX script could send data
> back and forth between those ports.
>
> But with the Amiga, all applications ran in the same address space (so a crash
> of one app would bring the entire system down). Windows is a lot different.
> Each app runs in its own address space to protect apps from crashing the system
> or each other. But, data can't be easily sent back and forth between apps. It
> involves a lot more effort, and that's a lot of what "active scripting" is
> meant to do. The REXX interpreter I work on for windows is not an active script
> engine (although it does support COM, so could be used to pass data between
> active script aware apps. But this really isn't a very good realtime system.
> Windows data protection imposes a rather severe penalty upon realtime passing
> of data between apps. There are other, less-widely-supported means of passing
> data that may be more efficient, such as the WM_COPYDATA message).
>
> Incidentally, my web site address has recently changed to:
> http://users.adelphia.net/~jgglatt

ham...@gmail.com

unread,
Sep 29, 2006, 3:10:34 PM9/29/06
to
Hi,

A ram disk could be used (google "windows ram disk", I used one not so
long ago), but it would be much nicer just adding the MIDI input
capability to Autohotkey. I know it's not so complicated: one time I
compiled a simple MIDI IN dump tool which was about 15 lines of code...
I just would not like to install a huge C development kit and learn C
just to do something so simple, so I hope someone gets interested and
can do it. There ideas and details in the Autohotkey forum thread.

By the way... Bars & Pipes was my sequencer 10 years ago! :) I
sequenced many songs with it and a Yamaha SY-85. Nice to know someone
remembers it :) Gee... I just tried searching for an Amiga program I
did for editing SY-85 voices and it's still there to be downloaded in
many sites! google "ved.lha" :)

Message has been deleted
Message has been deleted

ham...@gmail.com

unread,
Sep 30, 2006, 8:51:56 AM9/30/06
to
I see... that's an interesting concept...

Would it be complicated to do a simple resident tool
that writes MIDI IN data in such a memory-mapped file?

I can propose some Autohotkey developer to make
it possible to read such file... Does it add much to the
filesize?

Thanks for your ideas!

Abe

Jeff Glatt wrote:
> >ham...@gmail.com


> >A ram disk could be used
>

> A memory-mapped file is easier, more flexible, and faster. For example, I have
> a DLL on my web site called "GenMidi". It lets a user define patch banks for
> numerous MIDI devices (ie, a "MIDI patch database"), and then every program
> that uses this DLL has access to that one, same MIDI database. When one program
> modifies the database, the change is picked up in every other running program.
>
> I use a memory-mapped file to load/contain the database, and that's what makes
> it possible for numerous running programs to all share the same data
> simultaneously, in an efficient manner.

Message has been deleted

ham...@gmail.com

unread,
Oct 1, 2006, 9:09:05 AM10/1/06
to
Oops maybe I didn't explain the basic thing...

Autohotkey is already able to control absolutely everything in Windows.
It can launch applications, send keys, examine and edit interface
controls present in other programs, read and write files, bring windows
to front or back... lot's of things. So it can already do everything I
want, and people are writing really crazy scripts that automate
Windows. Here some examples:
http://www.autohotkey.com/forum/topic3284.html

The only limitation is that it only takes input from keyboard, joystick
and mouse. It's really good at it. You can do strange keyboard
shortcuts: for example, I launch programs when holding the mouse button
down (on a blank place on screen) and then pressing a key on the
keyboard. I also have shortcuts that involve two keys (not necessarily
CTRL, SHIFT or ALT, but maybe z and x). Or you can detect key
sequences, or mouse gestures.

Anything is possible, except MIDI input. When adding MIDI input to
Autohotkey, you could control the whole system with any MIDI device,
and use real hardware as an interface for any window in any program.
Then, on top of keyboards and mice, we could use lots of MIDI hardware
to get our work done.

Autohotkey is open source. But I haven't found anyone yet willing to
have a look on this MIDI issue, I believe because people can not really
imagine what could be achieved...


Jeff Glatt wrote:
> >ham...@gmail.com


> >Would it be complicated to do a simple resident tool
> >that writes MIDI IN data in such a memory-mapped file?
>

> I'm not entirely sure what your intentions are. For example, you mention
> something like:


>
> >controlling Photoshop or 3D
> >Studio Max with a 32 knob MIDI controller
>

> Getting MIDI Input is fairly trivial. And you don't need a memory-mapped file
> for that. You just use midiInOpen() to open whatever MIDI IN you want, and have
> a callback to store incoming MIDI data. My article at
> http://users.adelphia.net/~jgglatt/tech/lowmidi.htm explains it, and gives C
> examples.
>
> The real problem you have is controlling one application from another
> application, especially if the first (ie, controlled) application is not
> written to have any sort of special "automation" features.
>
> So, the first thing to determine is what automation features, if any, the
> application you want to control has. Are you going to be doing something fairly
> primitive such as sending its application window messages to simulate the
> enduser operating the application? Then all you need is FindWindow() to locate
> the app window you desire, and SendMessage() or PostMessage(). (It sounds like
> this is how Autohotkey works).
>
> Better yet is to see if the app supports Active Scripting. If so, then you can
> use COM to directly control the app, thus bypassing any need for some
> programming language add-on. See my series of articles on CodeProject entitled
> "COM in plain C" for more information about COM.

Message has been deleted

notejam

unread,
Oct 2, 2006, 9:42:48 PM10/2/06
to
Jeff,
I barely remember having used a program that controlled other programs
by voice and its an ibm program. Think it might be voice commander,
but I know for sure its on one of the install disks for the real old
sound card sound blaster live platinum, but only if you get the package
that was published with all the free software bundles of audio/midi
programs. (about 3 cds of midi/voice and sound programs, and 2 or 3 cds
of games.)

What was interesting to me about this program was it some way got the
command names of programs I wanted to use with it, into its own program
and would auto matically recognize those commands. You did not even
have to type in the list of available commands in the voice command
program. It seemed almost like the good ol days on the amiga with
rexx.
I also can not quite remember the code name for this, but it was
something like amappi or sapppi or ? Think it might be some ibm
standard for software to aid handicapped to use programs?

Any way if that rings a bell, it might be a usefull standard to get
working with your midi rexx.
, enough so that I think it might be worth your time to try and track
down that software package for soundblaster live, and take a look into
this a bit deeper. The midi program I ran by voice commands was an
early version of Jammer so you might be able to get some info from them
over at www.soundtrek.com/content/index.php regarding how the voice
command program could possibly get a list of commands into it, and give
those commands to an external program such as their jammer program.

There are most likely quite a few programs that were written to be
compatible with this voice command program in the early days of ibm
software, so if you can get it working with midi rex, it might give you
quite a few programs that would work with midi rex.

Drat, wsih I could remember the name of that program, I know there were
several such voice command programs on the several cds that came with
the card.

http://www.soundtrek.com/content/index.php

Jeff Glatt wrote:
> >ham...@gmail.com


> >Autohotkey is already able to control absolutely everything in Windows.
>

> Ah, what I was talking about is eliminating the need to use Autohotkey
> entirely, and instead using COM to control Active Script supported
> applications. This seems to be a more robust manner of control than what
> Autohotkey uses. Also, it means that you can write your script in any supported
> Active Scripting language, such as VB, VBscript, Javascript, Python, etc.


>
> >Anything is possible, except MIDI input.
>

> Here's the crux of the matter then. You need to get Autohotkey to get its input
> from a MIDI port. I don't know much about Autohotkey's particulars, but if its
> input routines are hard-wired in the code itself, then you need to
> modify/compile the original sources for MIDI input. On the other hand, if
> Autohotkey is written so that its input can be taken from some sort of
> "plug-in" (perhaps a specially written DLL, or a COM component), then adding
> MIDI input will not be much of a chore.

Message has been deleted

notejam

unread,
Oct 3, 2006, 6:00:15 PM10/3/06
to
The programs were all windows 98 programs. Some 98 programs can work
in xp.
Some of the names of the voice operated programs were voice commander,
prodigy parrot, and ibm via voice. Think there might be 1 or more too.

There must be lots of programs out there that can take scripts, and all
you would have to do to identify script runnable programs, is test them
with this program to see if it got the list of commands or not.

If you can ever route rex to send scripts commands to the same place,
you would have a very large base of software that could work with
scripting from rexx.


Jeff Glatt wrote:
> >"notejam" <not...@sbcglobal.net>


> >a program that controlled other programs

> >software, so if you can get it working with midi rex, it might give you
> >quite a few programs that would work with midi rex.
>

> MIDI Rexx is really just plain old REXX for Windows, with some MIDI add-ons.
> The REXX interpreter part of the package is called Reginald. And Reginald has
> functions that are equivalent to Visual Basic's CreateObject and GetObject,
> plus it supports the concept of a "REXX COM object". So Reginald can already be
> used to control any program that supports active scripting, such as Office,
> Word, Excel, etc.
>
> (But not being an ActiveX Script engine itself, the limitation with Reginald is
> that the control must happen from a separate process, rather than the same
> process as the controlled application. The former approach is not as efficient
> as the latter, even though this is completely transparent to the person writing
> a REXX script).

notejam

unread,
Oct 3, 2006, 7:03:04 PM10/3/06
to
Can you add cursor recording and playback, and these become a macro
that can be triggered from rexx? One program does this curser
recording to launch other programs. Think they just record the memory
cell or place where the mouse or joystick connect, and any mouse clicks
etc. Then for playback they just stick it to the joystick or mouse
location and it seems to the programs just like the user did it with a
controler.
Message has been deleted

notejam

unread,
Oct 4, 2006, 8:12:17 PM10/4/06
to
Yes the com port would be the reliable way, but seems to me that to
have the alternate way would be great for those programs that do not
accept scripts.Not every program around is going to be able to
communicate with rex scripts from a com port. It would also need to
record keyboard keys and play them back if needed.

Just have a warning about how it could go wrong, and let it be the
users responsibility to have the program running with window open
correctly before any rexx macro commands be issued to play back mouse,
cursor, clicks, and keyboard keys.

A screen reader would be great too, I have at times wished I could
capture text in a web browser and process it from another program and
do so live, rather than the cut and paste method.

Jeff Glatt wrote:
> >"notejam" <not...@sbcglobal.net>

> >Can you add cursor recording and playback, and these become a macro
> >that can be triggered from rexx?
>

> You can do that by calling the appropriate system APIs, such as mouse_event()
> to simulate mouse moves/clicks.
>
> I have a web page on REXX at
> http://users.adelphia.net/~jgglatt/rexx/rexxuser.htm which contains an example
> scripts page. One of the examples, named mousesim.rex, is a REXX script that
> creates a few simulated mouse events.
>
> But you have to understand that this is a very old-style, crude, and
> error-prone approach to controlling another application. After all, who gets
> the mouse events? Whatever program happens to have the input focus, and the
> enduser can change that at will, perhaps at an inadvertently disasterous time.
>
> Active Scripting (ie, COM-based control of applications) is really the more
> versatile, predictable way to control an application. (And Reginald does
> support COM). If the app you want to control implements Active Scripting, then
> the preferable way to control it is to get a script language that also supports
> COM, and write a script to utilize that. (Think of a Windows app's Active
> Script implementation as analogous to an Amiga app's REXX port. Although they
> do things in a different manner internally, they both are meant to ultimately
> serve the exact same purpose. The big difference is that, while an Amiga's REXX
> port can be controlled only from Amiga REXX or a compiled language such as C, a
> Windows' Active Script implementation can be controlled by not only any
> compiled language, but also any script language that supports COM. And most
> Windows script languages do, such as Visual Basic, Perl, Python, Reginald REXX,
> etc, etc).

notejam

unread,
Oct 4, 2006, 9:03:32 PM10/4/06
to
Think the voice command that used curser recording, got around the
problem of risk of triggering the wrong thing, by limiting the
vocabulary of commands to what ever window was on top. That way it was
impossible to accidently trigger windows commands or other programs or
copy one program to a place you did not want it copied.

The vocabulary list of commands available changed depending on what
window was on top.

0 new messages