A real MIDI hub

[BertKoor]

First merge then split.
this site used to have all that and morehttp://www.midisolutions.com/applicat.htm

[tsouni]

First merge then split.
this site used to have all that and morehttp://www.midisolutions.com/applicat.htm

First this: http://www.thomann.de/en/midi_solutions ... _merge.htm
.. and then this: http://www.thomann.de/en/midi_solutions_quadra_thru.htm

Could be a solution for 154 euros. What about midi clock, would it get a feedback loop? Does anyone have experience on this?

[mkdr]

I am thinking in buying this: http://www.esi-audio.com/products/m8uxl/
It's much cheaper than the MOTU MIDI Interfaces. However, it seems hard to find now, and I have no feedback.

The ESI M8U XL is the best midi interface i have ever come across. I've had plenty of 1, 2, 4 and 8 port devices over the years. Serial port, ISA, PCI or Usb. Nothing has been as stable and reliable as the ESI. Nothing. The drivers are also excellent, with multiclient support and physics defying low latency and low jitter. I can't recommend anything more than this beast. It's such a shame they don't make more of them. Might be hard to find these days. I bought mine from Thomann some years ago.

[Jim Y]

Another obsolete candidate might be the Roland UM880 8x8 patchbay.

So little on the market now, and that's surprising considering what a PITA patching multiple USB Midi ports with a host PC is, so a niche for someone to fill.

[T-CM11]

Another obsolete candidate might be the Roland UM880 8x8 patchbay.

Expensive and hard to find.
I wouldn't recommend them to anybody unless they're looking for a COMBINED midi interface + patchbay with front panel programmability.
Patchbay only; Roland A880 (essentially the patchbay part of the UM880): cheap and easy to find
Midi interface only; ESI M8U or MOTU Midi Express 128

[aMUSEd]

I am thinking in buying this: http://www.esi-audio.com/products/m8uxl/
It's much cheaper than the MOTU MIDI Interfaces. However, it seems hard to find now, and I have no feedback.

The ESI M8U XL is the best midi interface i have ever come across. I've had plenty of 1, 2, 4 and 8 port devices over the years. Serial port, ISA, PCI or Usb. Nothing has been as stable and reliable as the ESI. Nothing. The drivers are also excellent, with multiclient support and physics defying low latency and low jitter. I can't recommend anything more than this beast. It's such a shame they don't make more of them. Might be hard to find these days. I bought mine from Thomann some years ago.

The smaller version seems still to be available

http://www.thomann.de/gb/esi_m4u_xt.htm ... 8decec877c

[crimsonwarlock]

Another obsolete candidate might be the Roland UM880 8x8 patchbay.

I still have (and use) two Roland A-880 MIDI patchbays in my studio:



It seems you can pick one up at eBay for around 100 bucks.

So little on the market now, and that's surprising considering what a PITA patching multiple USB Midi ports with a host PC is, so a niche for someone to fill.

I actually want to go the other way, getting rid of the patchbays and do all MIDI routing ITB. I have my eye on a Motu Midi Express 128 to replace the Rolands.

[mkdr]

I am thinking in buying this: http://www.esi-audio.com/products/m8uxl/
It's much cheaper than the MOTU MIDI Interfaces. However, it seems hard to find now, and I have no feedback.

The ESI M8U XL is the best midi interface i have ever come across. I've had plenty of 1, 2, 4 and 8 port devices over the years. Serial port, ISA, PCI or Usb. Nothing has been as stable and reliable as the ESI. Nothing. The drivers are also excellent, with multiclient support and physics defying low latency and low jitter. I can't recommend anything more than this beast. It's such a shame they don't make more of them. Might be hard to find these days. I bought mine from Thomann some years ago.

The smaller version seems still to be available

http://www.thomann.de/gb/esi_m4u_xt.htm ... 8decec877c

I actually found the M8UXL too. But not from the big vendors. This is from Finland.
http://www.dlxmusic.fi/Product/product.aspx?id=399433
189€, decent price for this unit.

[mkdr]

I actually want to go the other way, getting rid of the patchbays and do all MIDI routing ITB. I have my eye on a Motu Midi Express 128 to replace the Rolands.

I've heard horror stories of Motu reliability and drivers. Put me off from buying one myself when i was searching for an interface. Would love to see if anyone would have any latency of jitter info on them.

[tsouni]

Hi! Progress report!

I have received the prototype PCB's and I have got some basic MIDI routing working. Now the biggest problem is what should I call it. I'm thinking of name "Dave", any better suggestions?

The basic idea in short: four separate midi in's, four separate midi out's. What comes to one input, goes automatically to other four midi outs. Exception is midi sync which is allowed only from one port. All midi traffic is processed at microcontroller so there shouldn't be any broken messages.

I haven't been thinking of making a product of this, but surely it would be under 100 dollars, without casing or power (USB). Would there be any interest, what do you think?

Picture of prototype below, just two in's and out's connected.

[tsouni]

All four ports are working fine! Now I can finally route things automatically by just plugging the devices and get the midi clock spreaded to all devices.

However I found and interesting problem. I don't know if it's in standard or what but my Juno-G may sometimes "shorten" the MIDI-commands by leaving the command byte out, so it's some kind of "repeated" or "continous" command mode. This is totally OK but for a midi HUB it causes some headache. I have a solution already but it's so teasing problem that I want to let it boil for a moment in my head

