Almost 15 years ago I created a proposal for a communications system that would be able to pass control parameters around an effects environment. To a great degree it was meant as something that could replace the limited and ageing MIDI standard which was never originally intended for prime time.
My proposal was based on the physical layer of Apple's LocalTalk networking system. This is a transformer isolated RS-485 multi-drop network with the ability to connect up to 32 nodes via a single twisted pair of phone cable. This approach eliminates ground loops, allows for runs of up to 4000 feet, and it uses cheap-as-dirt category 3 twisted pair wire which is very easy to work with, requiring no special tools. I used the same IBM invented FM signaling method that Apple did, and set the data rate the same 230,400bps which is over 7 times faster than MIDI. It differed from MIDI in that it was a multi-drop network, rather than the chain of serial point to point links that MIDI is. The change in topology eliminates "MIDI slur" which is deadly to trigger signals and the increase in data rate allowed for the increase in traffic that would be seen on the net topology.
MIDI was built around the use of an inexpensive and obsolete UART being clocked with an inexpensive 2MHz crystal. There is no reason to use the parameters of these two cheap parts as a base for a standard any more. My standard on the other hand required the use of a serial chip that would encode data using SDLC signaling in order to make use of transformer isolation and the only real commercial solution was the expensive Zilog 8530 SCC. These chips are big, power hungry, expensive, and at times they were difficult to get with a lead time of several weeks. I eventually wrote a software emulation of the 8530 features I needed using a Ubicom SX28, but by that time Ethernet was pretty firmly entrenched and I just hoped that equipment would start to have 10baseT ports.
Although it had a number of things going for it, I never did anything with this proposal. Now here we are in 2006, microcontrollers are cheap and readily available, and it's time the DIY crowd finally got the use of an interface that MIDI never will be. :)
I'm bringing back my proposal, but in a little different form. I'm dropping the transformer isolation because of the problems with the complexity of the signaling method, but keeping the RS-485 signaling and the 230.4Kbps data rate. If I can get people to agree on what this thing is and how to use it, we'll be able to produce universal control devices and highly integrated control systems that give us options we never had before. Since we're mostly guitarists here, we won't have as much use for note data as the synth crowd does. We're probably going to be more interested in moving control values around to affect effects. This proposed standard will be free for all to use, for DIY or commercial purposes.
_________________________________________________________
Musical Instrument Local Area Network
_________________________________________________________
What is it?
MILAN is a medium speed network specification intended for the inexpensive networking of devices in the instrument-effect-amplifier environment.
Why are you doing this?
MIDI has quite a number of shortcomings such as the use of 7 bit values, it's slow, it suffers from latency problems, it uses big ugly connectors, it's not flexible enough, etc., etc.
MILAN is intended to be a cheap and easy way to get meaningful control data from a user interface into a variety of control devices at the same time while bypassing most of the major issues with MIDI control.
I would like to see a standard interface for controlling presets on analog gear, signal routing in switchers, parameters in DSP effects, and modular user interfaces. Wouldn't it be great if stepping on a stompswitch in a controller made by one company would be able to trigger configuration changes in 25 pieces of gear made by 25 different companies, all at once? With MILAN, this is possible.
How fast is it?
The signaling rate is 230,400 bits per second; roughly 7.3 times higher than MIDI's clock rate. This equates to a maximuim data transfer speed of roughly 23K bytes per second. Network overhead reduces this figure, but signaling is still several times faster than MIDI.
What is the cable & topology like?
MILAN uses a single Category 3 twisted pair for bidirectional signaling between up to 32 devices on a single piece of cable. A single cable segment may be up to 4000 feet long but in practical use it should be limited to less than 2000 feet. Low load drivers can be used to place up to 127 devices on the same piece of cable.
The connector is not specified in the standard. Small form factor devices may wish to use 2.5mm stereo headphone jacks with the tip and ring connected to the twisted pair. RJ-11 phone jacks are a proven solution with locking capability for smaller devices. Rack mount devices may use RJ-11s along with screw terminals, DINs, XLRs, or any other connector system capable of terminating the connection. Devices should provide two connections in order to facilitate easy daisy chaining.
How expensive is it to put MILAN in my device?
The signaling is based on the built-in USART in certain members of the Atmel AVR microcontroller family. The other components required are an RS-485 transceiver like the LTC485, the jacks for making the connections, and a few discrete passives for bypassing, filtering, and coupling. 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. If you're already using a capable AVR, the additional cost is roughly $2 for a generic implementation.
Can I use other microcontrollers?
All you need is to be able to send and receive serial data at 230,400bps using the special 8N1 format provided by Atmel for Multi-Processor Communications Mode. The polarity of the stop bit is used in this mode to signal whether the byte contains a network address or data. This format was chosen for efficiency and to take advantage of special functionality provided by the Atmel USART.
Where do I go from here?
Short answer: nowhere, but keep this stuff in mind when you design new gadgets. :)
The early versions of this standard were somewhat different and all those notes have been lost for some time. The format of the communications is still being formulated but it will consist of 127 possible node addresses and up to 127 possible broadcast "group" addresses. Dynamic addressing with name look-up will be used to allow for plug-and-play functionality.
=============================================================================
Let's start talking about ways to make our devices work together. At the very least, it would be great if standards for remote configuration can be developed. Every device will be different, but there should be a standard way of saying, "hey everybody, switch to global preset #12".
Here are a couple links on RS-485:
http://en.wikipedia.org/wiki/Rs485
http://www.lammertbies.nl/comm/info/RS-485.html
http://www.rs485.com/rs485spec.html
http://www.national.com/an/AN/AN-979.pdf#page=5
What do YOU want MILAN to accomplish? :icon_biggrin:
.
Horshack here. OH! OH! OH! Holy cats, Peter! How come you never pursued this? You could have been retired by now!
Here's what I'd like to see MILAN accomplish:
1) Have a conversion methodology to at least be able to send MIDI note numbers, "start note" and "all notes off" commands so it can play MIDI synths
2) Perform the selection logic on an Omnidrive so its settings could be treated like "patches" or "loops"
3) Select 1 of N ROG preamps
4) Select "Zombie", "Clone" or Mark Hammer "Badge" mode on a Zombie Chorus
5) Switch between hard and soft clipping on a diode and op-amp distortion
6) Flip a wah into wah, volume or autowah modes. Also engage or disengage input and/or output buffers
7) Assign an expression pedal to one of the effects units in your rig
Last) Use a momentary switch to select a different effects loop and hold that loop as long as the switch is depressed
I want it to make me sound like Hendrix but without the practice and talent.
ok...I got nothin'
Andrew
:icon_cool:
Quote from: The Tone God
I want it to make me sound like Hendrix but without the practice and talent.
Does that mean you don't want to take the time and effort to sound like Hendrix, or do you want to sound like an unpracticed and untalented Hendrix? :icon_razz:
Quote from: DavidHere's what I'd like to see MILAN accomplish:
1) Have a conversion methodology to at least be able to send MIDI note numbers, "start note" and "all notes off" commands so it can play MIDI synths
Easy to make with a single AVR. Some have two hardware serial ports making this really easy.
Quote from: David2) Perform the selection logic on an Omnidrive so its settings could be treated like "patches" or "loops"
As long as you can make a preset interface to the analog circuitry, no problem.
Quote from: David3) Select 1 of N ROG preamps
Piece O' cake.
Quote from: David4) Select "Zombie", "Clone" or Mark Hammer "Badge" mode on a Zombie Chorus
More cake.
Quote from: David5) Switch between hard and soft clipping on a diode and op-amp distortion
Still more cake.
Quote from: David6) Flip a wah into wah, volume or autowah modes. Also engage or disengage input and/or output buffers
Again, more cake.
Quote from: David7) Assign an expression pedal to one of the effects units in your rig
Want some cake?
Quote from: DavidLast) Use a momentary switch to select a different effects loop and hold that loop as long as the switch is depressed
...and finally, cake again. 8)
OK, here's something I'm having some issues and confusion about. I've just gotten my STK500, and I've dinked around with it a little, but I'm feeling a bit lost with this whole programming methodology. I'm used to high-level languages, and sugary features like event handlers.
So, how exactly would you handle something like a held-down button programmatically? Do you just keep sampling the thing to make sure it's held down in some sort of sub-loop, or can you link a digital input up to an interrupt or something? So much of this stuff seems like an event-driven system would make sense, though clearly it works without it.
I need to get some books on uC programming... Recommend any?
Sorry, probably should have started a new thread for this...
In all honestly, I just don't get the point. Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why? Is it somehow advantageous to put all the controls in a central spot? If you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...? I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.
How about synchronizing all of your LFOs? Or having a set of preprogrammed "patches" like in a multi-fx unit? Or having your settings on your pedals be programmable? Or generally being able to program your entire setup and alter multiple parameters in realtime with a single control, across multiple devices? And generally be able to pull off lots of complex studio-esque tricks live, and all by yourself?
Quote from: rockgardenlove on March 10, 2006, 03:36:50 AM
In all honestly, I just don't get the point. Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why? Is it somehow advantageous to put all the controls in a central spot? If you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...? I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.
Think outside the box. If we can design a common interface protocol, we can stick any pedal in any position on a pedalboard and the controller can select pedals, select chains and change stompbox parameters. It would be ASMOP on steroids.
This has absolutely head-spinning possibilities!
It's really cool to envision what can be done once you step in to the digital domain. In fact, that is one of the things that is so seductive about digital - you can, with some assurance, state that whatever you think of can be done. Even previously scifi stuff.
However, there is a massive problem when you actually have to fit the old-school everyday practicalities into the new Digital Millenium(tm) setups. You can't instantly change the history of the world or replace it.
As David says...
QuoteHere's what I'd like to see MILAN accomplish:
1...2...3...4...5...6...7...
and as Andrew notes:
QuotePiece o' cake... cake... cake...
but he also notes:
QuoteAs long as you can make a preset interface to the analog circuitry, no problem.
And that's the bit of ugliness hiding inside.
To get to the anything anytime forever kind of setup that's lurking in these ideas, you have to change the pedals themselves to listen to the digital network. And in a dull, painful, difficult and tedious way, that will likely be the downfall of this kind of setup being done all at once.
It's really not much of a stretch to do any one of the practical things involved - setting a pot digitally, sending a LFO frequency digitally, sending switch configuration digitally and so on, but the Devil is very much lurking in the details. F'rinstance - there are not an infinite number of digital pot values, nor tapers available. You'll probably have to tweak every pedal to work with the digital pots that are available. You'll certainly have to adapt the pedals to new pots. Setting the LFO to a specific frequency requires either an on-board digital LFO generator for the LFO and the matching redesign of the pedal to include that, or some kind of pot-and-feedback setup to let the controller that's running the show read back and correct the LFO to the right frequency - and THAT requires some kind of smart sensor of frequency and the ability to send the frequency back over your network. Setting switches is the easy part, but every switch has to be replaced by an electronically controllable switch.
So you wind up redesigning every pedal to be put into this thing with either fairly elaborate onboard digital controls(this is what I was referring to as changing the history of the world), or some very elaborate A/D conversion and feedback to the controller on the network (this is what I meant by replacing it) - or both.
It is, of course, possible to design up a generic digital wrapper, very much like the analog wrapper concept I have on GEO where there is a layer of automatable stuff around the effects circuit that takes care of all the mess. But that then becomes a necessity for every pedal, and you have to design in enough complexity on the wrapper to take care of any pedal you want to wrap up in it.
I'm not sure what's the bigger problem - a unique retrofit to every pedal you want to put into this design, or a single digital wrapper that will do any ( or almost any) pedal you want to hook into it. The first is never ending, the second is probably never starting, and likely never ending.
A very clever, very fast communications network for effects use is a great start. But there's a ton of work to get the effects ready to work with it.
And I didn't even touch on how complicated it will be to make this setup so a human can tell it what to do. The human interface is maybe the worst of all. Dealing with the HUMANs is really, really hard, picky, and frustrating when you have to tell a machine how to do it.
QuoteOK, here's something I'm having some issues and confusion about. I've just gotten my STK500, and I've dinked around with it a little, but I'm feeling a bit lost with this whole programming methodology. I'm used to high-level languages, and sugary features like event handlers.
So, how exactly would you handle something like a held-down button programmatically? Do you just keep sampling the thing to make sure it's held down in some sort of sub-loop, or can you link a digital input up to an interrupt or something? So much of this stuff seems like an event-driven system would make sense, though clearly it works without it.
Actually, you have put your fingers on the issues already. There are really only two ways to deal with events - polling and interrupts. Actually, now that I think about it, there's a third way - interrupt driven polling.
Programming in applications level languages hides the details of what is happening in real-time events by hiding behind an interrupt handler. And you WANT it that way, because you don't want to have every single line of programming have to know about the real time events. But you have to either be programming right down at the bare metal or highly disciplined and modular to deal with it.
Here's how you handle real time events in any computer.
Whatever suffices for an operating system is always a never ending loop. It starts at "MAIN" and ends with a "GOTO Main", or the structured equivalents "WHILE TRUE" and "WEND", or other ways to say the same thing in different languages. You either check the event status by polling the I/O once or more times per main loop, using an interrupt handler to break into and out of the main loop, or using a timer to break out of the main loop at regular intervals to poll the external event. Just thinking about it, I don't think there are any other than those three ways.
Polling is ugly, nasty, and only suitable for tiny applications where you know with no doubts that your main loop always executes in less time than you need between polling events.
Interrupts are ugly, and nasty, but they are suitable for getting the offending real world event out of your hair so you can concentrate on what you're doing (either interrupt code or main loop code) and not have to worry about the other all the time.
Timer interrupts are ugly, but they offer a way to deal with the real time event while restricting the amount of time in the main loop spent on it, and still letting you separate real time events from interrupting events in your head.
Notice that only purely interrupt driven stuff can cope with real time events as quickly as the computer can respond. Polling, even interrupt polling, will on average respond to the real world even in half the polling interval, and as bad as the entire polling interval. So you have to be sure that your real-time event can stand for you to wait the polling interval before servicing the event.
Modular block structured programming is a good fit to the human mind. We compartmentalize and analogize incredibly easily. If you have to do something, whether incredibly minute or gigantically complex, you name the whole process, and deal with it as a unit. We deal with "First do this, then this, then.... then this and now start over" very well. The "this" things can be big or small. They just have to be non-interacting, or more properly, interacting only at entry and exit points. If there are two processes that interact in detail that can't be separated out so they interact at entry and exit points only, then they are really not two processes, and should be handled as one.
That was part of what I was trying to get across with one of my recent polemics on programming here. MODULARIZE.
Once it's modularized, you can always get some help on how to write the modules.
In the case of any uC, if the main loop task is short enough, you can simply check the real world event once per main loop, or even sprinkle tests on the real world event throughout the main loop. It is possible to write the main loop so that it always takes the same amount of time to execute, no matter what. This is so-called isochronous code, and is a marvel of elegance. The top octave generator code that you may have heard me talk about is isochronous code.
Isochronous code is perhaps the worst of all possible code to write, leaving aside self modifying code, wihch is itself a death wish.
If the main task is too long for the polling time, I would set up a timer interrupt and use that to tell me when to poll. When the timer goes off, go look at the event you're watching.
If I absolutely, positively have to be on top of the event the instant it happens, nothing except pure interrupt driven will work. Sometimes that's not fast enough if you have a complex interrupt handler. The interrupt latency, the time between the interrupt signal being asserted and the time when you actually service the event, can be too long in some situations.
You have to know how often the real world event happens, and how long you can wait to service it before you can deal with writing code for it. Fortunately, humans and mechanical devices are slow compared to computers.
For instance, sensing the state of a momentary switch. Humans push switches. Human reaction time (that is, the human interrupt response time) is somewhere longer than 1/20 of a second. Faster than that is not detectable from instant by most humans in most circumstances. Human mechanical response time, (as in pressing a switch based on seeing a light) is on the order of 100mS to 250mS if the human is not o o o n n n n d r u g s, ill, or otherwise indisposed. So if you can respond in under 0.02 to 0.2 seconds, you usually are fast enough for humans. Switches bounce. You ... can ... not... tell if a switch is making, unmaking, or bouncing in less time than the switch bounce clearing time. There have been books written about debouncing switches.
And it gets down to
QuoteI need to get some books on uC programming... Recommend any?
Yes - I did. My reference to the PIC list area. Even if you're not doing a PIC, go read the examples in the PIC list on how those people solved things like switch detection, timing generations, math, table lookup, sensing a pot, A/D, etc. You usually don't have to know PIC assembly, as the comments (remember those!!) tell you how the code works, and there is usually liberal teaching along with the code.
It's hard to overestimate how much learning is stored there in the PIC list site. There may be a comparable site for Atmel, but I have not yet found it.
QuoteSorry, probably should have started a new thread for this...
No biggie, but yeah, I think we should.
R.G. -
I don't think anyone is expecting it to be easy. If we wanted easy, we'd be buying stuff from Musician's Foe instead of Small Bear.
I also knew that it would be a big, difficult job wrapping digital control around various discrete analog pedals. Bring it on.
There's strength in numbers.
Having admitted those things, here's how we might get around or at least mitigate them. Let's create a finite list of pedals that we would
want to retrofit with digital control and set about figuring out how to do that. Actually, this is the kind of thinking I was trying to create with
my list of MILAN requirements. I'm not the teacher you are, though, and I certainly can't use the Socratic method.
I understand - I'm into replying to the audience today. You certainly don't need what I was saying. I agree, bring it on.
Quote from: R.G. on March 10, 2006, 10:40:09 AM
You certainly don't need what I was saying.
Oh, yes I do. Where were you when I was studying computer science? Reading your stuff is a hell of a lot easier than reading Knuth or Djikstra!
Now, if we are going to pick some victims, let's start with a short, simple list of the stuff guitarists would use most. This is all purely my own opinion, submitted to spark discussion and further research (And no, I'm no expert at any of this stuff - including software development. I do, however, do a pretty good job of getting people to respond - unfortunately, not always in a positive way.)
DISTORTION: Muffer
MODULATION: EZ Vibe
FILTERING: Maestro Boomer 2 wah/volume
BOOST: Sparkle Boost
COMPRESSION: Aussie Compressor
AMP SIM: Ruby / Prof. Tweed / Eighteen (I don't know - you guys pick some!)
This ought to provoke some discussion... :icon_mrgreen:
Not to hijack but Just a side note. Programming stuff is coming soon. Alittle more patience.
Andrew
Quote from: The Tone GodProgramming stuff is coming soon.
8) 8) 8)
Quote from: R.G.And I didn't even touch on how complicated it will be to make this setup so a human can tell it what to do. The human interface is maybe the worst of all. Dealing with the HUMANs is really, really hard, picky, and frustrating when you have to tell a machine how to do it.
This is why I'm bringing this idea up now. I figure that by the time the first couple of practical real-work examples are ready, there should be some kind of simple kludge user interface available to. ;)
Thanks for making a new thread out of your above post. 8) Very cool stuff. 8)
Quote from: rockgardenloveIn all honestly, I just don't get the point. Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why? Is it somehow advantageous to put all the controls in a central spot?
Imagine David Gilmore having to dance around between all the pedal combinations he uses while the boxes are all in front him, keeping him back 6 feet from the microphone. ;)
If you're setting up for a gig it's much easier to set your pedal box/board down, connect it to your amp(s), and run a single little wire to a little box of stompswitches sitting by your feet to switch settings. Lots of stages just are not all that big if you're into using 14 pedals.
Quote from: rockgardenloveIf you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...? I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.
You
would want all the specific controls for a pedal to inside the pedal. MILAN allows for an easy way to put those settings under remote selection or control, depending on the capabilities of the individual pedal.
It doesn't have to any more complex than being able to switch a preset bunch of pedals on or off via a MILAN controlled switchbox to provide big value. If you can have an expression pedal by your feet that can be remapped to control different effects, that's icing on the cake.
MIDI is just too brain-dead to be as useful as it could have been. It's ironic that it was intended for amateur piano players buying cheap gear, yet it has been pushed to center stage in professional venues. It could have been so much better, but it's not.
Quote from: DavidS on March 10, 2006, 07:49:23 AM
How about synchronizing all of your LFOs? Or having a set of preprogrammed "patches" like in a multi-fx unit? Or having your settings on your pedals be programmable? Or generally being able to program your entire setup and alter multiple parameters in realtime with a single control, across multiple devices? And generally be able to pull off lots of complex studio-esque tricks live, and all by yourself?
You've got it. 8)
Synchronizing LFOs at will is very cool.
Programmable patches of analog circuits is also cool.
Now
being able to alter multiple parameters across multiple devices in real-time with a single control, that's just uber-cool!
Once you add MILAN controllability to a DSP sub-system (;)) you can start doing all kinds of amazing mixing and morphing between analog and/or digital devices and do it in a 100% repeatable way.
R.G. -
Thanks for the reply. Your answer is sort of what I was afraid of! But now that I KNOW it's going to be ugly, I'll stop wasting time looking for a "pretty" solution.
DavidS
I like this idea very much--if we can ever get to a point where digital control of analog devices can move more easily into the DIY realm.
Agree the MIDI with its latency and nasty old connectors isn't the way to go. Regarding the physical layer, are there ruggedized versions of the RJ connectors? The standard ones you use to hook up your computer wouldn't stand up to pedal board or road use.
I think that moving forward with MILAN would need to be baby steps at first--before the .1 spec is finalized, pick one or two types of controls in a typical pedal that it could interact with. Come up with a workable DIY circuit for a digital pot and maybe some kind of CMOS switch. Get those two running in a typical circuit that is easily identifiable, like a fuzz clone or phaser. Then let the community start playing how to actually control that pot, get its current reading, save its value etc.
Your concept is very cool, and very ambitious, sounds like a perfect collaborative project for the DIY community.
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. 8)
I decided to leave the connector out of the spec so that it could get implemented in the way most suitable to the application.
If you had a floor controller that sat by the mic, I would encourage the use of ruggedized RJs link to link that to a box with all the effects in it. The effects box would also have a rugged RJ. Inside the box, I can see using 3.5mm TRS headphone connectors for space constraints inside the individual effects. I could also easily see some 1/4" TRS jacks in there that would allow for MILAN patch cords to jumper to the amplifier(s) for switching there.
Plain vanilla 1/4" TRS jacks have a number of advantages, but they're bulky too. In any case, I could easily see a floor controller linked via 1/4" TRS as having the exact same durability as the analog connection it would replace. The big advantage for 1/4" I see off the top is that if you were at a gig and somebody kills your MILAN cable, you can probably substitute a regular stereo patch cord for the duration of the show without anybody knowing. It's also easy to quickly make up a replacement cable without tools. OK, RJs don't need soldering, they're ideal for differential data connections, and now you can get RJ-45 tools at every home center, but how many musicians know how to make data cables? You normally you have to solder 1/4" plugs, but in an emergency you can just wrap some twisted pair onto the connector lugs and you'll get a working MILAN cable. I've seen fairly large RS-485 networks operate for months with only ONE of the two data wires in tact.
Dano, I think you're right about baby steps. There is still some work to do in reconstructing the MILAN protocols and I'll do that before we start talking about any specific builds. The first issue of a network is how to address the nodes. Apple did a really great job with AppleTalk and since I've got lots of experience with it, I'm going to "borrow" lots of key concepts. Apple used English naming to identify unique devices. I'm doing the same. This eliminates lots of potential addressing problems and gives plug-and-play functionality. The key sub-protocols include MARP (MILAN Address Resolution Protocol) and MDDP (MILAN Datagram Delivery Protocol). These allow for a node to come on line, find a free address, and get to work without messing with DIP switches, requiring devices to have displays, etc.
The first MILAN devices will be a foot-controller with digital switches and indicator LEDs, and an 8 loop effects switcher which allows up to 7 loops to be used at a time, in any order. :icon_biggrin:
We'll deal with analog control later, but I will say now that I'm going to standardize on 16 bit control values.
Thanks everyone for your interest.
I know we can put this technology to use around here for all of our benefit. 8)
Things can either be rugged at some cost, or easily replaceable.
If you're thinking about RJ connectors, make your standard the ethernet patch cable, which is both cheap and has replaceable connectors. Buying a few of these and a crimping tool is probably cheaper than buying a ruggedized version of the RJ's.
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. :icon_confused: 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>
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?
QuoteUsing 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.
Long posts are good. :icon_biggrin:
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.
QuoteMaybe 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! 8)
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! 8)
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.
Quote
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! 8)
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...
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.
Quote from: David on March 19, 2006, 10:56:52 PM
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...)
Quote from: David on March 19, 2006, 10:56:52 PM
I would keep the control system digital and the effects analog to the extent possible.
I agree too! :icon_biggrin:
Quote from: idlefaction on March 21, 2006, 05:28:08 PM
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? :icon_biggrin:
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.
Quote from: Peter Snowberg on March 21, 2006, 05:50:03 PM
Do you have a link by chance? :icon_biggrin:
http://www.imdb.com/title/tt0378378/ <<< enjoy!
Excellent idea!! 8)
Quote from: Peter Snowberg on March 09, 2006, 02:20:15 PM
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 (http://www.atmel.com/dyn/products/product_card.asp?PN=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...
Quote
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.
Thank you for the suggestion Genie. 8)
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. :icon_wink:
Thanks for your interest. 8)
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! ;D
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.
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. :icon_mrgreen:
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. :icon_biggrin: 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. :icon_wink:
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.
Quote from: Peter Snowberg on March 12, 2006, 11:34:12 AM
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. 8)
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...