MILAN - Musical Instrument Local Area Network

[Peter Snowberg]

Using standard Ethernet cables is one way to go, except that these days all the patch cords you're going to find will be Cat 5, 5e, or 6 and the parasitic capacitance may play hell with things. Today's fast Ethernet uses all kinds of fancy adaptive equalization and deals in uni-directional point to point interfaces which necessitate the use of Cat 5 or "better". What we really want is the Cat 3 of yesteryear which has a lower parasitic capacitance. It's getting a little harder to find Cat 3 these days.

Ethernet would allow for easy replacement of a damaged cable and they are ubiquitous but they do have some disadvantages beyond the cable spec. They are much more fragile than many connectors we're used to using in the Rock&Roll environment, with XLRs being a prime example. Off-the-shelf Ethernet cables are also made with wire which is designed to let the insulation "squish" out of the way when pressure is put on it. This "insulation displacement" feature of the wire may not be much of a feature in stage environments. One smash and your Ethernet cable could be toast whereas more robust cable will handle the abuse time and time again. Modular connectors really speak to having point-to-point links thanks to the wire terminations. If you want a bus topology with stubs, now you need (ideally) additional connectors at every point a stub joins the bus. If you provide a single jack on a piece of equipment, it's much better to provide two.

Still, Ethernet cables are an option with the trade-off of reduced overall distance on the net. I suggest for such implementations that pins 3 and 6 of an 8P8C (standard 10base-T connector) are used. An alternate would be the use of pins 2 & 5 on a 6P4C (regular modular telephone connector), the same way that Farallon did PhoneNET.


When it comes down to it, in stage use an XLR would really be the way to go because of ruggedness and commonality. Scratch anything I've said about rugged modular connectors. XLR is it for rugged point to point links. In a pinch you could use a mic cable. Ideally you want an unshielded category 3 twisted pair but it's astounding what the RS485 world will put up and still give solid, reliable communication.

OK, so now I'm seeing XLR or 1/4" TRS for stage use where connections are exposed, and 1/4 or 3.5mm TRS for most effects devices. As much as I like modular connectors for some things, I just don't think they have much of a place in stage use unless you're talking about digital snakes.


<soapbox>

The plugs and jacks used in Ethernet are not RJ45.  I apologize for my incorrect usage.

RJ45 refers to to a way that 8P8C modular connectors were wired for a single line phone in the late 1960s. Today we use it interchangeably with the 8P8C designation, but it's not correct.

</soapbox>

[idlefaction]

First up, 'scuse my long post!!!

WIRELESS

I think wireless would be an excellent way for devices to communicate via MILAN.

I remember seeing an Atmel press release about having AVR's with built-in Zig-Bee transceivers, and Zig-Bee is a technology specifically designed for this type of application (low power, short range, low traffic) - a quick scan shows no sign yet on the Atmel website though, unless I missed it.

BIT DEPTH

If you're going to allow 16 bit values to be sent via MILAN, but your pedal internally has a 10-bit range because you're using the 10-bit ADC's built into your AVR to convert the CVs from knobs and switches, you'll need to think about what to do with out-of-range values. 

This'd be a per-pedal issue tho rather than something MILAN would have to deal with.  But it could be handy to specify how pedals should deal with this?  Maybe each pedal should receive the full range of 16 bit values and scale to whatever they use internally.  So a on-off switch would use the MSB, a 10-bit CV would use the 10 MSBs, a 4-position rotary switch would use the 2 MSBs, a 3- or 7- etc position rotary would divide the range by 3 or 7, etc etc...

