Next/previous switching a multiplexer

[KrisBlueNZ]

I'm a little confused, because we already added pullup/-down resistors to the schematic, didn't we?

Pullup and pulldown resistors are needed when a device (e.g. a transistor or a pushbutton) only pulls the signal in one direction, to ensure that the signal assumes the opposite state when that device is not active.

In your circuit in post #11, R17, R19, R2, R4, R6, R8, and R11 are all pullup resistors, and are all needed.

R13 in that diagram is a pulldown resistor that pulls the A, B, C and D inputs of IC5 low. Nothing else acts on those inputs; they will always be low. So they can be connected directly ("tied") to 0V instead of "pulled" to 0V through a resistor, in the same way that the -LOAD input is tied high and the CLEAR input is tied low.

I'm looking into the stuff you asked about previously about volatility and LEDs, but for now wanted to show a schematic I received from someone years ago when I started another project (still not done) where I also wanted to show MIDI activity by flashing an LED for each MIDI port. But can't it be done simpler? I was hoping I could just "tap into" the existing MIDI pins (pin 4 and 5) for each MIDI port I'd be wanting a flashing LED for, but this schematic takes the existing MIDI IN, puts it through the LED circuit and ends with a replacement MIDI IN socket. The nice thing about it though is that the two ICs have enough gates for two LED circuits.

The MIDI output sockets are normally called MIDI "thru" outputs because they carry an exact copy of the MIDI data stream that's coming into the inputs. They're needed because MIDI is a point-to-point system; you can't (or you shouldn't) connect one MIDI output to the MIDI inputs on two separate devices. So any device that monitors MIDI data travelling from a MIDI source to a MIDI destination, like that one, needs to receive the data from the source, monitor it, and retransmit it so it can pass to the destination.

The circuits using IC2 are called monostables or one-shots or pulse stretchers. They are needed because a short MIDI message may only contain one byte, and in the absolute worst case, the data line may only go active for 32 µs. A 32 µs flash on an LED is not detectable with the naked eye (except perhaps in a dark room if you're very close to it and watching it intently). So it is not practical to drive the activity LED directly from the data stream. Some kind of pulse lengthening is required.

There are other ways to implement a pulse stretcher for MIDI data. A simple way I alluded to uses a transistor to rapidly discharge a capacitor while the MIDI data line is in the active state, and this illuminates the LED; when the line goes inactive, the capacitor takes a short time to charge up, and during this time, the LED remains ON.

Here's a circuit that shows one way:



MIDI data comes through U1. When the MIDI line is idle, U1's output (the MIDIDATA node) is high; any activity causes it to pulse low. When this happens, Q1 (a PNP used in the emitter follower aka common collector configuration) conducts and pulls its emitter towards 0V, discharging CT and pulling the bottom end of RT towards 0V. This creates a base-emitter voltage for Q2 which causes it to conduct and illuminate the LED.

When MIDI data stops, Q1 stops discharging CT. CT charges up through RT. When there's insufficient voltage to keep Q2 turned ON, the LED goes out.

You can see the circuit's operation on the simulation graph. It's being driven with a single 32 µs pulse (a single start bit) every 200 ms. The green trace shows the voltage at the VT node; it drops down to nearly 0V on each MIDI data pulse, then charges up, following the standard R-C charge curve. The dark blue trace shows the LED current; you can see that the LED illuminates immediately when CT is discharged, then turns OFF a short time later as CT has charged up.

This is only one of many ways of implementing this feature. Smarter methods can be implemented with a microcontroller - for example, occasional MIDI data can cause a long blink, whereas continuous MIDI data can cause the LED to blink ON and OFF quickly; with a simple circuit like this, continuous MIDI data will just cause the LED to remain ON steadily.

 

[TTL]

Thanks for clearing up the difference between pullup/-down resistors and "tying down" a signal. Although I'm no engineer I find your explanations very clear and understandable. Now figuring out on my own where to tie down/pull up or down with resistors in circuits I try to design is another story altogether. But I'm learning

I've been concerned about signal degradation, delays or other problems with a THRU port as opposed to just "tapping into" the MIDI port, which is why I haven't just settled for the schematic I attached in posting #20. I know THRU boxes are meant to solve the delay problem which you'd otherwise get when daisy-chaning MIDI devices, but can't help but think that the signal out just won't be the same as the original port. Do I need to be concerned?
If I attach this circuit to each of the IN ports of the MIDI input selector circuit, can't I just tap into the signal there, right after its opto-isolator (6N138) instead of adding yet another one (4N26)?

I understand that IN ports demand opto-isolators according to the MIDI standard, but this doesn't apply to OUT ports, does it? So how does that apply when using this circuit with an IN port? (another project I'm working on involves a computer with multiple MIDI IN and OUT ports where I also want LEDs to flash indicating data-flows for each port).

So apart from the IC-based circuit I posted having the ability to adjust the pulse length, does your transistor based one do the exact same thing, possibly just costing a bit less? I suppose a trimmer resistor could be incorporated to do the same thing. Is RT the resistor that needs to replaced by a trimmer in case I want to do that?
A microcontroller for the LEDs does seem like the ultimate solution, but as with the input selector circuit/volatility issue it's likely very much beyond my capabilities.

I've recreated your schematic in Eagle (it's good practice, and nice to have in case I'll be using it) but don't know if I've got the MIDI input pins right:

 

[KrisBlueNZ]

You're right that the signal coming out a MIDI THRU connector will not be exactly the same as the signal going into the MIDI IN connector.

Optocouplers introduce an effect called skew, because they respond more quickly to an active-going edge (a start bit or 0-bit in the data) at the LED than to an idle-going edge (end of data or a 1-bit in the data). This means that if you inject a continuous 1-0-1-0-1-0... bitstream, which has a duty cycle of 50% (active and inactive times are equal), the output from the optocoupler will not have a duty cycle of exactly 50%.

If multiple devices are cascaded using MIDI THRU, the skew will get progressively worse, until the data cannot be reliably received.

How many MIDI THRU stages are needed before this happens? I don't know. It depends on the characteristics of the receiving optocoupler at each point. But I did a Google search and couldn't find anyone who has had real-world problems with it.

