Exercises in absurdity, or ... M-Audio Code controller

For your Saturday morning (or evening) entertainment…

I just bought an M-Audio Code black controller as my MIDI master keyboard, thinking with all these assignable buttons, sliders and encoders this will be way cool for controlling the Pyramid remotely. Overall the device feels sturdy, has tonne of assignable controls and has a nice keyboard touch (for my undeveloped taste and for the price anyway), but I haven’t had much chance to play (in the musical sense) with it yet, I started with setting it up for the Pyramid.

Configuring the thing on the controller itself is arcane to say the least - with all those buttons you think you could’ve afforded an “ok” or “enter” button in there, but instead, you use third-lowest C (I’ll call it C3) on the keyboard for that, and various other things. Including numeric entry, D2 being 0, D#2 1 and so on. The fingers will learn that in time of course, but one would think the pad area with pads that are, you know, numbered, would make for a more natural numeric keyboard. No?

Anyway, due to my setup, getting the transport keys to control Pyramid was the really the first thing I wanted to do. Which is where the absurdity starts.
I skimmed through the manual before buying (of course) and saw all the note, CC, PC/LSB/MSB mapping methods and that it’ll do Mackie control and MMC even. So I thought surely this will do everything I need it to do.

The first of many surprises is that out of the box, the transport controls didn’t seem to do anything at all, nothing on the MIDI wire. The second is that the transport controls are not assignable. So they’re not assignable and they don’t send anything? Suspecting that maybe Pyramid MIDI monitor isn’t showing something here, hooked up to a PC and lo and behold, it’s registering MIDI note events from the transport. So they do something, but they only send over USB, and this is not configurable. Wut? Turns out this “something” is Mackie control, but it’s also switchable to HID (to send keyboard strokes to a PC, which appear as funky CC messages). But no MMC. The thing can send MMC, but not from the transport control? WUT? Who would ever want to use transport controls for MMC? And no MIDI clock start/cont/stop either?

It also turns out here’s absolutely no way to send an old-fashioned MIDI clock start/continue/stop messages by assigning any of the other buttons either, so there’s no way to directly start/stop the Pyramid, because it doesn’t support MMC (AFAIK) and PyraMIDI only has special provisions for REC. I suppose this is because in MIDI spec, it’s the clock masters job to send both the start/cont/stop and the clock itself, but AIUI many devices will respond to play/stop even if no actual clock is sent, certainly the Pyramid does so.

So okay, getting this to work on any level will require an external MIDI processor, it’ll simply have to wait a bit. (still waiting for my MidiHub with increasing impatience…) But with transport controls only sent on USB, this means that I’d need an USB host in the setup, which I don’t have, and the MidiHub doesn’t either. So just for the purposes of routing those messages from transport into a processor that can transform them into start/stop for Pyramid, I’d need yet another MIDI box in the 100-200€ range, most of which would also make the MidiHub as a processor unnecessary before it even arrives, IF it wasn’t for the fact that it seems to be the only such thing with an editor for Linux desktop or Android. Which is pretty much a showstopper for me. Anyway, the bottom line is, I will have five dead buttons on the controller (which is a non-trivial percentage) unless I spend a non-trivial amount of further money on an USB MIDI host box of some kind, which is a thing I tried to avoid in the first place.

So here I have a controller on whose color-configurable pads you could almost play Tetris on, and a sequencer whose track selection and effect parameters and record state I can remotely control from the controller that alone are worth closer to thousand euros. And somehow there’s just no way to send that one byte over the 3m wire these devices are connected with to get it to start and stop playback. In this age where low-cost mobile phone are routinely used for surfing the web and watching videos over a wireless global network, this is just all so absurd that it makes a grown man cry in hysterical laughter :crazy_face: :joy:

1 Like

How exciting! Using an alternative controller for the Pyramid.
I lurves this!

I use a Prophet 12 as my ‘controller’ - the keys emulate a basic button matrix and I’ve redirected the knobs to ‘do things’. The 2 sliders? The left one increases the Mute Probability % (I consider this ‘complexity’) and the right one sends CC’s that do things based on a set of packed global variables in addition to increasing the Velocity of the played notes on masked channels (I consider this ‘intensity’).

Okay, blah blah blah - sorry, I get excited. heh