(It's easier to do greater-than comparisons than trying to divide numbers in assembly, by the way!)

METHODS OF USE

The things I'd use MILAN for would be:

*  Recalling a preset (sets bypass and knob state for all my MILAN gadgets)
*  Sending a Tap Tempo signal for devices to sync to
*  Sending a CV from one pedal to another - eg. an envelope detector pedal that may have an inbuilt filter, but the envelope can be used for other pedals as well, envelope-controlled flanger speed etc.

RECALLING A PRESET

There are two ways i can see this working, either you store your presets inside each device, or you store all the settings for each device externally.

If you store presets in each device, all your controller needs to do is send out a patch change message, and the pedal itself needs a way to know to 'store' its current setup into a specific patch.  A 'store' pushbutton would do (possibly holding down the bypass footswitch), or accepting a 'store' message from the device sending the patch change messages, allowing you to 'store' all your MILAN devices simultaneously.

If you store all the preset info in an external device, you need to be able to ensure that the system can tell your two identical delay pedals apart, and send the correct settings to the correct pedal - otherwise you could end up with your settings appearing on different pedals each time you power up your pedalboard.  So something equivalent to MAC addresses on ethernet cards may be needed...  :-/  (Zig-Bee chips have this!  *grin*) 

One disadvantage here is that if you have a large number of devices with a large number of controls on each, you have to wait for the patch changer to send out a message for each control of each device serially, which could take a noticeable amount of time compared to just a single 'patch change' message.

TIME SYNC

MIDI used a clock message that is sent at regular intervals - i'm not 100% sure but I think the MIDI clock message also has song position info in it, like bar and beat.  IIRC there are 6 clocks per eigth note and the clock speed is not contained in the clock messages, you determine clock sync implicitly by the time between clock messages.  Not very accurate, but great for getting your drum machine and synth arpeggiator with beat 1 in the same place.

You could copy this idea, or send a message with the time explicitly in it.  An idea in this case could be to have a standard for controls that affect timing, so that setting your delay time and phaser speed controls to 0x4E03 will always result in them having a period of a particular time.  This is problematic though;  it could result in out-of-range times for some effects.

Perhaps each pedal has a range of times it can produce, and out-of-range times are scaled by the effect by a factor of 2 until they are in range...?  Lets you still be in sync even if you get an illegal value...

I'm unsure which of these two options is best.

CV SHARING

I really like the idea of being able to share envelopes and LFOs between effects!  It would result in a lot of traffic on the bus, though.  I'm not sure if its feasible to have messages sent at 20kHz sampling rate for example?  :-(

BAND MILAN...

No reason why you can't send a MILAN cable on over to your bass players' rig so his chorus can sync to your phaser...   =D

WHY NOT USE MIDI?

Realistically, MIDI might be slow and old, but it's also ubiquitous.  Many guitarists who care about things like syncing clocks and patch changing already have MIDI gear.  And they will be using their MIDI floorboard with inbuilt tap tempo MIDI clock generator.  Many of us home DIY'ers would love to be able to sync our delay to our drum machine.  The list of times when MIDI would be handy goes on.

Here's some points for and against:

Patch change messages via MIDI.  Without a discovery protocol, patch storage would have to be done inside each effect.
Sync messages via MIDI. Not addressed, so all gadgets would sync, which isn't ideal. (Assuming each device doesn't have a method for controlling whether it syncs or not.)
Parameter control messages via MIDI - controllers are limited to 7-bit values, but Sysex and NRPN's raise this to 14 if you use two messages.  7-bit is low enough to hear zipper noise when changing knobs quickly. MILAN uses 16 bits.
CV sharing - possible but would clog up the MIDI bus. MILAN is much faster, but is it fast enough?
Addressing via MIDI is only by MIDI channel for patch changes, or by using Sysex messages.

I think the gist is that MILAN is cool and a necessary upgrade, but many setups will be a mixed-technology situation with both clock and patch change info originating from MIDI equipment.  So keeping MILAN similar enough to MIDI that patch change and sync info at least can be shared, is important.

*whew*!

I'm keen to help develop this idea if I can!  How can I help?

[R.G.]

Using standard Ethernet cables is one way to go, except that these days all the patch cords you're going to find will be Cat 5, 5e, or 6 and the parasitic capacitance may play hell with things.

There's a whole branch of engineering that I've never seen noted as a formal discipline, but that every engineer worth his salt does. I call it "design with available components."

This is simply a recognition that whatever is easiest to get is likely to be cheapest, and in the long run most reliably available. It is worth some consideration in any design to at least take a look at what is available easily and everywhere and include that if the adaptations for using it are not too severe.

