errantember

After nearly a month of intermittently looking at the problem, I finally have come to the conclusion that MIDIStroke doesn't differentiate between the three different types of MIDI signals at *all*. The idea that it did was what sent me off on this wild goose chase to begin with, since it would be kind of stupid if a program treated playing note #5 the same as changing to instrument #5 or the pedal passing point 5 our of 128, but, evidently, MIDIStroke is stupid.
( Read more... )

I *finally* found the location of the *actual* MIDI message inside MIDIStroke! It's at 0xF007FD6E! Of course! I was already pretty excited when I discovered the part of it moved into r2 looked like the preamble for a note-on, but after changing the MIDI transmission channel and hitting the key with different levels of force, which changes the velocity number at the end of the note, I'm 100% sure I've got it!

The path from this info to finding out what needs to be in the box to make my pedalboard work should be *short*. I'm *very* pleased with myself!

Go me!

Eventually I will post a link to a little presentation that explains all of this in more laymen understandable terms, at which point it won't be *nearly* as rad.

By stepping through the MIDIStroke program after having sent one each of the three different MIDI signals I'm interested in, I was able to create a map of the path through the program that each different kind of messages travels. By then overlapping these maps, I was able to see which parts of the program are used for each kind of message exclusively, and which ones are used by more than one. So now I have it narrowed down to about 20 or 30 lines of code where I *know* the program is figuring out which kind of message it's getting and responding accordingly.

Now I just have to figure out what's actually going on in those lines of code. On a processor I've never worked with before. At 2:20 AM.

...

Time for bed!

Or, if you don't have the source, go to the assembler. :)

I made a bit more progress in using the GNU Debugger to run around inside MIDIStroke, and also made some progress in disassembling the entire program using otool. It does look like it might be possible to actually figure out the encoding scheme for program changes and control changes using this method, thought it won't be easy. For those generally unfamiliar with this sort of thing, what I'm doing is taking a complete program and looking at it's guts to try to figure out something about how it works. When you create a program, you have something called "source code", which is a sort-of englishy-language description of how you want the program to run. The computer can't read this, though, so it has to be translated into machine language, which is called assembler. Generally, when you're using an existing program you didn't write, you only get the assembler to look at, which is very much akin to trying to figure out how a car works without having the design diagrams or any manuals.
( Read more... )

I'm now one step closer to getting this to happen in my bedroom. This being the ability to create any number of looping music samples in real time with my voice in order to create a song. The main thing that was stopping me was a lack of understanding how an incoming MIDI signal (say, hitting the middle-C on my piano keyboard) could be converted not into one, but several keystrokes in a row. I've now figured out how to do that with MIDIStroke, a free software program expressly for that purpose. Now that I know how it's done, I just need to get the template all set up to record and control the loops in real time using the right combination of keystrokes.