(BTW during that search I found a nice explanation of MIDI messages at http://www.thewhippinpost.co.uk/midi/midi-messages.htm which may interest you.)

If you're concerned, you can probably speed up the LED turn-off slightly by adding a resistor (say 1k) across the LED on the receiving optocoupler, and you can use a fast optocoupler with built-in Schmitt trigger output such as MOC5007 or H11L1. These don't need a base-emitter resistor (RB in that schematic) but will be a bit more expensive.

BTW, the 4N26 is probably not a good choice. I only used it in my MIDI activity indicator circuit because it was available in the circuit simulation software I use.

No, you mustn't tap into the non-isolated signal for the MIDI THRU output. Not because it's not isolated - as you say, since it's feeding another optopcoupler, isolation isn't an issue. But because you can't reliably drive two MIDI inputs from a single MIDI output. Whether you connect them in parallel or series, the electrical characteristics of the MIDI interconnection are NOT designed to support driving two MIDI receivers from a single transmitter. It may work in some cases, but it's not compliant with the standard.

You're right that MIDI inputs must be optoisolated and MIDI outputs are not. A computer with multiple MIDI IN and MIDI OUT connectors will comply with this - each MIDI IN will be individually optoisolated, and all of the MIDI OUT connectors will be driven directly without any isolation.

Yes, my transistor-based circuit does pretty much the same thing as the CD4013-based circuit in post #20. They will behave slightly differently in certain circumstances, because the IC version is an edge-triggered monostable, but the transistor version is better described as a delayed turn-off circuit. For example, assuming that both circuits illuminate the LED for 40 ms (1/25 of a second), if there is MIDI activity every 30 ms, the IC version will flash the LED rapidly but the transistor version will just keep the LED ON steadily. In typical use conditions, you probably wouldn't notice a difference.

If you want to change the LED blink duration, adjust CT. Actually that's probably not the best circuit. The best approach would be to use a microcontroller. A PIC16F527 would be a good choice. It could handle eight MIDI data streams and can drive the eight LEDs directly. The only external components needed would be the LEDs, current limiting resistors for the LEDs (you can use a resistor network to save space), and a decoupling capacitor. Something to think about for the future!

I think my circuit needs a bit of work. There's a conflict between responding to very short MIDI data pulses, and getting a decent LED blink duration. I'll redesign it using MOSFETs and post a new version.

Your circuit is close to right.

1. You need to remove the line connecting the optocoupler's cathode to the circuit's GND rail - the optocoupler is there for isolation, after all!

2. You should add a reverse-connected diode (e.g. 1N914/1N4148) across the optocoupler LED, as shown in the other circuits you posted. This protects the LED in the optocoupler from possible damage from electrostatic discharge.

3. RIN should be 220 ohms.

 

[Harald Kapp]

I'm a little confused, because we already added pullup/-down resistors to the schematic, didn't we?

I'm sorry, please don't be confused. This is a little discussion between Kris and me. For your schematic it will work with resistors or direct connections to Vcc or GND for unused pins.

Tapping directly into the MIDI connection (or by the way of a bufffer) will not be very useful. The original MIDI datarate is 31.25 kBit/s, much too fast for the human eye to notice any change in LED brightness. That's why the schematic in your post #20 uses monoflops to create a visible pulse length from the fast MIDI signal. The monoflops are made from flipflops (3013) with some external circuitry. I don't think this use of a flipflop as a monoflop is particularly good. The R-input of the flipflop will see a slowly rising edge due to C1. It is not intended for slow edges. A Schmittt-Triggger between C1 ad R would be advisable. Or use a monoflop that is meant to be one (e.g. 4093).

Harald

 

[TTL]

No worries Harald

No, you mustn't tap into the non-isolated signal for the MIDI THRU output. Not because it's not isolated - as you say, since it's feeding another optopcoupler, isolation isn't an issue. But because you can't reliably drive two MIDI inputs from a single MIDI output. Whether you connect them in parallel or series, the electrical characteristics of the MIDI interconnection are NOT designed to support driving two MIDI receivers from a single transmitter. It may work in some cases, but it's not compliant with the standard.

I wasn't aware the LED circuit was considered another MIDI device (as being yet another synth or drum machine), but always assumed I would just be "tapping into" the existing signal. Then again the LED circuit does somewhat (in a rudimentary way but nonetheless) read the MIDI signal, which is what a MIDI synth would do as well come to think of it, just not analyze and use it, rather just detecting it.

So the conclusion to all of this is: if I want an LED indication of MIDI activity then I also have to expect some kind of MIDI signal loss? And there is no way to read into the MIDI signal without affecting it negatively?


MIDI timing is probably the problem I fear the most (i.e. when playing a song from the MIDI sequencer) and I'd hate to mess up the rather excellent MIDI flow from the sequencer, but at the same time want a visual feedback of which MIDI port is having data passed out or in from it.

 

[KrisBlueNZ]

I wasn't aware the LED circuit was considered another MIDI device (as being yet another synth or drum machine), but always assumed I would just be "tapping into" the existing signal. Then again the LED circuit does somewhat (in a rudimentary way but nonetheless) read the MIDI signal, which is what a MIDI synth would do as well come to think of it, just not analyze and use it, rather just detecting it.

Right. The activity indicator receives the MIDI data using an optocoupler, converts it to a logic-level signal so it can detect it easily and illuminate the LED, and then re-transmits it. There is an inherent skew introduced by the optocoupler, and it will affect the signal. The simple solution is to minimise this skew, which is why I suggested the MOC5007/H11L1 which is designed for fast data and has a digital output.

As I said, I couldn't find anyone who had had real-life problems with skew due to cascaded MIDI THRU connections, and it's very preferable to receiving the MIDI byte-by-byte and retransmitting it, which will introduce a delay of about 0.25 ms.

So the conclusion to all of this is: if I want an LED indication of MIDI activity then I also have to expect some kind of MIDI signal loss? And there is no way to read into the MIDI signal without affecting it negatively?

There might be a way to compensate for the skew, but I don't think you should worry about it, especially if you use a fast optocoupler.

MIDI timing is probably the problem I fear the most (i.e. when playing a song from the MIDI sequencer) and I'd hate to mess up the rather excellent MIDI flow from the sequencer, but at the same time want a visual feedback of which MIDI port is having data passed out or in from it.

I think you're worrying unnecessarily.

Here's an updated version of the pulse stretcher using MOSFETs. It works a lot better than the other version. If you decide to build it, there are probably better component options for the MOSFETs - I only used those ones because LTSpice has them built-in. Let me know whether you're using SMT (surface-mount technology) or THT (through-hole) components, and your preferred supplier, and I'll suggest some better options.

 

[TTL]

So "skew" isn't the same thing as MIDI timing delays? What exactly does opto-coupler skew do in practical terms concerning MIDI?
Out of curiosity I downloaded a service manual for a MIDI synth module which indeed has a "MIDI message" LED just to see how it's connected. I'll take a closer look and post it here later.

Getting back to the transistor based LED schematic...
I've tried to follow your suggestions but I'm not sure I fully understood everything, so here's version #2 with the following changes. Does it look right (MIDI input connections, power supply etc.)?

Your circuit is close to right.

1. You need to remove the line connecting the optocoupler's cathode to the circuit's GND rail - the optocoupler is there for isolation, after all!

2. You should add a reverse-connected diode (e.g. 1N914/1N4148) across the optocoupler LED, as shown in the other circuits you posted. This protects the LED in the optocoupler from possible damage from electrostatic discharge.

3. RIN should be 220 ohms.

Next is version #3 which is an attempt to copy your most recent schematic in Eagle (I've also attached the reverse diode across the optocoupler as you suggested previously even if you didn't include it here). I'm not sure if I've got the MOSFET pinouts correct nor other details (the symbols in LTspice are a little different from the ones I'm used to):




Finally, here's version #4 which is the MOSFET version (I might have gotten the new optocoupler connections wrong here), but with the following changes:

If you're concerned, you can probably speed up the LED turn-off slightly by adding a resistor (say 1k) across the LED on the receiving optocoupler, and you can use a fast optocoupler with built-in Schmitt trigger output such as MOC5007 or H11L1. These don't need a base-emitter resistor (RB in that schematic) but will be a bit more expensive.

If you decide to build it, there are probably better component options for the MOSFETs - I only used those ones because LTSpice has them built-in. Let me know whether you're using SMT (surface-mount technology) or THT (through-hole) components, and your preferred supplier, and I'll suggest some better options.

I prefer good old through-hole components. I don't have a preferred supplier as of yet (haven't built stuff for years so I'll be starting all over again. I mainly ordered from Maplin in the UK back in the 80s, but they don't have much of components today). You said the LED schematic using ICs which I posted earlier in posting #20 works (for all practical purposes) in the same way as your transistor version of this. Is cost the advantage over it?

 

[KrisBlueNZ]

Skew is a delay, but in this case it's shorter than one bit-time (32 µs), which is short compared to the delay introduced by receiving a whole byte then retransmitting it, which is a minimum of one byte-time (256 µs). Skew causes the data bits in the message to become wider (or narrower, depending on the direction of the skew). Skew is caused by different delays on rising and falling edges in the data.

I tried to find a diagram that explains it. The best I could find is http://www.wildpackets.com/images/compendium/AB21-3.gif but it's not quite right.