In my idiocy and ignorance, I’d like to share what I know about Transport controls: the [Play] isn’t the only part, it needs to be [Play] followed by an F8 MIDI Clock message. I haven’t looked further into this, because I have enough fun playing around with other things, but my impression that it’d be best to incorporate the [FA] (Start) command with an [F8] (MIDI Clock) from a clock source. I have an E-RM MIDI Clock but haven’t incorporated it into my system because I love love love the BPM Effect.

That being said, I use an Impact LX49 in the studio for playing because it’s just easier to divide/conquer when I want to use my Prophet for Sequencer control (and I do some really weird stuff, so I use a lot of keys). I have found it so much easier to have a beater laptop running MTPro in the mix, routing the Impact data thru it and if I need to change a CC number, or boost values, etc, it’s super easy to do it on the laptop.

I do use a BomeBox for ‘live’ setup - if I ever play live again (it’s not looking likely, but I’ve had my fun).

But still: I’ve tried just sending Transport to no avail. It needs an F8 right after it. I haven’t tried to send an FA F8 msg to see if it kicks on the Pyramid internal clock, tho. If that’s all it needs, then golden, but I have a suspicion that scenario flips the Pyramid into Slave mode.

I just:

  • Made sure the Pyramid was receiving Start/Stop, Clock Sync off
  • Sent the message [FA], and then tried [FA F8]
    neither started the Pyramid. :frowning:

@CreepyPants, you had an all-USB setup (to the Pyramid at least) if I’ve understood correctly?

Just tested this, and USB is quite different from DIN on the Pyramid when it comes to sync and start/stop. Buggy I would say:

For data coming from the USB port, CLOCK SYNC and START/STOP settings have no effect. USB CLOCK SYNC must be enabled for it to receive START/STOP from there. When that’s enabled, sending START causes Pyramid to start (apparently) immediately without waiting for the first CLOCK. Also CLOCK TIMEOUT setting has no effect.

For data coming from MIDI IN, things are far more complicated. If START/STOP is disabled then those are not received regardless of CLOCK settings (as expected). If START/STOP is enabled then those are received regardless of CLOCK settings. If CLOCK SYNC is enabled, then it visibly waits (literally hangs) for the first CLOCK message, but starts playing nevertheless if that clock never arrives. The time spent waiting depends on CLOCK TIMEOUT value.

So just enable USB CLOCK SYNC and those “transport” messages should start working.

Edit: Oh and yes, according to the MIDI spec, START is only a “get ready” signal, and playback should only start at the first CLOCK message. I wont try to guess as to how common it is, but some hardware and software will start the playing without ever receiving the CLOCK, and Pyramid is one of them.

Just to fool around with this all: my Fostex D2424LV accepts MMC (through DIN MIDI), and can send MIDI clock and related start/stop messages, so if I have the keyboard talk to the the Fostex then I can control play/stop/record on both the Fostex and the Pyramid, right? (this is actually the desired setup at some stages in my workflow)

Well, nope. The Code controller only ever sends MMC over USB. While some of my other surprises would’ve been avoided by more careful reading of the manual, nothing in the so much as hints towards this.

So in my computer-free setup, to have the fancy new controller with its transport controls to control anything transport-related, I’d need to have a computer just to route the USB midi back into DIN which besides all other hysteria, creates the additional problem of having to merge two signals from one source :crazy_face:

Clearly this keyboard is first and foremost designed to be used together with a software DAW, but this is ridiculous. :roll_eyes:

Would something like this help?

Hobbytronics (UK I think) used to have something similar.

I think Kenton has a similar device also.

If my brain actually functioned, i dreamed of a multiport USB to DIN MIDI device.

…or, Bomebox. :wink:

Thanks for the Clock info.
I actually have a hybrid system because i use a bunch of 90s rackmount romplers. I have a 4 port USB to DIN interface plugged into my BomeBox.

I dismissed external transport after only testing via USB. Thanks for your update/knowledge! I can reconfigure a bit. Nice!

Sure, variety of USB host to MIDI boxes exist and could be used to sort this out, but they’re not exactly free and have their own issues in turn. I picked a controller with DIN MIDI precisely to avoid the need for those, otherwise I would’ve probably gotten M-Audio Oxygen instead.

I’m really just venting at absurdity of this. If a piece of hardware has a MIDI out port, you’d expect the device to be capable of sending all its MIDI output through that port, no? Well, apparently no.

1 Like

