Posted by: dhj in Music Technology on Nov 27, 2011
Aptril 26th, 2012
A new website has been created that focuses specifically on using Max with the Eigenharp. Please visit http://max4eigenharp.com for more details as well as for the Max patchers to support the Eigenharp.
Posted by: dhj in Music Technology on Sep 24, 2011
Tagged in: Untagged
The earlier articles are
Part 1
Part 2
Posted by: dhj in Music Technology on Jul 26, 2011
Tagged in: Untagged
In part 1 of this article, I introduced some of the basic Max patchers I created such as generic MIDI input and output devices and then instrument-specific versions. After a few days of testing, I ran into some bizarre behavior where Scorecerer would not change pages via MIDI remote control, but only for some songs.
I finally tracked the problem down and it turned out that there was a 'double-bug', one in Scorecerer and one in my Max implementation. These conspired to cause the problem. What was happening was that when I pressed the button on my MPK61 to go to the next page in Scorecerer, Scorecerer didn't respond at all but the (highly recommended) MIDI Monitor app I was running reported that two copies of the CC event were being sent to Scorecerer. I'll get back to the reason two copies were being sent in a moment as that caused me to change the original design of the MIDI device patches.
The reason Scorecerer didn't respond at all (as opposed to changing the page twice, which is what should have happened) is because I was (stupidly) using the length of the incoming packet to decide whether I was getting a CC event (3 bytes) or a ProgramChange event (2 bytes). However, in this particular case, the packet length was 6 (two CC events) and so was just being ignored. I fixed this by switching on the actual Status byte but I'm glad I found this issue as if it had been reproduced by customers but not by us, it would have been very difficult to track down.
Posted by: dhj in Music Technology on Jul 20, 2011
I have a large live keyboard rig with 7 keyboards (including a wireless MIDI keytar), several pedalboards with MIDI, as well as an Eigenharp and various other control surfaces. I also have several synth modules in a rack that also contains two MOTU 8-port MIDI interfaces and a MOTU 828mkIII/8Pre combo that is fed by an SSL X-Patch so that I have complete control over how audio is routed from place to place.
Historically I have used Apple MainStage to control my rig but even though I considered it to be brilliant in conception, it was never (and sadly still is not) 100% reliable. I have never gotten through a single rehearsal (never mind performance) without several glitches such as plugins randomly stopping as well as occasional stuck notes. Although I stopped using audio plugins and added a Muse Research Receptor to handle such things, even MIDI routing fails to work reliably. The Receptor was also surprisingly flakey as well, and subject to many reboots as well as occasional failure to respond to MIDI.
After considering the available alternatives, including switching to a Windows box as there are a couple of interesting alternatives there, last weekend I decided instead to bite the bullet and just develop my own MIDI routing environment. The main criteria was that it had to implement the MainStage indirection mechanism where you can define devices (keyboards, knobs, pedals and so forth) which respond to incoming MIDI but which can then control other devices that want different MIDI values without having to be focused on knowing the actual MIDI data all the time (a key highlight differentiator that separated MainStage from other systems with similar functionality) and it had to be very easy to add new "patches" representing new songs.