In that diagram, the top signal represents the 1-bits and 0-bits of MIDI data as it arrives at the MIDI IN connector, and the botton signal represents the signal coming out of the optocoupler. (Actually the optocoupler's output signal is upside down but that's not important.)

You can see that there is a delay between the MIDI IN signal rising, and the corresponding change at the output of the optocoupler. This time delay is marked "Skew" on the diagram, but that's not really what skew is.

See that on the other edge, the falling edge, there is also a delay between the falling edge at the input, and the corresponding edge coming out of the optocoupler.

Skew is the difference between those two delays. At least, that's the kind of skew I'm talking about!

If those delays are the same, then the data coming out of the optocoupler is not skewed. It is only slightly delayed.

But optocouplers are not perfect and they will always introduce SOME skew. Normally, the delay on the falling edge is longer than the delay on the rising edge. Because physics.

This means that the waveform you see at the output of the optocoupler is not a perfect square wave with a duty cycle of exactly 50%. Its duty cycle is widened; to perhaps as much as 55%.

If you retransmit this skewed data through another similar optocoupler, it will add its own skew (in the same direction), making its output duty cycle 60%.

The more cascaded optocouplers you have, the more the skew will magnify, until eventually it will be impossible for the microcontroller in the synth (or whatever) to receive the MIDI data properly.

These examples show the effect with a continuous bitstream at 31.25 kbps, i.e. 32 µs high, 32 µs low, 32 µs high, 32 µs low, and so on. That's just for convenience. No matter what the MIDI data is, it has rising and falling edges and will be affected by skew.

You can find the data sheet for the H11L1, which I recommend, at http://media.digikey.com/pdf/Data Sheets/Fairchild PDFs/H11L1, H11L2, H11L3.pdf. Look for the Dynamic Characteristics section. The important parameters are t_ON and t_OFF and they are 1 µs and 2 µs respectively, typically, which are 3% and 6% of one bit-width for MIDI data. So each H11L1 will add a skew of (6% - 3%) = 3% of a bit-width, approximately.

Those schematics all look good, apart from one error in the last one - two of the connections on the output side of the H11L1 are wrong. The top pin, pin 6, marked VCC, needs to connect to +5V, and the middle pin, pin 4, output, connects to RC and Q1's gate. RS isn't needed.

Why use the transistor version instead of the IC version? It's slightly more compact, and it can light the LED more brightly (the CD4013's outputs can't supply much current).

I think I've noticed another error. In other MIDI documentation I've seen, pin 4 was positive and pin 5 was negative; all your diagrams have had the opposite. Can you check on this please?

Also, I'm not sure about the connection to pin 2. Is this supposed to be connected to the chassis at both ends? In that case, the MIDI cable mustn't connect it through from one end to the other, otherwise that will cause an earth loop, and avoiding earth loops is the reason MIDI uses optocouplers! That's probably how I think it's done, although personally I wouldn't use screened cables for MIDI - they just add extra capacitance with slows down the signal. Again, can you find out?

I decided to draw up a complete schematic of a MIDI repeater with an activity LED. I've used what I think is the right polarity for the MIDI connectors.

 

[TTL]

I think you're right about me exchanging MIDI input pins 4 and 5. I found this page which confirms what you're saying: pin 4 is positive and pin 5 is negative. Thanks for pointing it out.
About MIDI pin 2 I'm not completely sure either. I do know that it should be connected in one part of a circuit and not connected in another, I just can't remember where. I'll do some research and get back when I find out more. I think the MIDI cables are supposed to be screened, but the screening should only be connected to one end. Again, I'll have to look into this.

The circuit's looking good with the THRU socket. Not too many components, which is good as I'll be repeating it 16 times.
The THRU socket is actually the new IN, isn't it?




Being concerned about the skew issue (partly because I don't fully understand it yet -I'll look into it in more detail when I get the time) I tried to look up how a MIDI indicator LED is done in commercially available MIDI gear. The first one is from a Roland MKS-50 rack synthesizer:

I won't claim that I understand everything which is going on here, but following the IN signal I see it enters a microprocessor, and the LED is output from somewhere else in the same microprocessor.
I also came across a DIY project for adding MIDI to an ancient pre-MIDI Roland CR-68 drum machine which looks to work in the same way (only part of the schematic shown here, but relevant to what we're discussing):

This is the kind of setup I'd feel more at ease with since the actual MIDI IN path doesn't seem to be altered because of the activity LED, but I'm guessing a similar setup could be done if I was to go the PIC route you suggested a while back, where the PIC handles both the MIDI signal, and at a separate location also handles the LED. Am I understanding it correctly?

 

[KrisBlueNZ]

I'm not sure about the MIDI connector pin usage. Also, I don't know whether a MIDI cable connects 4-4 and 5-5, or maybe 4-5 and 5-4. And I don't know about pin 2, but I would expect the cable would connect the shield (if one is used) at both ends, because MIDI cables are reversible, and you want the screen to be connected to the 0V rail of the transmitter, and isolated (more or less) at the receiver; if the break was part of the cable, then there would be one end for the sender and the other end for the receiver, but the cables are reversible.

This is borne out by the schematic you posted. Both of the transmitting ports (THRU and OUT) connect pin 2 to the circuit's 0V rail, which is appropriate for the shield to be connected to, and the IN connector has pin 2 connected to the 0V rail through a 0.1 µF capacitor. I'm not sure if that's the best approach. Maybe you can check on the schematics for a few other synths.

If that schematic is right, the transmitting ports (THRU and OUT) have positive on pin 4 and negative on pin 5, which is what I thought was right, but the IN port has positive on pin 5 and negative on pin 4. I don't know why. It's possible that the schematic is wrong I guess. Or the wires cross over in the cable, perhaps.

I also notice that that design uses an optocoupler with a digital output, like the H11L1/MOC5007 I recommended.

The MIDI activity indicator is driven by the micro because it's easier to include the pulse lengthening logic in software. Also, if activity is determined after the data is received, it will only indicate activity if the MIDI data is valid, at least to some extent. Lastly, it's possible that the activity indicator only indicates activity for the MIDI channel(s) that the synth is actively receiving, and software needs to make that decision.

The schematic I posted in post #28 is a stand-alone MIDI activity monitor. I had not considered how it would integrate into your multiplexer circuit. Also I didn't think you wanted MIDI THRU outputs for the individual channels on your multiplexer.

No, I wouldn't say that the THRU connector is a "new IN" connector. It's an output only. In what way do you think it's an input?

That schematic for the MIDI input hack looks pretty standard. The "MIDI IN GND" signal, presumably from pin 2, is not connected to anything, compared to the MKS-50 schematic which has it connected to 0V through a 0.1 µF capacitor.

Yes, in the MKS-50 and the MIDI input hack, the microcontroller drives the activity indicator using some kind of timer-based logic. Having software control of the LED allows you to implement a smarter control algorithm such as a continuous steady rapid flashing if there is continuous data, which looks cool.

 

[TTL]

Detailed technical MIDI information seems lacking online but I did find the MIDI manufacturers organization electrical specs and "making your own MIDI cables" (confirming the findings in "How to wire a MIDI cable using DIN plugs")

• MIDI cables connect to the same pins (4-4 and 5-5).
  A shielded cable is used. The shielded wire goes between pins 2 and 2.
  Pins 1 and 3 aren't used.
  
• Pin 4 is signal +, pin 5 is signal -
• Pin 2 of MIDI IN sockets should NOT be attached to GND
• Pin 2 of MIDI OUT sockets should be attached to GND

So for your latest schematic I've removed the GND connection of the MIDI IN socket. The H11L1 Eagle component didn't have any pin 3 and I see from the datasheet that it's not connected to anything inside the IC either. I assume IC pins like these are still tied to GND out of consistency so as to not leave any potential logic levels "floating" as we discussed earlier.

The MIDI activity indicator is driven by the micro because it's easier to include the pulse lengthening logic in software. Also, if activity is determined after the data is received, it will only indicate activity if the MIDI data is valid, at least to some extent. Lastly, it's possible that the activity indicator only indicates activity for the MIDI channel(s) that the synth is actively receiving, and software needs to make that decision.

Will a circuit like that affect the MIDI signal less than the circuits we're working on, given that there's no THRU to pass the signal on?

The schematic I posted in post #28 is a stand-alone MIDI activity monitor. I had not considered how it would integrate into your multiplexer circuit. Also I didn't think you wanted MIDI THRU outputs for the individual channels on your multiplexer.

You're right; I don't need any MIDI THRU in that circuit. I just want to add a flashing LED for each of those 16 inputs, but I thought you had said earlier that in order to add the flashing LEDs you need to build a THRU circuit. The input selector schematic in post #11 is more or less completed, isn't it, with up/down buttons selecting the inputs, and reseting to input 1 when powered up as there's no memory?

(I did mention THRU circuitry at some stage, but I already have two 8x THRU circuit boards ready made which I intended to put inside the same 19" rack enclosure as the MIDI input selector. These have absolutely nothing to do with the input selector circuit though (except feeding off the same power supply), but just happen to be inside the same enclosure. Alas I did some measuring and found out I can't fit two rows of DIN-5 sockets on top of each other in a single 1U rack enclosure, so the MIDI THRU boards will have to go in another 1U enclosure I have).


Talking about stand-alone LED MIDI activity circuits, but getting slightly off-topic... I believe I mentioned that I would like to display MIDI activity not only for the MIDI input selector project we're discussing here, but also for a computer with MIDI IN and OUT ports which I'll be using as a MIDI sequencer. Since the MIDI timing is extremely steady on this particular computer (Atari ST from back in the late 80's/early 90s) I don't want to sacrifice that timing for the aesthetics/convenience of seeing MIDI activity, but if I could somehow get both I'd be a happy camper
Would I be using the schematic you just posted (and redrawn in Eagle as shown above (version 7)) connecting the computer's OUT to the LED circuit's IN, then having the LED circuit's THRU function as a new replacement for the computer's OUT? Likewise for the computer's IN?
Or would the computer's innards be better modified for this?
Here's a schematic showing the built-in MIDI ports of the Atari ST:

No, I wouldn't say that the THRU connector is a "new IN" connector. It's an output only. In what way do you think it's an input?

A silly description on my part What I meant was that as far as the input selector is concerned, each LED circuit's THRU will be seen as an IN (i.e. the OUT from one of the connected MIDI synths).

That schematic for the MIDI input hack looks pretty standard. The "MIDI IN GND" signal, presumably from pin 2, is not connected to anything, compared to the MKS-50 schematic which has it connected to 0V through a 0.1 µF capacitor.

This, according to the MIDI specs I found seems to mean Roland has it wrong because a MIDI IN socket shouldn't be connected to GND and the CR-68 MIDI interface circuit has it done right.

Yes, in the MKS-50 and the MIDI input hack, the microcontroller drives the activity indicator using some kind of timer-based logic. Having software control of the LED allows you to implement a smarter control algorithm such as a continuous steady rapid flashing if there is continuous data, which looks cool.

With the transistor based circuit the LED would then flash more correctly (i.e. faster when a lot of data is passed through, slower when less/smaller chunks of data flows)? Either works for me as I just want some sort of indication to as where the signal comes from (great for troubleshooting). I have some further thoughts/suggestions:

• Flash duration: could a trimmer-resistor be added so that I could adjust the flash duration to my liking? I would probably have to try it out a bit and find a compromise between noticing short flashes and long ones looking more like a constant light. You've pointed out that the "CT" capacitor takes care of the duration, so would it need to be replaced with a variable capacitor for this, or can a trimmer resistor be used in the circuit?
• I believe a single red LED for each MIDI input would look best (constant light indicating the selected input but flashing whenever a MIDI signal passes through). For the other inputs not currently selected their LEDs should be turned off, but flash whenever a MIDI signal is passed to that port. You said earlier that this could be confusing to look at (several inputs flashing all at once), but only the input selected is supposed to flash (when MIDI data is passed through). MIDI will be flowing through a port basically only when I play a MIDI keyboard/the sequencer is playing or MIDI Sysex data is dumped to the computer. As far as I know, several LEDs of the input selector would only flash if I accidently told a synth to dump it's Sysex data even though I hadn't selected its input all while dumping data from another synth with that input selected.
  Confusingly explained but I hope you understood my meaning. Would it be difficult to implement a single red LED for each input with both functions?
  A dual coloured LED would probably be easier to do but I find it more looking like a Christmas decoration than a serious piece of gear

 

[KrisBlueNZ]

Detailed technical MIDI information seems lacking online but I did find the MIDI manufacturers organization electrical specs and "making your own MIDI cables" (confirming the findings in "How to wire a MIDI cable using DIN plugs")

• MIDI cables connect to the same pins (4-4 and 5-5).
  A shielded cable is used. The shielded wire goes between pins 2 and 2.
  Pins 1 and 3 aren't used.
  
• Pin 4 is signal +, pin 5 is signal -
• Pin 2 of MIDI IN sockets should NOT be attached to GND
• Pin 2 of MIDI OUT sockets should be attached to GND

So for your latest schematic I've removed the GND connection of the MIDI IN socket.

OK, thanks for the information. Yes, disconnect pin 2 of the DIN socket on the receiver.

The H11L1 Eagle component didn't have any pin 3 and I see from the datasheet that it's not connected to anything inside the IC either.

I would say that the component symbol should include pin 3, but that's their decision to omit it. The IC obviously does have a pin 3, and yes it's not connected internally.

I assume IC pins like these are still tied to GND out of consistency so as to not leave any potential logic levels "floating" as we discussed earlier.

I connect pin 3 to pin 2 on my designs because it makes the PCB layout a bit easier and tidier. There is no other reason to connect it. It is not an input to anything. It is just not connected inside the IC.

Will a circuit like that affect the MIDI signal less than the circuits we're working on, given that there's no THRU to pass the signal on?

You mean a receiver with an activity indicator but no MIDI THRU connector? It will affect the signal because the skew is introduced by the optocoupler. The skew will affect the signal going into the multiplexer. But as I've said before, it's nothing to worry about. Any delay it introduces will be tiny - in the range of a few microseconds - and skew would have to accumulate through many cascaded MIDI receivers before it would cause problems with data reception.

You're right; I don't need any MIDI THRU in that circuit. I just want to add a flashing LED for each of those 16 inputs, but I thought you had said earlier that in order to add the flashing LEDs you need to build a THRU circuit.

No. You don't need to have a MIDI THRU output on the monitoring circuit if it just feeds the multiplexer.

The input selector schematic in post #11 is more or less completed, isn't it, with up/down buttons selecting the inputs, and reseting to input 1 when powered up as there's no memory?

Yes. You're going to use the MOSFET-based activity indicator circuit are you?

(I did mention THRU circuitry at some stage, but I already have two 8x THRU circuit boards ready made which I intended to put inside the same 19" rack enclosure as the MIDI input selector. These have absolutely nothing to do with the input selector circuit though (except feeding off the same power supply), but just happen to be inside the same enclosure.

Right. When you mentioned this other project, I must have assumed you wanted to talk about stand-alone MIDI activity monitoring circuits. These DO need a MIDI THRU connector because you can't feed a MIDI output into two inputs (i.e. the activity monitoring circuit AND the receiving device) so the activity monitor needs to provide a daisy-chain output to drive the receiving device.

Talking about stand-alone LED MIDI activity circuits, but getting slightly off-topic... I believe I mentioned that I would like to display MIDI activity not only for the MIDI input selector project we're discussing here, but also for a computer with MIDI IN and OUT ports which I'll be using as a MIDI sequencer. Since the MIDI timing is extremely steady on this particular computer (Atari ST from back in the late 80's/early 90s) I don't want to sacrifice that timing for the aesthetics/convenience of seeing MIDI activity, but if I could somehow get both I'd be a happy camper
Would I be using the schematic you just posted (and redrawn in Eagle as shown above (version 7)) connecting the computer's OUT to the LED circuit's IN, then having the LED circuit's THRU function as a new replacement for the computer's OUT? Likewise for the computer's IN? Or would the computer's innards be better modified for this? Here's a schematic showing the built-in MIDI ports of the Atari ST:

That's interesting. The computer already has a MIDI THRU feature! Pins 1 and 3 of the MIDI OUT connector retransmit what's received on the MIDI IN connector! You can easily add LED indications to the computer.

For the MIDI OUT indicator, connect a wire from the VCC end of R218 to the anode of an LED; connect a 330 ohm resistor to the cathode of the LED; connect another wire from the resistor to the other end of R218 (the end that connects to U210 pin 8).

For the MIDI IN indicator, repeat the above for R219 instead of R218.

The 330 ohm resistor will give you about 8 mA LED current; change it if necessary. You could use a piece of ribbon cable ripped down to four wires (or three wires, since VCC is common to both LEDs) from the board to the LEDs, to keep things tidy.

With the transistor based circuit the LED would then flash more correctly (i.e. faster when a lot of data is passed through, slower when less/smaller chunks of data flows)?

It depends on how you define "correctly". With the simple RC circuit (transistors or MOSFETs), the LED turns ON as soon as any MIDI activity is detected, and it turns OFF a certain amount of time after no MIDI activity is detected. If activity is continuous, or often enough that the timer never expires, the LED will stay ON constantly. The alternative requires some processing, which can be fairly simple (e.g. short burst of activity causes a long blink, but continuous activity causes a rapid flashing) or more complicated (e.g. flashing speed is proportional to the amount of data flowing).

Either works for me as I just want some sort of indication to as where the signal comes from (great for troubleshooting).

Well, you might as well use the MOSFET circuit. The only other advantage of a microcontroller-based solution is that it's probably more compact - a single 20-pin device can handle eight channels; LEDs and resistors are the only external components needed.

I have some further thoughts/suggestions:
Flash duration: could a trimmer-resistor be added so that I could adjust the flash duration to my liking? I would probably have to try it out a bit and find a compromise between noticing short flashes and long ones looking more like a constant light. You've pointed out that the "CT" capacitor takes care of the duration, so would it need to be replaced with a variable capacitor for this, or can a trimmer resistor be used in the circuit?

Yes, you can make the flash duration adjustable. In the circuit in post #26, change CT1 to 0.33 µF and change RT1 to a 1 megohm trimpot.

I changed Rc from 3k3 to 1k in post #28 and I recommend you make that change; it will improve the skew slightly. Connect the multiplexer input to pin 4 of the H11L1. I added R4, R7 and D2 (in post #28) to simplify the MIDI THRU circuit; they're not needed otherwise.

I believe a single red LED for each MIDI input would look best (constant light indicating the selected input but flashing whenever a MIDI signal passes through). For the other inputs not currently selected their LEDs should be turned off, but flash whenever a MIDI signal is passed to that port. You said earlier that this could be confusing to look at (several inputs flashing all at once), but only the input selected is supposed to flash (when MIDI data is passed through). MIDI will be flowing through a port basically only when I play a MIDI keyboard/the sequencer is playing or MIDI Sysex data is dumped to the computer. As far as I know, several LEDs of the input selector would only flash if I accidently told a synth to dump it's Sysex data even though I hadn't selected its input all while dumping data from another synth with that input selected.
Confusingly explained but I hope you understood my meaning. Would it be difficult to implement a single red LED for each input with both functions? A dual coloured LED would probably be easier to do but I find it more looking like a Christmas decoration than a serious piece of gear

Yes, I understand you exactly. I'm going to have to think about the best way to do what you want. One fairly simple idea comes to mind, requiring another CD4067 and one resistor, using bicolour LEDs, that would give you a nice behaviour: the selected input would be normally green, and would blink OFF with received MIDI data; other inputs would be normally OFF but would blink red with MIDI data. That seems like a very appropriate paradigm to me; what do you think?

 

[TTL]

I agree that tying pin 3 of the H11L1 optoisolator looks tidier. I'll keep it in mind for when I design the actual board and physically connect the pins/traces.

You mean a receiver with an activity indicator but no MIDI THRU connector? It will affect the signal because the skew is introduced by the optocoupler. The skew will affect the signal going into the multiplexer. But as I've said before, it's nothing to worry about. Any delay it introduces will be tiny - in the range of a few microseconds - and skew would have to accumulate through many cascaded MIDI receivers before it would cause problems with data reception.

Sorry if this is a silly question, but what do you mean by a "receiver"? A receiver as in "a circuit which receives a MIDI signal", for instance the MUX-based input selector circuit, a synthesizer or computer's MIDI IN?

No. You don't need to have a MIDI THRU output on the monitoring circuit if it just feeds the multiplexer.

I think I've been misunderstanding all along thinking the LED circuit was a sort of stand-alone module with a new output (THRU) which in turn was to be attached to one of the input selector's MIDI IN ports. Am I understanding correctly that this is NOT the case and it's just an extension/add-on to the rest of the circuit, or are you just saying that the DIN-5 connector component can obviously be omitted as the circuit can be connected directly to the MUX-based input selector?

Never mind: a picture (or schematic in this case) says more than a thousand words, so here's an attempt to incorporate the LED circuit to the input selector (with your most recent suggestions for changes):

PS: I've noticed that images don't display at full size even though I choose "full size" for image attachements when posting here. How do I get images to display at full size?

Yes. You're going to use the MOSFET-based activity indicator circuit are you?

That's correct. Have you designed two different LED activity circuits, or is there just one which has evolved, starting in post #21, post #26 and post #28 with several suggestions for improvement along the way?
I'm confused because you're referring to both the #26 and #28 schematics when I asked about adding a trimmer resistor for the flash duration:

Yes, you can make the flash duration adjustable. In the circuit in post #26, change CT1 to 0.33 µF and change RT1 to a 1 megohm trimpot.

I changed Rc from 3k3 to 1k in post #28 and I recommend you make that change; it will improve the skew slightly. Connect the multiplexer input to pin 4 of the H11L1. I added R4, R7 and D2 (in post #28) to simplify the MIDI THRU circuit; they're not needed otherwise.

Oops! I must have missed that Rc resistor change.
I've now made the change (see version 6 of the schematic attached), but I've used the circuit you posted in #28 (assuming it was an improved version of the first circuit, posted in #26). I've also attached pin 4 of the H11L1 opto-isolator to the + pin of MIDI IN port 1 of the MUX-based input selector circuit.

Or should I now (since there's already an opto-isolator in the LED circuit) remove the 6N138 (IC1 of the input selector schematic) and all its associated components (R1, D1, C1 and R2), and instead feed pin 4 of the H11L1 opto-isolator directly to pin 9 (the X0 input) of the 4067 MUX?
I've also removed R7 and D2 as suggested, but by removing R4 I will end up with a FET (Q3/BSS84) not being attached to anything. Comparing with your schematic in post #26 however I think I may have solved that puzzle.

Right. When you mentioned this other project, I must have assumed you wanted to talk about stand-alone MIDI activity monitoring circuits. These DO need a MIDI THRU connector because you can't feed a MIDI output into two inputs (i.e. the activity monitoring circuit AND the receiving device) so the activity monitor needs to provide a daisy-chain output to drive the receiving device.

By "stand alone MIDI activity monitoring circuits" do you mean an LED circuit simply attached to the end of a MIDI cable (for troubleshooting purposes etc.)? In that case I completely understand why a THRU connector has to be added, otherwise there's no way to attach a MIDI synth etc. to the end of that cable. I have made a simple "MIDI tester" circuit in the past which simply consisted of a LED and a resistor connected to pins 4 and 5 inside a 5-pin DIN plug (so I could plug it right into a MIDI OUT of a synth and see if MIDI data came out of it). Is this the kind of scenario you're referring to?

That's interesting. The computer already has a MIDI THRU feature! Pins 1 and 3 of the MIDI OUT connector retransmit what's received on the MIDI IN connector! You can easily add LED indications to the computer.

Yes, a very interesting solution by Atari to include a THRU inside the OUT port pins 1 and 3. This surely isn't standard procedure and it could cause problems with non-standard cables (pins 1 and 3 have sometimes found to be shorted when purchased ready made), but I've found good use for this feature in the past:
if I attach my MIDI keyboard's OUT to the computer's IN, then connect the computer's OUT to a synthesizer module's IN I can play that module whenever the computer is turned on and a MIDI sequencer program is running (because the software is routing a "soft MIDI THRU"). However, when the computer is physically turned off I have to physically re-attach the keyboard's OUT directly to the synth module's IN.
By using a simple 2-pole switch I was able to re-route the signal without re-attaching the cable every time (I actually incorporated that switch into my ancient 4-way MIDI input selector (using a two-pole rotary switch) which is what I'm expanding upon here, with more inputs and electronic control).

The Atari ST schematic I found was pretty badly scanned so I drew it again, in Eagle and incorporated the additions you suggested:

For the MIDI OUT indicator, connect a wire from the VCC end of R218 to the anode of an LED; connect a 330 ohm resistor to the cathode of the LED; connect another wire from the resistor to the other end of R218 (the end that connects to U210 pin 8).

For the MIDI IN indicator, repeat the above for R219 instead of R218.

Should that be "connect another wire from the resistor to the other end of R218 (the end that connects to U210 pin 6)" as the other end of R218 attaches to pin 6 of U210C/pin 9 of U210D. Or did you mean to U210D pin 8? I could only find a poorly scanned schematic for this.

Why can we have such a simple solution (where we just "tap into" the existing MIDI signal lines as I first assumed we could do, without affecting the actual signal path) in the computer when we have to design a circuit for the MIDI input selector in order to do the same thing (flash LEDs to indicate MIDI data flow). Is it because the computer already has a MIDI THRU circuit (built into the MIDI OUT connector) or because we could do it this way with the input selector circuit as well, but not have the pulse stretching ability we now have?

It depends on how you define "correctly". With the simple RC circuit (transistors or MOSFETs), the LED turns ON as soon as any MIDI activity is detected, and it turns OFF a certain amount of time after no MIDI activity is detected. If activity is continuous, or often enough that the timer never expires, the LED will stay ON constantly. The alternative requires some processing, which can be fairly simple (e.g. short burst of activity causes a long blink, but continuous activity causes a rapid flashing) or more complicated (e.g. flashing speed is proportional to the amount of data flowing).

I'm more than happy with it just flashing a bit when there's signal flowing through, so the MOSFET solution will be just fine.
By "more correctly" I just meant if the LED would flash according to the data flow, which you've confirmed it will, unlike the microprocessor solution you've also described which is fancier but dependant on some logic circuitry which translates/analyzes the signal in order to give different flashes according to what it finds.

Yes, I understand you exactly. I'm going to have to think about the best way to do what you want. One fairly simple idea comes to mind, requiring another CD4067 and one resistor, using bicolour LEDs, that would give you a nice behaviour: the selected input would be normally green, and would blink OFF with received MIDI data; other inputs would be normally OFF but would blink red with MIDI data. That seems like a very appropriate paradigm to me; what do you think?

Yes, it does indeed seem appropriate, but I would prefer just the one colour (if it's not too complicated). Are we looking at yet another MUX which switches between a "Input port selected with constant power to the appropriate LED" circuit and another "LED flashing when MIDI signal is detected" circuit?

 

[KrisBlueNZ]

Sorry if this is a silly question, but what do you mean by a "receiver"? A receiver as in "a circuit which receives a MIDI signal", for instance the MUX-based input selector circuit, a synthesizer or computer's MIDI IN?

Yes.


A "receiver" is an optocoupler and related components. It provides electrical isolation, which is needed to prevent earth loops.

Every time a MIDI signal is passed from one piece of equipment to another, it must be transmitted on a pair of wires, normally using the DIN-5-180 connectors, from a transmitter at the sending end (that drives a MIDI OUT or MIDI THRU connector) to a receiver at the receiving end (that gets the signal from a MIDI IN connector).

A standard MIDI transmitter uses a +5V supply, a transistor, and two 220 ohm resistors. It is not isolated from the transmitting equipment.

A receiver consists of a 220 ohm resistor, an optocoupler, and usually a protection diode, and some components on the output side of the optocoupler. Receivers must be electrically isolated, which is why an optocoupler is used.

The MIDI receiver is only needed because of the isolation requirement. Once data has been received by the optocoupler, it is now standard digital data with a 0V/5V swing relative to the circuit's 0V rail. It can be fed to an activity indicator, and/or multiplexer, and/or a MIDI transmitter, as you require, with no isolation, and no optocouplers.

I think I've been misunderstanding all along thinking the LED circuit was a sort of stand-alone module with a new output (THRU) which in turn was to be attached to one of the input selector's MIDI IN ports. Am I understanding correctly that this is NOT the case and it's just an extension/add-on to the rest of the circuit, or are you just saying that the DIN-5 connector component can obviously be omitted as the circuit can be connected directly to the MUX-based input selector?

Yes, it's just an add-on, and the MIDI THRU connector can be omitted because the receiver can be connected straight through to the mux.

Never mind: a picture (or schematic in this case) says more than a thousand words, so here's an attempt to incorporate the LED circuit to the input selector (with your most recent suggestions for changes):

You don't need the second optocoupler in that circuit.

The H11L1 is the MIDI receiver for the mux. The received MIDI data on pin 4 of the H11L1 is a standard logic signal with a 0V/+5V swing relative to the circuit's 0V rail. It can feed both the activity indicator circuit, and the mux input.

That's correct. Have you designed two different LED activity circuits, or is there just one which has evolved, starting in post #21, post #26 and post #28 with several suggestions for improvement along the way? I'm confused because you're referring to both the #26 and #28 schematics when I asked about adding a trimmer resistor for the flash duration

The schematic in post #26 is what I recommend as a general-purpose activity indicator, except that (a) the optocoupler should be an H11L1, not a 4N26 (I only used the 4N26 because the circuit simulation program, LTSpice, didn't have anything better), and (b) RC in that diagram should be 1k instead of 3k3 as shown. CT1 and RT1 can be changed to 0.33 µF and a 1M trimpot to make the blink duration adjustable.

The schematic in post #28 is changed slightly to simplify driving the MIDI THRU output. It also has RC changed to 1k (it's marked R3 on that circuit) which is an improvement made possible by the use of the H11L1. I drew up that circuit because I thought you wanted a design for a stand-alone MIDI activity monitor. Since you don't, you can ignore that circuit.

I've now made the change (see version 6 of the schematic attached), but I've used the circuit you posted in #28 (assuming it was an improved version of the first circuit, posted in #26). I've also attached pin 4 of the H11L1 opto-isolator to the + pin of MIDI IN port 1 of the MUX-based input selector circuit.

Or should I now (since there's already an opto-isolator in the LED circuit) remove the 6N138 (IC1 of the input selector schematic) and all its associated components (R1, D1, C1 and R2), and instead feed pin 4 of the H11L1 opto-isolator directly to pin 9 (the X0 input) of the 4067 MUX?

Right. You need to remove that second optocoupler. H11L1 pin 4 can connect straight to the mux input.

The input circuit and activity indicator look good.

I've also removed R7 and D2 as suggested, but by removing R4 I will end up with a FET (Q3/BSS84) not being attached to anything. Comparing with your schematic in post #26 however I think I may have solved that puzzle.

Not sure what you mean. But the MIDI receiver and activity indicator are right in circuit version 6.

By "stand alone MIDI activity monitoring circuits" do you mean an LED circuit simply attached to the end of a MIDI cable (for troubleshooting purposes etc.)? In that case I completely understand why a THRU connector has to be added, otherwise there's no way to attach a MIDI synth etc. to the end of that cable. I have made a simple "MIDI tester" circuit in the past which simply consisted of a LED and a resistor connected to pins 4 and 5 inside a 5-pin DIN plug (so I could plug it right into a MIDI OUT of a synth and see if MIDI data came out of it). Is this the kind of scenario you're referring to?

Yes, you've got it. A stand-alone activity indicator needs to have a MIDI receiver, an activity indicator circuit, and a MIDI transmitter driving a connector marked MIDI THRU, so that you can insert the activity indicator between a MIDI transmitter and a MIDI receiver. It needs the MIDI THRU output because you cannot take the wires from a single MIDI transmitter and connect it to two receivers - at least, not if you want to comply with the MIDI standard.

Yes, a very interesting solution by Atari to include a THRU inside the OUT port pins 1 and 3. This surely isn't standard procedure and it could cause problems with non-standard cables (pins 1 and 3 have sometimes found to be shorted when purchased ready made),

No doubt it's non-standard, and I expect it's also non-standard for the cable to short pins 1 and 3. But that won't cause any damage because the current is limited by the 220 ohm resistors in the transmitter.

but I've found good use for this feature in the past: if I attach my MIDI keyboard's OUT to the computer's IN, then connect the computer's OUT to a synthesizer module's IN I can play that module whenever the computer is turned on and a MIDI sequencer program is running (because the software is routing a "soft MIDI THRU"). However, when the computer is physically turned off I have to physically re-attach the keyboard's OUT directly to the synth module's IN.
By using a simple 2-pole switch I was able to re-route the signal without re-attaching the cable every time (I actually incorporated that switch into my ancient 4-way MIDI input selector (using a two-pole rotary switch) which is what I'm expanding upon here, with more inputs and electronic control).

That's cool

The Atari ST schematic I found was pretty badly scanned so I drew it again, in Eagle and incorporated the additions you suggested:

You've drawn exactly what I described, but I got it wrong. You need to connect the LEDs to the OUTPUTS of U210D and U210E, not the inputs. Sorry!

Why can we have such a simple solution (where we just "tap into" the existing MIDI signal lines as I first assumed we could do, without affecting the actual signal path) in the computer when we have to design a circuit for the MIDI input selector in order to do the same thing (flash LEDs to indicate MIDI data flow). Is it because the computer already has a MIDI THRU circuit (built into the MIDI OUT connector) or because we could do it this way with the input selector circuit as well, but not have the pulse stretching ability we now have?

Yes, the MIDI THRU circuit in the computer makes it easy to connect the "MIDI RX" LED. Yes, that simple hack has no pulse stretching feature.

I'm more than happy with it just flashing a bit when there's signal flowing through, so the MOSFET solution will be just fine.

You mean "the LED solution"? OK. If you change your mind, you could add pulse stretching using two copies of the MOSFET-based circuit, if you want it. Otherwise it might be hard to see very short bursts of activity on the LEDs.

By "more correctly" I just meant if the LED would flash according to the data flow, which you've confirmed it will, unlike the microprocessor solution you've also described which is fancier but dependant on some logic circuitry which translates/analyzes the signal in order to give different flashes according to what it finds.

OK.

Yes, it does indeed seem appropriate, but I would prefer just the one colour (if it's not too complicated).

I'll think about it.

Are we looking at yet another MUX which switches between a "Input port selected with constant power to the appropriate LED" circuit and another "LED flashing when MIDI signal is detected" circuit?

At present, you have one CD4067 which carries the MIDI data signal from the selected input circuit to the output. It doesn't have any way to tell the input circuits which input is selected. That's what the second CD4067 will be needed for. Each input circuit needs a true/false signal that tells it whether it is selected, so it knows how to drive its LED.

 

[KrisBlueNZ]

OK, here's what I suggest for activity monitoring with a single indicator that's ON and blinks OFF for activity on the selected channel, and OFF and blinks ON for activity on the un-selected channels.



The MIDI receiver is standard and feeds MIDI data from H11L1 pin 4 to the 4067 data mux.

Q1, CT and RT form the pulse stretcher. Its output goes straight into U?A, one of four exclusive-OR gates in a CD4070BE quad exclusive-OR gate IC.

An exclusive-OR gate can be considered a "programmable inverter" because one of its inputs (pin 1 in this case) determines whether it inverts the signal on its other input, or passes it through to the output without inverting it. This handy capability is just a byproduct of its truth table.

Its output feeds a second MOSFET that provides buffering to drive the LED. R5 determines the LED current.

The "selected/unselected" input to the circuit needs to come from a second CD4067 that I've called the "selection mux", whose A~D inputs are driven in parallel with the data mux. Its "common" pin, pin 1, must be connected to 0V, so the mux switch for the selected input will pull the selected/unselected signal for the selected input down to 0V.

Inputs that aren't selected will not be switched to 0V and R4 will pull the selected/unselected input high.

So you will need a second CD4067 to provide these selected/unselected signals, and four CD4070BE ICs (16 inputs, 4 gates per IC).

I hope this makes sense!

 

[TTL]

Wow! That's fantastic Thanks Kris!
I'll look into all of this soon and get back to you.

 

[TTL]

OK, I'm back and think I've finally understood a few things along the way
First, a few details that need clearing up:

The Atari ST MIDI activity LED circuit
You said I had done it right by attaching the two LEDs to the outputs of U210D and U210E, but I attached them to the inputs, didn't I? Correct me if I'm mistaken, but shouldn't it rather be like this?:

I'm more than happy with it just flashing a bit when there's signal flowing through, so the MOSFET solution will be just fine.

You mean "the LED solution"? OK. If you change your mind, you could add pulse stretching using two copies of the MOSFET-based circuit, if you want it. Otherwise it might be hard to see very short bursts of activity on the LEDs.

Huh? You mean the circuit with just the two LEDs/two resistors (being the "LED solution" as shown above)? Yes, it works and more importantly it doesn't seem to tamper with the existing MIDI IN or OUT signals, but rather just "taps into" the signal already there. You may however be right about this not being very easy to see and one of the MOSFET based pulse-stretchers could improve on that.

Alas I'm still a little unclear about the difference between the "standalone" and the "THRU" versions of the MOSFET circuit.... read on.

Two MOSFET circuits -differences?
If I haven't confused things further, here are the two final versions of the MOSFET based circuits. First the one I believe you're referring to as "standalone":




By "Standalone", is this a circuit which would be attached to the end of a MIDI OUT cable (e.g. from a MIDI keyboard) and would be used as an analysis tool? This would then be a pulse stretched version of the "MIDI detector" I built years ago (an LED with a resistor, attached to pins 4 and 5 inside a 5-pin DIN connector with the LED sticking out from where the cable usually goes in) to see if a device would be sending any MIDI signal at all.

Next, the "THRU" version:



From my understanding, this is the circuit which needs to be used whenever the signal should continue moving on to somewhere else (unlike the "standalone" MIDI detector above), hence the inclusion of a "MIDI OUT" connector which is technically speaking a THRU, right?
So what we do is cut the connection between the OUT (e.g. a sequencer, acting as the "sender") and the receiving (e.g. a synth module, acting appropriately as a "receiver"), then insert the LED circuit in between, as a bridge?


I don't fully understand how this relates to the Atari ST circuit, and how I can simply "tap into" the existing circuit there with just the two LEDs/resistors (while with the MIDI input selector I'm building I need to build THRU ports as well)....
Starting with the Atari ST "IN" port activity LED I think I can understand how that makes sense: because the computer was already designed with a MIDI THRU circuit which is passed on to the computer's OUT connector using pins 1 and 3. So this is why we don't need any more advanced circuitry for flashing a MIDI activity LED.
But how about the computer's OUT port? Why can we just tap into the circuitry already there without putting our "THRU" LED circuit in between the computer's OUT and whatever's going to be connected to it? (for practical reasons, the "receiver" will be a new OUT port in the form of a DIN-5 connector allowing for anything to be attached as the receiver).

Input selector with dual function LEDs
Having gotten the above out of the way, here's a new schematic of the input selector, this time with the new input ports (dual function LEDs) and the added 4067 for lighting up the active input port's LED. Does it look right?

 

[KrisBlueNZ]

You said I had done it right by attaching the two LEDs to the outputs of U210D and U210E, but I attached them to the inputs, didn't I? Correct me if I'm mistaken, but shouldn't it rather be like this?:

Yes, that's right. The LEDs (with current limiting resistors) should be connected between VCC and the OUTPUTS of gates D and E. As I said in post #34:

You've drawn exactly what I described, but I got it wrong. You need to connect the LEDs to the OUTPUTS of U210D and U210E, not the inputs. Sorry!

Huh? You mean the circuit with just the two LEDs/two resistors (being the "LED solution" as shown above)? Yes, it works and more importantly it doesn't seem to tamper with the existing MIDI IN or OUT signals, but rather just "taps into" the signal already there. You may however be right about this not being very easy to see and one of the MOSFET based pulse-stretchers could improve on that.

Exactly.

By "Standalone", is this a circuit which would be attached to the end of a MIDI OUT cable (e.g. from a MIDI keyboard) and would be used as an analysis tool? This would then be a pulse stretched version of the "MIDI detector" I built years ago (an LED with a resistor, attached to pins 4 and 5 inside a 5-pin DIN connector with the LED sticking out from where the cable usually goes in) to see if a device would be sending any MIDI signal at all.

What I mean by a "standalone MIDI activity monitor" is a circuit that performs only that function. It has a MIDI input, which goes through an optocoupler, a MIDI THRU output, which retransmits the received data, and a pulse stretcher with LED indicator for indicating MIDI activity. It doesn't have any other functions such as multiplexing, or any MIDI signal analysis. It could be powered from a battery. Its only function is MIDI activity monitoring, but in order to be useful, it needs to have a MIDI THRU output, so it could be inserted into a MIDI data connection. That's what I mean by a "standalone MIDI activity monitor".

I don't fully understand how this relates to the Atari ST circuit, and how I can simply "tap into" the existing circuit there with just the two LEDs/resistors (while with the MIDI input selector I'm building I need to build THRU ports as well)....

It's because you have direct access to the logic-level signals. You can connect directly to the outputs of the drivers (U210D and U210E). These signals swing fully (well, almost) between VCC and GND and are able to drive a few milliamps into a monitoring LED as well as driving the MIDI outputs.

The MIDI outputs are not like this. There are two 220 ohm resistors - one between VCC and the positive MIDI output, and one between the driving gate and the MIDI negative output. There is a third 220 ohm resistor in the receiver. This is how MIDI is supposed to work, and it does work properly, provided that one output connects to one receiver. You can't (reliably) drive two receivers from one output. But if you can get at the signal before it goes through the resistors, you can add a monitoring LED without (significantly) affecting the transmitted MIDI data.

Having gotten the above out of the way, here's a new schematic of the input selector, this time with the new input ports (dual function LEDs) and the added 4067 for lighting up the active input port's LED. Does it look right?

That's spot on in every detail (apart from the missing junction dot at the top of the 33k resistor from IC1A's pin 1 input).

You can replace R13 with a short circuit.

Your debounce circuits need some component values. C7 and C8 can be 100 nF; R17 and R19 can be 10k; R16 and R18 can be 33k; D5 and D6 aren't needed IMO.

 

[TTL]

It's because you have direct access to the logic-level signals. You can connect directly to the outputs of the drivers (U210D and U210E). These signals swing fully (well, almost) between VCC and GND and are able to drive a few milliamps into a monitoring LED as well as driving the MIDI outputs.

The MIDI outputs are not like this. There are two 220 ohm resistors - one between VCC and the positive MIDI output, and one between the driving gate and the MIDI negative output. There is a third 220 ohm resistor in the receiver. This is how MIDI is supposed to work, and it does work properly, provided that one output connects to one receiver. You can't (reliably) drive two receivers from one output. But if you can get at the signal before it goes through the resistors, you can add a monitoring LED without (significantly) affecting the transmitted MIDI data.

Aha! I think I understand (see red quote above). So because the Atari ST OUT also has a THRU available and I can access the signal BEFORE the resistors I can make this work. I also have some other MIDI OUT and IN ports from the same computer, but they're add-on devices (connected through a cartridge expansion port) and I very much doubt they have a built-in THRU port as with the original Atari OUT. So in that case I'd have to use the "THRU" version of the LED circuit?
By the way, here's the Atari ST MIDI ports with the standalone LED pulse stretchers. I've attached them to the same connection points as the LEDs used before:

That's spot on in every detail (apart from the missing junction dot at the top of the 33k resistor from IC1A's pin 1 input).

You can replace R13 with a short circuit.

Your debounce circuits need some component values. C7 and C8 can be 100 nF; R17 and R19 can be 10k; R16 and R18 can be 33k; D5 and D6 aren't needed IMO.

OK, I've added the missing junction to the 33K resistor, replaced R13 with a wire (short circuit) and added the values for the debounce circuits. If I've done it correctly I guess this just about concludes the whole project and I can go ahead with the contruction?

 

[KrisBlueNZ]

Aha! I think I understand (see red quote above).

Yes, that's the important factor.

So because the Atari ST OUT also has a THRU available and I can access the signal BEFORE the resistors I can make this work. I also have some other MIDI OUT and IN ports from the same computer, but they're add-on devices (connected through a cartridge expansion port) and I very much doubt they have a built-in THRU port as with the original Atari OUT. So in that case I'd have to use the "THRU" version of the LED circuit?

I'm sorry, I don't understand the question. Can you post schematics of the circuits involved?

By the way, here's the Atari ST MIDI ports with the standalone LED pulse stretchers. I've attached them to the same connection points as the LEDs used before

You don't need optocouplers unless you need isolation between the 0V rails of the two circuits. Here's how to use the pulse stretchers without isolation, assuming they are powered from the Atari's +5V rail. I've shown the mod for the bottom one; repeat it for the top one.

OK, I've added the missing junction to the 33K resistor, replaced R13 with a wire (short circuit) and added the values for the debounce circuits. If I've done it correctly I guess this just about concludes the whole project and I can go ahead with the contruction?[/QUOTE]
That looks right to me. There's one change I should at least suggest to you. With the present circuit, if you turn the RT1 trimpot fully anticlockwise, i.e. shortest possible LED blink, it is possible that Q1 could be damaged because there is no resistance to limit the current flowing through it. To avoid this potential problem you can add a small resistance, e.g. 1k, in series with RT1. Drag RT1 down closer to the 0V rail and break the wire from the top end (it's marked "3") of RT1 to the rest of the circuit (Q1 drain, CT1, and the 4070 input) and insert a 1k resistor in the break. That will protect Q1 if the trimpot is ever turned fully anticlockwise.

Are you going to prototype the circuit on a breadboard first? Just wondering.