In the case of Cat 5, etc. my opinion (note - that's not a fact) is that the pan-availability makes the patch cords qualify, even if some buffering is needed to use them to overcome the capacitance, and even if you back the frequency down a bit to use them.

But that's just my take on it.

[Peter Snowberg]

Long posts are good. 

Wireless:

Wireless has some exciting things going for it but I'm still nervous about the idea of the ice machine and the portable phone causing interference at a gig. Bluetooth is also getting quite accessible and cheap these days.

I never intended MILAN to be a fully routable protocol because of timing issues, but it is intended to be bridgeable to MIDI or other serial link and there is no reason why that can't be extended to ZigBee, Bluetooth, IR, or other physical interfaces. In these instances the AVR on MILAN is acting as a protocol converter. I can see timing issues for note-on-note-off data like MIDI uses, but since we're talking control here it should be a much easier situation.


Bit Depths:

For control values being read by a 10 bit ADC, simply shift the word up by 6 bits so that the 10 most significant bits contain the real data and the lower 6 contain zeros for padding. Likewise, on the receiver end the least significant 6 bits would just be discarded if using a 10 bit DAC. This scheme allows and number of control bits to dovetail with any number of bits being controlled. This way you can't get values that are out of range.

Maybe each pedal should receive the full range of 16 bit values and scale to whatever they use internally.  So a on-off switch would use the MSB, a 10-bit CV would use the 10 MSBs, a 4-position rotary switch would use the 2 MSBs, a 3- or 7- etc position rotary would divide the range by 3 or 7, etc etc...

Exactly!

I have to think a little more about other types of control values so that a lot of bits on the line are not constantly wasted.


Presets:

Since each piece of gear is going to be different, the concept of presets needs a little modularity. If each piece of gear can manage all of its own info and just be told, "hey, switch to global preset 12", it's much easier than trying to get everything to understand everything else. You could also have a master device interrogate each slave node, asking it for a list of the settable parameters and then the settings of each of those parameters for remote storage. Changing programs with lots of gear then becomes much more complex. It's still something we should have available even if the preferred method is to use the same "program change" method that MIDI does.

Rather than using a MAC address which has to be totally unique in the world, I'm going for a similar method to what Apple used. Each node is described by three values as English names. The first is the Node_Name which is a string of up to 16 characters which is unique on the network. This name may be changed at will and is the primary human addressing mechanism. The other two strings hold a device name (set by the builder)and a serial number (also set by the builder). The combo of those will make a unique ID, but for the most part the Node_Name is what gets used.

At power-up, each MILAN will try to occupy a one byte Node_Address. Each device looks for other nodes trying to occupy that same address and if a conflict is found, they will pick another address. A name binding is used for access of one device by another in a similar way to how domain names get translated to IPs. Once an English name has been equated with a Node_Address, all subsequent communication will happen between the one byte addresses.


Time Sync:

A broadcast message can hit everything at once without any MIDI-slur. I don't see MILAN being used as much for clocking but there isn't any reason why not. I'm a bit more of a fan of having each clock sensitive device control a local oscillator which is then synced via the clock. That way there is no need to standardize on how clocking is dealt with in terms of time period.


CV Sharing:

That one is a little harder and would result in more traffic, but traffic only needs to be sent during value changes which reduces demands a little. With LFOs that are local to each device the sync signal takes care of that without lots of traffic.

The update rate is something to keep in mind and this is where MILAN will show its limitations, but at least they're much less restrictive than what MIDI allows. If we can dream up ways of making most of the fast stuff happen locally I think we're in good shape.


Band MILAN:

Yes!

Being able to sync the effects of multiple players is some powerful stuff!


On MIDI:

I agree with all your points.

The similarities between the two allow for easy MILAN/MIDI converters.

I'm keen to help develop this idea if I can!  How can I help?

Keep doing exactly what you're doing..... and keep dreaming too!

[mistercooper]

This is a wonderful idea.  I have some development ponderings of my own to share.

I'm not sure how familiar you guys are with the modular synthesizer world, but this would be a dream in that department as well.  A lack of preset patches/memory has been the number one complaint/loveable quirk that sets asides modulars.  If the AVR could somehow be housed in its own module and communicate with another 40 or so, who knows what might be possible.

Makes me wonder further about what this new deal is that moog will be releasing soon.  The only clue theyve released is a picture of a pot surrounded by LEDs...

[David]

Ummm...  I'm not an engineer, just a humble programmer/analyst.  Here's another take on this.  Were I doing the designing, I would keep the control system digital and the effects analog to the extent possible.  We should be able to treat this system as if we could plug in pedals we had just purchased from the Effects Rip-off Emporium down the street.

I'm tired.  If this doesn't make sense, tell me and I'll try to clean it up tomorrow.  My idea's valid, but the way I expressed it might not be.

[idlefaction]

I would keep the control system digital and the effects analog to the extent possible.

Yes, definitely!!  Remember that control voltages can also be digitally generated via the wonder of DACs - try it, you might like it.  Some very well-regarded high-end compressors and limiters used in some very expensive studios use control signals generated digitally.

I highly recommend watching the Moog documentary, not only will you learn how to pronounce Moog, the guy was absolutely fascinating in his approach to electronics.  Contained enough geeky electronics talk to keep me happy, and also kept my wife enthralled (she *loves* anything with Moog written on it now!!!)  I got the impression Bob was a firm believer in the all-analog path also, as he had a kind of 'feel' for what was happening in analog circuits.  My hat is off.  The doco shows you through the insides of a Moog synth, the Voyager I think, with it's analog circuitry controlled by a digital patch memory that adjusted CVs.  I wouldn't be surprised if even Bob Moog's CV generation system was digital, so all your knob movements go through an ADC->DAC step!  (I can't figure out a way to do it without going digital...)

