PIC-based sysex message controller

[Mark Hammer]

How feasible and hard would it be to make a dedicated sysex message controller for a specific piece of MIDI-controlled equipment?  I'd like to be able to play with the "hidden" parameters/functions of a piece of Lexicon equipment (MX100) using a handful of momentary footswitches.  I suppose I'd settle for some of them rather than insisting on access to all of them.  The intent is not to store a bunch of presets.  Rather, I'd like to be able to treat the unit as if it had more tweakable knobs on it.  RG was kind enough to send me a fistful of 16F628 PICs and a programming board, and I'm finally starting to read about the 628, so that would likely be the base for anything I made.

So, is this harder, or easier than I think?  If it is far simpler to purchase a commercially-available MIDI-foot-control unit, please point me in the right direction.

[iaresee]

It depends.

Really on how complicated the sysex is for the unit. I've been dissecting a bit of the sysex for the Axe-Fx trying to figure out if I can attach a control surface with lots of knobs to it and control all the parameters in it (only some of the effect block parameters can be assigned to controllers, but they have software that can access all of the parameters via sysex) and what I'm finding is the sysex header, message block and footer are complicated enough to make this impossible to do with cheap, off-the-shelf stuff like the M-Audio Control thingy. Even my Axiom can't send sysex that complicated. I'd either have to invest is something >$200 I'm willing to spend or DIY....

... and doing this with a PIC and my own surface is a possibility but I'm in going to need a lot of memory for holding the sysex information. Lots of parameters in that box.

MIDI from a PIC is thankfully a well known problem so there's lots of stuff out there on how to do it (check this out for a good, quick rundown: http://www.audiomulch.com/midipic/). The devil is in the sysex details...I think.

[Mark Hammer]

Yeah, stumbled onto that page the other day.  Good resource.

The Sysex implementation for the unit in question is found here: http://www.lexiconpro.com/Product_Downloads/mpx%20100/MPX_MIDI_Sysex_Inst_Rev1.pdf  Looks like it's a looooong message to be sent to the unit.

Alternatively, I guess I could aim for something simpler, like a mere program change, with maybe a couple of presets out of the 16x16 menu: http://www.lexiconpro.com/Product_Downloads/mpx%20100/MPX_100_Program_Change.pdf

[MoltenVoltage]

Are you sure you mean 12F628, not 12F629?  Either way, I would recommend starting with the 12F675 which has an ADC input so you can connect a pot to it.

PIC programming is very rewarding once you get your head around it.  It took me about 3 months of frustration, but then one day the clouds parted and I saw the light!  (just so happens it was a blinking LED)   

[Mark Hammer]

Nope, they're 628s.  Doesn't mean I have intentions of restricting myself to that forever.  It was just I was gievn a bunch for free, and Everyday Practical Electronics came out with a special PIC issue essentially dedicated to the 628 with a bunch of projects and CD of code, etc.  I figured it would be a soft way to learn.

[MoltenVoltage]

I wish I would have had more practical examples when I started, that sounds like a good way to go.

Its really the configuration stuff that stumped me for a long time.

Once you get past that, its just a lot of switching.  There are only like 30 assembly instructions total.  Then you have to figure out things like how to multiply using assembly (e.g. for 3x3 you need to make a loop and add 3 three times).  Division is even more fun.  And that's using 8 bit numbers.  Once you want to use numbers greater than 255, your problems get exponentially harder.

Another major challenge is that the code is not easy to transfer from one chip to another, as they have different register names for the ports, different pin layouts, and any number of other things that make it difficult.  I have also found multiple errors in the datasheets which MCHP has confirmed (but not always fixed!).  Also, they will often use one datasheet for multiple chips so you need to read VERY carefully.

Be sure to have the datasheet within reach at all times, and don't let the circular references get you down!  There are just a lot of things you need to figure out by trial and error and error and error.

Good luck!

[Mark Hammer]

Thanks for that.  It's encouraging!

[iaresee]

If you've got the sysex list (I don't for the Fractal unit, they don't share it -- I have reverse engineer it) then I'd spend your early PIC days learning how to program interrupt polling and whatever analog-to-digital control stuff is on the 628. That's your major battle. Once you can poll an interrupt, sample an analog value that's been converted to a digital representation you can look up the sysex message for that control at that value in your own lookup table and fire off the MIDI message.