I fully agree.
But i am very old and very cranky.
Dont follow this path.
It is miserable. :smiley:

Oh, and the “cranky” bit includes: never buy anything from M-Audio because: cranky baggage. LOL

Point taken :joy:

On being old and grumpy, I’m well past the point of return on that account :smile:

1 Like

From reading your posts, it seems the dementia hasnt started setting in, though.

That’s the sriracha that makes the whole thing exciting for you, but everyone else has to smell garlic breath. LOLOLOLOL

In seriousness: Nektar gear seems to be focused on DAW control, also. I think their Panorama line has DIN MIDI. Im happier with my Nektar Impact (USB MIDI) than i was with a previous Axiom model i had, although i dont exactly remember why.

Oh, and Crankmaste! :smiley:

This just keeps getting weirder and weirder.

You can assign the encoders to send any CC of choice, such as Bank change MSB/LSB. But not Program Change.

You can send PC for sure, but through buttons and pads only, in increment/decrement by one. Or you can enter the PC number directly. But not with encoders or faders.

Ookay :crazy_face:

1 Like

I was going to go “annoying nerd” on you, but that’s unproductive. Sorry.

I totes feel your pain.

I dream of a series of controllers that have something like a BomeBox built in and you can make any button do anything you want, including triggering some logic functions and subsequent complex output.

I have a button.
I should not be limited to what info it can send, excepting the amount of data. One button = one MIDI message.

Oh well, I’ll be able to work around this with the MidiHub by transforming a CC to PC. When it arrives… this is going to be long month waiting. Not sure if that’s nerdy enough :smiley: Note that I’ve no idea if it actually makes sense to use up an encoder for this purpose, it was just one of “more obvious things” to try using them for. Or so I thought :joy:

It’s the arbitrariness of this all that annoys me most. If the thing couldn’t do X at all then fine, but when it can do it in three different ways that I see no use for but not the one way I would imagine using it, argh. :man_facepalming:

BTW, the BomeBox is something I’d really want to want, but the Windows-only editor is a deal-breaker for me :cry: It hurts doubly because the device itself runs Linux AIUI.

1 Like

I freakin love my BomeBox. I picked up one of the first limited run ones and havent looked back.

I didnt realise MTPro was Windows only.
Wait. It’s not.
The BomeBox just runs MTPro scripts and MTPro is avail for Mac. There’s even a bunch of Mac only stuff it does, which i never paid attention to because I dont Mac.

Then you just upload the script to the Box via web browser.


I actually use a laptop to replicate the Box when Im making changes to my script. When it’s done, i upload, switch a couple connections, and done.

1 Like

Oh, sorry. “Windows-only” should’ve read “not available on Linux”.


Oh, adding: editing MTPro scripts is not like a gui point/click thing. You dont need to have a light pgmg or scripting background, but it helps, esp if you want to do complex logic or ridiculous stuff like me where i create bit masks for 16 tracks that get modified with different inputs then calculate what that means to sending PyraMIDI Mute/Unmutes, CC msgs to affect MIDI Fx, calc changes that affect lighting scenes and send those out on ethernet to a MIDI to DMX translator, etc.

I have a slider that i can use masks that are called per song or project (my choice) that when i increase the value in the slider, it increases velocity of some notes coming out the Pyramid.

But again: a bit of code.
I have a strong suspicion you can handle that way more than i, but regardless: support is amazing.

Ah yes. Not Linux. Yeah.

And yeah, i was going to write them and beg for a Linux version awhile back, or something that might run on an rPi so i could build a box to on the fly change MIDI routings from a generic controller.

1 Like

Dug out some more on Bome - this is actually yet another case of being oh so ever close, but no cigar: The MTPro project files are just plain old .ini style ASCII files that you could edit wherever with whatever (if you knew what to put it there). The catch is that MTPro signs the config file it creates and without that signature the box wont accept it, even if it was syntactically correct. Argh.

I’ve been also eyeballing the iConnectivity things ever since discovering there’s an unofficial open source editor in the making. The nice thing about those is that the entire SysEx based configuration interface is publically documented, the downside is that the programmability seems very limited. Guess it’s more of a router than a processor (but this is just based on looking at docs, no practical experience)

I’m getting close to the breaking point of ordering a bunch of toys for Arduino and see what (if anything) happens. Should make for a fun project even if nothing comes out of it :smile:

1 Like