[Peter Snowberg]

I would keep the control system digital and the effects analog to the extent possible.

I agree too! 

I highly recommend watching the Moog documentary,  ..... The doco shows you through the insides of a Moog synth, the Voyager I think, with it's analog circuitry controlled by a digital patch memory that adjusted CVs.  I wouldn't be surprised if even Bob Moog's CV generation system was digital, so all your knob movements go through an ADC->DAC step!  (I can't figure out a way to do it without going digital...)

Do you have a link by chance? 

I could see using digitally controlled MUXes to switch between a pot and DAC with an ADC added to read the pots. I'll bet that the resolution of the digital stuff is 8 bits and that's on the threshold of zipper noise for live control. Also, you don't need a fast ADC that way either.

[idlefaction]

Do you have a link by chance? 

http://www.imdb.com/title/tt0378378/     <<< enjoy!

[genie]

Excellent idea!!

The signaling rate is 230,400 bits per second;

I suggest to use 200 or 250 kbps instead for general crystal availability. Please consider about compatibility with another real-time controller bus system like as CAN (Controller Area Network) which runs at 100, 125, 200, 250, 500K or 1M bps. Actually, AVR AT90CAN128 is equipped with full CAN facility and run in combination with popular 12 or 16MHz crystal, but unfortunately it's not suit for MILAN 230.4Kbps. I think that penalty of changing MILAN speed -13 or +8.5 percent should be small...

The other requirement is that the master oscillator must provide an accurate bit clock. For AVRs, this will require an oscillator of 1.8432, 3.6864, 7.2738, 9.216, 11.0592, 12.9024, 14.7456, 16.5888, or 18.432MHz.

Btw, 12.9024 and 16.5888 MHz crystals are not listed at Digi-Key. 7.2738 7.3728 MHz.

[Peter Snowberg]

Thank you for the suggestion Genie.

One important thing for my network is to be compatible with other equipment. One of the most important categories of equipment to be compatible with is the common PC. I chose the oscillator so that the same chip would be able to host a MILAN port and a standard serial port with standard serial data rates. One problem with MIDI hardware was the reliance on a 2MHz crystal, chosen because it was inexpensive at the time. The non-standard baud rate made interfacing more difficult because most baud rate generators won't create bit clocks compatible with both MIDI and standard async serial rates. Part of the requirement for this new technology is that it be compatible with a wide variety of processors while allowing those MPUs to also host standard serial ports.

I don't see availability of crystals as an issue. The six frequencies below are very standard.  A scan of DigiKey shows the following availability: (numbers include all packaging and purchasing options)

1.8432 - 7 choices
3.6864 - 63 choices
7.3728 - 62 choices
11.0592 - 86 choices
14.7456 - 71 choices
18.432 - 113 choices

This does not include oscillator modules which are also available for these frequencies. The 12.9024 and 16.5888MHZ speeds are harder to find from some sources, but they are standard frequencies. I listed them because they provide standard serial data rates with 0% error and they may be available in some systems (and Atmel uses them as examples too).

The 18.432MHz and 9.216MHz speeds also allow the same oscillator to be used to generate a 48KHz sample clock for DSP systems. This is important to reduce heterodyning between multiple clocks.

