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?
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.
> 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?
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).
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" :)
notejam wrote: > 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).
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.
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.
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.
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" <note...@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).
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.
notejam wrote: > 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" <note...@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).
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" <note...@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).
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.
notejam wrote: > 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" <note...@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).