I encountered this problem when working with Juno-G midi some years ago, but I haven't really found any references to it. Anyone aware of this?

[JCJR]

That is a very nicely made proto board. Back when I was hardware hacking my boards were ugly enough to make a freight train take a dirt road, even though they generally worked ok and seemed long term reliable.

Your midi merging problem may be of two kinds that come immediately to mind. Apologies if you already know all about both of these and it is something else entirely.

1. Do you know about running status? That is a bog standard part of the spec and used by most devices. Status bytes are only transmitted when the kind of message changes. For instance if you transmit a 5 note chord on channel 3, hold it, then release the keys.

Many devices send velocity of zero to indicate note off. So if nothing else is going on with that controller, it would send a note on status channel 3, 0x92. Then send 10 bytes of data, note number and velocity pairs for the 5 notes. And then when you release the chord, if the controller sends velocity zero for note off, it might send 10 more bytes to turn off the chord, without sending another status byte. One status byte followed by 20 data bytes, speeding up midi transmission a little by deleting un-needed redundant status bytes.

If the controller sends note-off messages, then it would be note-on status followed by 10 data bytes, then note-off status followed by 10 data bytes.

2. Some of the early roland keyboards would send an all notes off message every time all keys get released. IMO it is best to filter out all notes off messages in a merger, just ignore them if they come in. And usually filter them from the input record-thru of software sequencers. Though the message might be useful to transmit FROM a sequencer sometimes.

3. There is also an active sensing message some controllers transmit in hopes of preventing stuck notes if someone trips over a midi cable or whatnot. IMO, active sensing should also be filtered out, ignored, almost without execption.

[tsouni]

That is a very nicely made proto board. Back when I was hardware hacking my boards were ugly enough to make a freight train take a dirt road, even though they generally worked ok and seemed long term reliable.

Thank you! For even for prototypes I will order ready made PCB with all components at the board. It's so much nicer to work that way. I've had too many air-wire-prototypes

Your midi merging problem may be of two kinds that come immediately to mind. Apologies if you already know all about both of these and it is something else entirely.

1. Do you know about running status? That is a bog standard part of the spec and used by most devices. Status bytes are only transmitted when the kind of message changes. For instance if you transmit a 5 note chord on channel 3, hold it, then release the keys.

Aha! This is what I've been experiencing. Just didn't know the correct name, now I know. And that's how I have been understood how it works (by staring at midi commands and try to understand what is going on).

2. Some of the early roland keyboards would send an all notes off message every time all keys get released. IMO it is best to filter out all notes off messages in a merger, just ignore them if they come in. And usually filter them from this input record-thru of software sequencers. Though the message might be useful to transmit FROM a sequencer sometimes.

3. There is also an active sensing message some controllers transmit in hopes of preventing stuck notes if someone trips over a midi cable or whatnot. IMO, active sensing should also be filtered out, gnored, almost without execption.

Are these early rolands still sending note-off (or note-on-velocity-zero) plus this all notes off message? Then it could be filtered out, otherwise I think it would cause problems.

For active sensing I have to check what it's all about. Surely I can do a filtering for it, but I hope it doesn't cause problems in the future.

Thinking that it's a thin line what you can walk, eventough the MIDI-standard is just simple and great. And still alive

Today I routed MIDI in following way:
- Analog Four Midi sync out -> to my hub input
- My hub output -> Juno-G input
- Juno-G output -> to my hub input
- My hub input -> Analog Four midi in

This way I got MIDI sync from Analog Four to Juno-G (it has a sequencer,arpegiator too) and I could still play Analog Four from Juno-G's keyboard.

[JCJR]

The earlier roland keyboards that sent gratuitous all notes off, as far as I know they send individual on and off messages fine and the all notes off can be safely filtered always. For instance, if you start playing a bunch of overlapping notes, two fisted piano playing but after a few beats or bars, all the fingers are briefly off the keyboard, no keys pressed. Every time that would happen on the affected models, it would send an all notes off command.

The all notes off command plays hob with merging of tracks in a software sequencer, or for instance maybe you recorded three different tracks all on the same channel. The nasty merged all notes off events during playback would make an awful mess of the merged tracks, very choppy, at almost random times. So generally sequencers completely ignore that message when recording or thruing data. However, it might be a useful message to MANUALLY insert at both the beginning and end of canned general midi standard midi files. The all notes off message at the head makes sure there are no hung notes remaining from the previous song in the playlist, and the message at the end hopefully cleans up the synth's state for the next song in the playlist.

As best I recall, active sensing may have been yamaha's bright idea. In the early days of midi they were not aware whether stuck notes would be a big problem or a little problem. So roland's excessive use of all notes off, and other manufacturers transmitting active sensing, was intended to fix a POSSIBLE stuck note problem that turned out not very serious in practice.

I don't know how many synths pay attention to active sensing nowadays. The idea-- A synth that recognizes active sensing will work entirely normal if it never receives an active sensing message. But if a synth starts receiving the periodic messages, but then the stream of active sensing messages stops, it is supposed to turn off all its notes.

[jay101]

http://www.ericasynths.lv/en/shop/stand ... h_box.html

would this work