CAN has may uses and for messages such as "the left turn indicator is now on", it is a great standard. Unfortunately CAN has many things that are not in its favor for audio control applications. CAN only provides a basic transport capability and still requires all higher level protocols to be coded. CAN does not support any kind of plug and play capability, the 8 byte hard limit on data packet size is a big problem, and the synchronous nature make CAN hardware a requirement. Using the AVR USART hardware is restricting too, but one can build a bit-banging serial routine to emulate the USART much easier than you can build a CAN transceiver in software. The USART is also present across most of the AVR product line from tiny and inexpensive chips to large chips with lots of memory and other resources. The AVR serial port can handle a data rate of 2.304Mbps where as CAN only extends to 1MHz and the bit times saved by CAN's synchronous protocol are lost in the requirements to achieve synchronization. I've worked with many embedded networks and I feel that CAN is not the most appropriate technology for the task so I'm inventing one. 

Thanks for your interest.

[aron]

Holy cow! Amazing.

I don't really have much to add, except this sounds cool and I believe that onstage I would trust an XLR more than CAT 5 anyday BUT I believe in order to make this work, it would have to be low cost and use easily obtainable parts AND the connector should be fairly small. After thiking about it, I haven't actually measured XLR vs. MIDI. Would one cable be able to handle bi-directional communication - for both sending and receiving? That could be a big plus over MIDI.

If this thing really starts moving - the interesting thing is that:

My old company I worked for was one of the first to:

Create a MIDI interface for the Macintosh
Create a MIDI Sequencer for the Macintosh
One of the first to succesfully integrate MIDI and Audio in a Sequencer
One of the pioneers of the MIDI File Format

I used to write front-end editors for almost every major synthesizer and a number of effects units. So OF COURSE I like this sort of thing! 

I also _used_ to talk to and have contact with most of the R&D depts in major music manufacturers.

Note that I USED to do this... I haven't in a long time but some of the connections might still be available.

[Peter Snowberg]

It's pretty hard to beat 1/4" stereo plugs for commonality and small panel space requirements. If you need locking, XLR is the only real choice I've seen in widespeard stage use unless you want to think about CPCs. 

For cable, Belden 9271 (124 ohm nominal impedance) or any low capacitance twinaxial cable will do.

http://www.newark.com/product-details/text/catalog/6221.html

Aron, this topology is very similar to LocalTalk so yes the communication is bi-directional over a single pair. No "break in the loop" worries.    You do have to use termination at the ends, but a pair of N.C. switching stereo jacks make for an easy auto-termination scheme and easy daisychaining just by plugging in a cable.

I can't wait to see what folks around here are able to do with this stuff. The near-term object will be to put together a simple experimenter board with analog inputs and digital I/O that can interface to ePots, DACs, switches, LEDs, and will also provide serial bridging. Parts list:

(1) Atmel AVR
(1) LTC1485 transceiver
(1) 7.3728MHz crystal
(2) 22pF caps
(2) 0.1uF caps
(1) 10uF cap

Pretty short list. 

[LyleCaldwell]

I've used the Ethercon stuff for control signals (exp pedals, momentary switches, etc), and it's easily comparable to DIN/XLR in rugggedness.  Plus the Neutrik Ethercon plugs quickly and easily snap on to stock Ethernet cables, so you can replace cables cheaply and easily, retaining the Ethercon plugs.

I'm intrigued by this thread, but don't have a ton to contribute. Though I'll have to ponder names for it now.

[hairyandy]

There are ruggedized RJs. Gibson is using the EtherCon series from Neutrik to do their RJ-45s for MaGIC. In fact, you can pick them up at Mouser.

The "ruggedized" RJs are also what Line6 is using for the Variax.  The guy that I tech for is using a Variax with the PodXT Live board which I've integrated into his Bradshaw rig.  It's great for those couple songs where he needs to be playing a 12-string acoustic in the chorus and a banjo in the verse.  I found the connectors and also some EtherCon couplers at Pac Radio in L.A. when we were doing rehearsals there and I just made all of my own cables to the length that I needed for his rig.  The added bonus of ethernet is that length/capacitance doesn't come into play, at least so far in my experience.  They've been using these connectors in video for a long time...