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?
=)
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
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
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" :)
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.
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.
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.
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).
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).
The vocabulary list of commands available changed depending on what
window was on top.