Have you considered using something like an embedded linux system instead? It's not as cheap as a PIC, but we're talking maybe $30 tops for a dev kit. The advantage is you get to write C or C++ or maybe in Java instead of PIC assembly. Check out: http://www.uclinux.org/ -- that, running on a ColdFire chip, would be more $, but way easier to program IMO.

[MoltenVoltage]

I just looked at the datasheet and the problem is the 16F628 doesn't have an ADC which is what you will want if you want to connect a pot.  Again, look at the 12F629 if you want to go with PIC.

You might also want to look into arduino.  I haven't used them, but I know there is a huge library of code examples.  I have heard they don't use interrupts, but there are lots of ways to work around limitation (assuming it's true).

[iaresee]

I just looked at the datasheet and the problem is the 16F628 doesn't have an ADC which is what you will want if you want to connect a pot.  Again, look at the 12F629 if you want to go with PIC.

That's not impossible to work around. You can use a rotary encoder instead of a potentiometer. See: http://hobby_elec.piclist.com/e_ckt10_3.htm

You might also want to look into arduino.  I haven't used them, but I know there is a huge library of code examples.  I have heard they don't use interrupts, but there are lots of ways to work around limitation (assuming it's true).

Good call. I'd go Arduino over PIC myself -- the language is easier write in and the hobby community around it is much more modern. Not as cheap though.

Mark, I'm going to give some embedded Linux solutions a read over tomorrow. I think I'll try that approach myself since C and the general Linux dev environment is so well known to me. I'll report back on what I find.

[MoltenVoltage]

That's not impossible to work around. You can use a rotary encoder instead of a potentiometer. See: http://hobby_elec.piclist.com/e_ckt10_3.htm

Good point.

I kind of have blinders on when it comes to turning knobs and being able to see what position they are in at any time, but I think its just a case of old habits dying hard.

[Mark Hammer]

I was thinking real foot control, as in no bending over.   So, the absence ofA/D hasn't, as yet, perturbed me.  Simple parameter select and up/down seems like enough for now.....for now.

[David]

Mark:

I did some work several years ago on a device to send SysEx messages that would have used a 16F628 or a 16F877.  This stuff is something I understand.   I would be glad to lend detailed assistance.  PM if interested.

[iaresee]

Mark:

I did some work several years ago on a device to send SysEx messages that would have used a 16F628 or a 16F877.  This stuff is something I understand.   I would be glad to lend detailed assistance.  PM if interested.

Couldn't you just share the knowledge here -- so we can all learn from it?

[MoltenVoltage]

This is a great resource to get you started:

http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html

[David]

That would be easier if more was known about the specifications of the desired control surface device.  I can make some observations based on the discussions regarding controller selection.

1) The 16F628 is the desired target of the moment because that is what is available.  It would easily be possible to substitute a 16F648A later to double the code space available.  If a real beast is required, the 16F877 should be more than adequate for the job.

2)  It is not mandatory to use an ADC to read a pot, just more accurate.  Myke Predko's book contains a project on this, and the code.

3)  If the control surface does not need to receive data from the controlled device, only one type of SysEx is required.  A subroutine or subroutines can be written to send the parts of the message that never change.  These parts would not need to be stored.

4)  What dictates that the SysEx info has to be saved in the PIC's on board memory or some kind of EEPROM?  Nothing.  Write the program source so that include files are used to do the message formatting and sending.  Create include files to handle generation of each message.  Keep these include files with the main program source.  Specify include directives in the main source to bring in only the desired message processing.  You can change what messages get sent, and what they send, and simplify the main program all at the same time.

[iaresee]

Moved to here. Sorry for the hi-jack Mark.

[scratch]

Mark, if you have no C background, you might consider the PicBasic Compiler ...

http://www.melabs.com/products/pbc.htm

You might also want to check out MidiTools See under applications ...

http://miditool.com/index.html

[David]

Probably true.  However, developing in PIC assembler has HUGE advantages:
1)  The Microchip IDE is FREE
2)  There are several massive code bases already in existence:  The piclist, Nigel Goodwin's WinPicProg site, and code created by Ross Bencina, Josh Harle, Scott Dattalo, Marc Bareille and others.
3)  There is a ready to build, though dated, MIDI controller project at Thorsten Klose's site.  It's called the Floorboard.

[Mark Hammer]

Great resources!!  Thanks.