EMUSIC-L Digest Volume 40, Issue 08 This issue's topics: MIDI Mergers (19 messages) Your EMUSIC-L Digest moderator is Joe McMahon . You may subscribe to EMUSIC-L by sending mail to listserv@american.edu with the line "SUB EMUSIC-L your name" as the text. The EMUSIC-L archive is a service of SunSite (sunsite.unc.edu) at the University of North Carolina. ------------------------------------------------------------------------ Date: Mon, 11 May 1992 15:03:48 CDT From: Joseph Fosco Subject: Re: MIDI Mergers >> How do MIDI mergers work? Are they smart devices? Does it watch the >> running status? Does it buffer bytes as it waits for a sysex to pass >> through? >I don't really know. Yes, they have to be. They had better. Not usually. ----------- Does this mean that a sysex message could get mangled going through a merger? In other words, if a note-on message appeared at one input to a merger while a sysex was passing through the other, would the note-on be placed in the middle of the sysex going out? Just wondering. Thanks, Joseph Fosco Internet: b38669@anlvm.anl.ctd.gov Bitnet: b38669@anlvm ------------------------------ Date: Mon, 11 May 1992 15:08:00 CDT From: greg@IHLPM.ATT.COM Subject: Re: MIDI Mergers Hi, Sorry to jump in on top of this without much direct experience, but I beg to differ... > > How do MIDI mergers work? Are they smart devices? Does it watch the > > running status? Does it buffer bytes as it waits for a sysex to pass > > through? > > I don't really know. Yes, they have to be. They had better. Not usually. ^^^^^^^^^^^ How could they not? I would think that either they would buffer the SYSEX until they had the complete message, allowing other messages from the other input(s) through, or allow a SYSEX through as it arrived, buffering the messages from the other input(s) until it had completed. If they did the former (collected the complete SYSEX from one input before starting to transmit it to the merged output) they would still have to buffer any messages that arrived while they transmitted it. Certainly they can't allow messages from other inputs to be interspersed with a SYSEX message in progress. -- Greg Youngdahl AT&T Bell Laboratories Naperville, IL greg@ihlpm.att.com ------------------------------ Date: Mon, 11 May 1992 15:34:01 EDT From: "Simon Weatherill" Subject: MIDI Mergers How do MIDI mergers work? Are they smart devices? Does it watch the running status? Does it buffer bytes as it waits for a sysex to pass through? Now that I've asked that, how does the Pocket Merge rate? Thanks in advance, simon.weatherill@coat.com ------------------------------ Date: Mon, 11 May 1992 15:44:50 EDT From: metlay Subject: Re: MIDI Mergers > How do MIDI mergers work? Are they smart devices? Does it watch the > running status? Does it buffer bytes as it waits for a sysex to pass > through? I don't really know. Yes, they have to be. They had better. Not usually. > Now that I've asked that, how does the Pocket Merge rate? Excellently. For the money nothing comes close. -- Mike Metlay metlay@minerva.phyast.pitt.edu Atomic City, P.O. Box 81175, Pittsburgh, PA 15217-0675 ------------------------------ Date: Mon, 11 May 1992 16:22:08 EDT From: metlay Subject: Re: MIDI Mergers > >I don't really know. Yes, they have to be. They had better. Not usually. > ----------- > Does this mean that a sysex message could get mangled going through > a merger? In other words, if a note-on message appeared at one input > to a merger while a sysex was passing through the other, would the > note-on be placed in the middle of the sysex going out? Just > wondering. This is considered THE torture test of a merger. A well-designed one will not allow a sysex package to be mangled, no matter what. I need to look up the torture test info from EM and KEYBOARD on the Pocket Merge, to see how it deals with such situations. There are limits to the reasonable behavior of a merger, too: locking up the merger with a long dump should not be common usage, if the other input MUST remain open for other data. -- Mike Metlay metlay@minerva.phyast.pitt.edu Atomic City, P.O. Box 81175, Pittsburgh, PA 15217-0675 ------------------------------ Date: Tue, 12 May 1992 11:10:34 EDT From: metlay Subject: Re: MIDI Mergers > Does the Pocket Merge require a power supply? It probably does. > -- > Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 > Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX Wrongo. It gets all the power it needs from the MIDI line. -- Mike Metlay metlay@minerva.phyast.pitt.edu Atomic City, P.O. Box 81175, Pittsburgh, PA 15217-0675 ------------------------------ Date: Tue, 12 May 1992 11:34:23 +0000 From: Nick Rothwell Subject: Re: MIDI Mergers A fully functional MIDI merger is an impossibility. Since a single SysEx message might be of indefinite length, this would require indefinite buffering in the situation where two SysEx messages arrive for the same destination. What real-world mergers do in these circumstances, I don't know. Certainly they'd be expected to pass SysEx messages through (and all of mine do) but what happens when something else arrives at the same time, I haven't investigated. When I've got music running (as opposed to doing bulk transfers and so on) the biggest SysEx messages flying around are the Wavestation configuration commands which are 10 or 11 bytes, and I haven't had any problems with the MIDI Time Piece or Lexicon MRC (the only two mergers active at present). I'd guess you can expect a (channel) MIDI message or two of buffering on the other side as any SysEx goes through. Nick. ------------------------------ Date: Tue, 12 May 1992 16:12:35 +0200 From: Adam Mirowski Subject: Re: MIDI Mergers >A fully functional MIDI merger is an impossibility. Since a single SysEx >message might be of indefinite length, this would require indefinite >buffering in the situation where two SysEx messages arrive for the same >destination. You don't even need infinite length sysexes. If the total flow of incoming data is above 31.25bps, you must drop something. >What real-world mergers do in these circumstances, I don't know. Certainly >they'd be expected to pass SysEx messages through (and all of mine do) but >what happens when something else arrives at the same time, I haven't >investigated. When I've got music running (as opposed to doing bulk >transfers and so on) the biggest SysEx messages flying around are the >Wavestation configuration commands which are 10 or 11 bytes, and I haven't >had any problems with the MIDI Time Piece or Lexicon MRC (the only two >mergers active at present). I'd guess you can expect a (channel) MIDI >message or two of buffering on the other side as any SysEx goes through. Does the Pocket Merge require a power supply? It probably does. It could imagine it contains something like an Intel 8052 microcontroller, with 256 bytes of on-board RAM and on-board EPROM containing machine code (I suppose doing things in Basic would require external RAM). -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX ------------------------------ Date: Wed, 13 May 1992 13:56:28 +0000 From: Nick Rothwell Subject: Re: MIDI Mergers >You don't even need infinite length sysexes. If the total flow of incoming >data is above 31.25bps, you must drop something. No: if you've got indefinite buffering, you're fine - the limit is the speed at which the processor can get stuff into the RAM buffer(s) for later transmission. Nick. ------------------------------ Date: Wed, 13 May 1992 14:47:02 ADT From: Alan Edwards Subject: Re: MIDI Mergers In message writes: > >>Is there any current in the MIDI loop in the idle state? > > yes .... > >They don't; it seems to be a case of trickling power from the current loop. > Just look at the MIDI OUT pin-out. Pin 4 comes from 5v through a resistor, and should give sufficient current for most CMOS uPs to work on. .. > >>Maybe the micro-controller could be substituted with a PAL (Programmable > >>Logic Array) coupled with a memory chip, all that in CMOS technology? > > .... > >The Studiomaster MA-36 MIDI analyser (a *superb* little box. by the way) > >seems to be a PAL: 40 or so LED's connected to a large chip with the > >minimum of glue logic. And they got the PAL wrong: MIDI beat RT messages > >confuse it... > A lot of things can be done with just a good UART. I made an analyzer similar to the MA-36 (long before it came out) based on the IM6403. This baby can work all by itself (no micro required) and all it took was some decoders to figure out which MIDI message was coming through. I did not try to get power from the MIDI lines, but with a standby current of 5 uA it would not have been be too hard. Lots of things such as filters could be done this way. Just hardware! Alan ------------------------------ Date: Wed, 13 May 1992 15:11:57 +0000 From: Nick Rothwell Subject: Re: MIDI Mergers >Does your real-timeness prefer being killed by hanging or would it be more >pleasant for it to be shot? Same kind of choice. If you're merging two data streams that real-timeness starts going out of the window. (realtime response of MIDI is a whole area of discussion and debate anyway.) If you're trying to get two SysEx messages to one destination then it's going to take time to digest them anyway, so local buffering isn't going to make things much worse... >I have examined >most of the boxes I have, but as a *very* amateurish electronic musician I >don't have any MIDI merger. :-( I've had a look inside the MX-8 but don't remember very much of it. I'd guess just a processor and a pile of DUARTS, one for each IN/OUT pair, so I'm not sure what this proves. But my knowledge of electronics is rather basic... Nick. ------------------------------ Date: Wed, 13 May 1992 15:24:58 +0200 From: Adam Mirowski Subject: Re: MIDI Mergers >>You don't even need infinite length sysexes. If the total flow of incoming >>data is above 31.25bps, you must drop something. > >No: if you've got indefinite buffering, you're fine - the limit is the >speed at which the processor can get stuff into the RAM buffer(s) for later >transmission. :-) Does your real-timeness prefer being killed by hanging or would it be more pleasant for it to be shot? Same kind of choice. It's time that someone opens a (simple) MIDI merger box to see what is really inside. Otherwise this discussion wil ressemble the one on the beginning of the last century when people preferred discussing whether a train would slip on rails instead of bothering to check it experimentally. I have examined most of the boxes I have, but as a *very* amateurish electronic musician I don't have any MIDI merger. :-( -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX ------------------------------ Date: Wed, 13 May 1992 16:37:23 +0000 From: Nick Rothwell Subject: Re: MIDI Mergers >Is there any current in the MIDI loop in the idle state? Now things get complicated. I've never understood this. I'm about to buy a pair of the Opcode MIDI Translators for one of my Macs, and these things (apparently) draw power from MIDI, not from the Mac serial port. The current loop business confuses me, and I can never work out whether they can draw parasitic power from MIDI IN or MIDI OUT. >Maybe the merger only gets active when a message burst appears. But that >would be difficult for a micro-processor to restart itself each time. They don't; it seems to be a case of trickling power from the current loop. >Maybe the micro-controller could be substituted with a PAL (Programmable >Logic Array) coupled with a memory chip, all that in CMOS technology? The Studiomaster MA-36 MIDI analyser (a *superb* little box. by the way) seems to be a PAL: 40 or so LED's connected to a large chip with the minimum of glue logic. And they got the PAL wrong: MIDI beat RT messages confuse it... Nick. ------------------------------ Date: Wed, 13 May 1992 17:22:37 +0200 From: Adam Mirowski Subject: Re: MIDI Mergers >>I have examined >>most of the boxes I have, but as a *very* amateurish electronic musician I >>don't have any MIDI merger. :-( > >I've had a look inside the MX-8 but don't remember very much of it. I'd >guess just a processor and a pile of DUARTS, one for each IN/OUT pair, so >I'm not sure what this proves. But my knowledge of electronics is rather >basic... Sorry, I have not been specific enough. My curiosity for the internals of MIDI mergers was for the no-power-supply ones. I have admiration for people that succeed to hook such a circuit on a 5mA power supply (yes, it should work with only one input too!). Is there any current in the MIDI loop in the idle state? Otherwise the device could only use the Active Sensing burst (:-)). Maybe the merger only gets active when a message burst appears. But that would be difficult for a micro-processor to restart itself each time. The Running Status could not be processed correctly either in the absence of a permanent power supply: if sources issued message alternatively, each using the running status method to save bandwidth, the merger would need to *remember* the current running status for each source, and *modify* the message issued by any source if the previous message came from the other one. Maybe the micro-controller could be substituted with a PAL (Programmable Logic Array) coupled with a memory chip, all that in CMOS technology? I thought first the all the circuit could be clocked by the incoming messages, but now I would probably use an internal clock. To save power consumption, the clock could be triggered by the start-bit of the first message and would automatically stop when the buffer becomes empty (or by the end of the stop bit, whichever happens last). An UART could be avoided in both designs: there is no parity in MIDI messages, bytes are fixed width and MIDI messages have a specific format (the decisive ctrl/data bit comes always first) which encourages on-the-fly processing. Thank you for reading till there! No, I am no hardware man. Just an amateur (as in music). -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX ------------------------------ Date: Wed, 13 May 1992 18:16:51 +0200 From: Adam Mirowski Subject: Re: MIDI Mergers >>Is there any current in the MIDI loop in the idle state? > >Now things get complicated. I've never understood this. I'm about to buy a >pair of the Opcode MIDI Translators for one of my Macs, and these things >(apparently) draw power from MIDI, not from the Mac serial port. The >current loop business confuses me, and I can never work out whether they >can draw parasitic power from MIDI IN or MIDI OUT. Here I would be very affirmative: the MIDI-in plug is electrically isolated from the device, the information passes as light, so it is not possible to draw any power from MIDI-in. >>Maybe the merger only gets active when a message burst appears. But that >>would be difficult for a micro-processor to restart itself each time. > >They don't; it seems to be a case of trickling power from the current loop. It doesn't contradict. The device gets the power from the line in every case. Simply, if the line is permanently supplied, the controller gets power all the time, except during message oscillations, and in the other case, it receives no power except during the oscillation, but that is impossible because of the running status. >>Maybe the micro-controller could be substituted with a PAL (Programmable >>Logic Array) coupled with a memory chip, all that in CMOS technology? > >The Studiomaster MA-36 MIDI analyser (a *superb* little box. by the way) >seems to be a PAL: 40 or so LED's connected to a large chip with the >minimum of glue logic. And they got the PAL wrong: MIDI beat RT messages >confuse it... You have tons of exciting hardware :-) BTW, that could an ASIC (Application Specific Integrated Circuit) too, if the company is big enough. It could include all the RAM it needs (but an analyzer doesn't necessarily need it). And it is more difficult to bug-fix than a PAL-based solution. -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX ------------------------------ Date: Thu, 14 May 1992 11:54:00 EDT From: RAY BROHINSKY Subject: Re: MIDI Mergers This looks like a good time to add my foolish conjecture to the pot... First of all, sysex's tend to be long. The only real exception I've seen to this (and my experience is neither comprehensive nor as eclectic as I'd wish) are the note-events-with type, like the microtunable FB01 sysex note-events. If you have to buffer these, you can do it with a fairly small amount of ram, like 1K. Longer sysex's usually change something, or disable sound output or something like that. Sending note-ons to a synth that is learning a whole new song/sound/bank thereof, is kinda like my 15-year-old, who always has to interrupt anything I say to my wife with incongruities: it's disruptive and annoying, and doesn't accomplish anything. My kid may try it on me and live, but doing that to an audience is fatal. so, IMHO, a midi merger needs to buffer small sys-ex's and normal events long enough to let the last set of stuff get out, and it needs to recognize that a sysex over a certain length is more important than short sys-ex's and events, and ignore the latter until the former is complete. Since sysex's are easy to identify, even for the likes of an 80C51, and the length is right there up front, a merger that sees a long one come in can immediately finish whatever it was sending and start streaming the long sysex out. It should not be any problem to do so, and it should, in the process, clear out any old events/ short sys-ex's that probably won't mean much after the big one is done. If it sees two long ones, it'll just have to decide which one came first, and forget about passing the other. Remember, midi is (as it now stands) _just_ a serial channel. You can't push two sysex's into one synth, nor should you try. If you think you'll need to send note-on's to one synth while sys-exing to another, you really need more thought about routing and such than just throwing mergers at the problem. raybro . ------------------------------ Date: Thu, 14 May 1992 12:42:00 EDT From: RAY BROHINSKY Subject: Re: MIDI Mergers :From: Adam Mirowski :>>Is there any current in the MIDI loop in the idle state? :> :>Now things get complicated. I've never understood this. I'm about to buy a :>pair of the Opcode MIDI Translators for one of my Macs, and these things :>(apparently) draw power from MIDI, not from the Mac serial port. The :>current loop business confuses me, and I can never work out whether they :>can draw parasitic power from MIDI IN or MIDI OUT. :Here I would be very affirmative: the MIDI-in plug is electrically :isolated from the device, the information passes as light, so it :is not possible to draw any power from MIDI-in. The usual way for current loops to work is as follows: a power supply provides a voltage which is high enough to provide the maximal current flow to the devices on the line. In the case of a 20ma loop, this is usually between 24v and 48v, in the case of MIDI it is 5v. The `sense resistors' are chosen to drop a voltage that can be sensed without confusion from line noise, induction, etc. There is a ballast resistor between the power supply and the beginning of the sensors, and some kind of electronic switch to control the current flow. Rather than switching between current flow and no current flow, the switch selects between maximum and minimum currents. In MIDI, if the maximal flow is 5ma, the minimal might be from .8 to .1ma. This may seem like very little, but you have to remember something: Most CMOS circuitry needs voltage with little current (unlike TTL which can be made to work on odd voltages, but suck lots of current!). If your processor needs 8ua for quiescent current, but a whopping 400 ma for maximum switching (CMOS draws power only when changing states) you can run without further consideration. If you need as much as 2ma when switching (capacity, rather than actual current-per-switch, mind you) you can add a cap which will charge up during quiet times and more so during the high-current portions of each bit. That provides the current for the string. Since the easiest way to convert the current to a usable voltage is with an optical isolator, that's the common device used to convert. However, there are many other devices that do the job, the simplest being a resistor! The optoisolator has the resistor beat in a number of ways, not least of which being that, on the low-current condition, it looks like not much resistance, but gives a good hard high out, and on the high current condition, it looks like not much resistance, and gives a good darn-near-ground out, with a great switching transient shape. However, the message is not sent from synth to synth by light! If it were, you'd have optical cables connecting your synths instead of copper wire. The first time you got one kinked, your cable would be toast. (And optical cables ain't that cheap, either!) Optoisolators _do_ provide isolation by an internal optical path, so if you have two different power supplys, you can arrange to send signals from one circuit to another without having to have a return path between the two power supplies. However, in cases where the opto's are fully powered from the input, you don't get that kind of power-supply isolation; just signal-flow isolation. Simply: both sides of the isolator are powered from current from the incoming line, and so the isolation is bridged. However, what we're really looking for here is cheap and lo-parts-count, not level-one explosion proof, right? So the opto's are powered both on the detection side and the indication of detection side from the same power source, i.e., the incoming current. :>>Maybe the merger only gets active when a message burst appears. But that :>>would be difficult for a micro-processor to restart itself each time. :> :>They don't; it seems to be a case of trickling power from the current loop. :It doesn't contradict. The device gets the power from the line in every :case. Simply, if the line is permanently supplied, the controller gets :power all the time, except during message oscillations, and in the other :case, it receives no power except during the oscillation, but that is :impossible because of the running status. There are many reasons why you wouldn't want to run a current loop from flow to off. Not least of all is the fact that you can get an instant integrity diagnostic if the current ever comes to a halt! Current loops are marvelously good for other reasons, not least of which is the fact that you get the same current flow in all parts of the loop at all times. That means that, if your current controller can cut current from 20ma to 4ma in 15ns, the change in state will be obvious at the detector 15ns after the change is initiated. Unfortunately, detectors tend to be slower about detecting this, especially optoisolators (which have detection times in the microseconds, fer heaven's sake!). Getting current to stop completely and start up from nothing is more difficult than merely controlling flow between two levels. :>>Maybe the micro-controller could be substituted with a PAL (Programmable :>>Logic Array) coupled with a memory chip, all that in CMOS technology? :> :>The Studiomaster MA-36 MIDI analyser (a *superb* little box. by the way) :>seems to be a PAL: 40 or so LED's connected to a large chip with the :>minimum of glue logic. And they got the PAL wrong: MIDI beat RT messages :>confuse it... Nick, I've seen chips that look just like that that have a cpu, 256bytes ram, 2K EEPROM, 8K ROM (mask programmable at manufacture, but makeable in lots of 10000), five timers, 3 counters, 40 I/O lines including two independently controllable UARTs (one of which will do microwire), and extended 8-16 bit instruction sets. 68hc11 family is one such. If you're a small company with good designs and venture capital, you can get 10000 of these with 10 programs in the ROM, and choose which to run with the EEPROM. A couple of opto's and you're set...power it from the incoming current. I'm still working on a design...8^( in my copious spare time! :You have tons of exciting hardware :-) people are jealous of Nick all over the world! 8^) :BTW, that could an ASIC (Application Specific Integrated Circuit) too, :if the company is big enough. It could include all the RAM it needs :(but an analyzer doesn't necessarily need it). And it is more difficult :to bug-fix than a PAL-based solution. PALs are fine for very limited things that can be described with very limited state diagrams. I've done some marvelous things with PALs, but I don't thing one would be up to a midi merger. ASIC's are a different story: they come in two or three flavors. Full ASICs are expensive, require large runs to justify doing them at all, and have their place in the world, but not in something I'd like to pay for! last-step laser-programmables are OK, lots of functionality, fairly low cost, and the purchase of a large enough bunch to make them cost effective won't leave you stuck with 39,997 midi merger chips when the midi spec changes...but the capital investment is fierce, and the technical help required to use the laser cutters is hefty. You'd need to be large like Yamaha to do that...and they already do their own asics. Then there's the ram programmable ones, like the Xilinx chips. They are slightly more expensive in large quantities, but more cost effective in smaller quantities; require support hardware (although the simple serial eproms are nice!). To change the function, reprogram the eprom that feeds the onboard ram. They are somewhat susceptable to power fluctuations (a dip could dump ram without successfully triggering a full power-up reload), it takes time to load one, and (worst of all) they are a lot closer to PALs in functionality. given a choice, I'd go with a full-function CMOS microcomputer on a chip. The FN68hc11F is sold by NMIX for about $37.50, and they don't do that large a volume. You'd just need to know what the ten(or so) things you're gonna do with it are before going to masks. (although you can patch and even put full programs in the EEPROM, and a new version has lots more EEPROM!). :-- :Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 :Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX raybro *** Nieder mit den Tueten! Freiheit fuer Gummibaerchen! *** ------------------------------ Date: Fri, 15 May 1992 13:24:22 EDT From: "Patrick Robinson" Subject: Re: MIDI Mergers >:You have tons of exciting hardware :-) > >people are jealous of Nick all over the world! 8^) What, the synths-'n-stuff? or the dancers? :-) -Patrick pgr@ramandu.ext.vt.edu ------------------------------ Date: Fri, 15 May 1992 14:23:32 EDT From: "Simon Weatherill" Subject: MIDI Mergers I just read an article in Home & Studio Recording about the Voice Crystal Merger Plus. It looks the same as the Pocket Merge (i.e. no battery, etc.), but it has a reset switch on it. It says that if a SYSEX comes in on one port, it will buffer data on the other channel. If the buffer fills up, it discards data from the front of the queue. The article did not say how big the buffer was. It uses 20mW of the the inline MIDI-power. It recommends not placing more than one on a link. simon.weatherill@coat.com ------------------------------ End of the EMUSIC-L Digest ******************************