Is there an explanation of Midi Ports vs Midi Through?

I've nearly finished the MT program for a DIY midi control surface and in the process have had to change the Midi signal flow. Basically:
- Midi is generated by the controller
- Is received by Midiox, for some processing
- Is sent out MidiYoke 1
- Is received by MT for further processing
- Is then sent back out to Midiox on MidiYoke2
- Is received by Midiox and sent back to the controller and to Ableton.

Sometimes when I've changed the routing of Midi, the system as a whole stops working, mainly because I seem to be confused about the difference between Midi Ports and the Midi Router. I"m not using the Virtual Ports in MT because I'm comfortable with MidiYoke (the same thing, right?).

My understanding is that the MIDI Router is separate from the Ports, somehow, and is used to allow Midi to bypass processing by MT, and just be sent through directly from IN port to OUT port. Still, this doesn't explain what happens to my project when I make changes in the ports etc.

I'd really appreciate a concise definition of the various terms involved in Midi Port setup, and how the routing works.

I think I understand that the aliases are merely more descriptive labels for the particular midi ports that are used in a preset, that also make it possible to assign routing per translator....I think.

Somehow, I'm stumbling along without such a definition, but it's quite disturbing, sometimes to have everything grind to a halt while I try to figure out why Midi doesn't show up where I expect it to.
Thanks,
Gabriel

Also, I'm not a total noob to this stuff but totally confused here regarding how to set up the midi flow in and out of MT.

Is there a diagram available anywhere for us left-brain challenged types?

Picture paints a thousand words and all that...

Cheers,
bagginz

A large update to the MT Online Manual is underway. Hopefully it will be released soon... All the new terminology will be covered, along with an extensive section on MIDI routing and MT's implementation thereof.

Until then, I can briefly summarize the differences between MT virtual ports, Port Aliases and the MT Router...

MT virtual ports DO NOT work the same as MIDIYoke ports. MT virtual ports HAVE to have one end connected to Bomes MIDI Translator, while MIDIYoke ports can function directly between 2 3rd party applications (for example; directly from Traktor's MIDI clock output to Ableton Live's MIDI clock input). MT Virtual ports serve as a conduit between MT and other devices, but HAVE to have MT running and handling the data in order for them to work.

MT Project templates can have default IN and OUT ports defined, which all your presets and translators will default to when you first create them. Presets can override these defaults and have multiple IN/OUT ports specifically defined, letting you create a preset that is specific to a particular midi controller input, a particular application, or both. Even then, individual translators can have the project/preset IN/OUT ports overridden and have their own ports defined as well.

Port Aliases are more or less a way to facilitate easy transportability of MT templates between different MIDI controllers and software packages. In your project you can define the default incoming port as an alias such as "PROJECT IN", and then link that Alias to whatever controller you want. That way you can give your template to a friend with a different controller, and MT will just ask you to link the PROJECT IN alias to the different controller. Outgoing alias ports work the same way - letting you link a default project OUT port such as "PROJECT OUT" to whatever application or midi port you wish with little hassle.

The MIDI Router in MT is very simple and works similarly to MIDIOX's setup. Use the MT MIDI Router to create Thru connections between ports and port aliases. Most commonly you'd want to create a link between your "PROJECT IN" and "PROJECT OUT" ports, if you created aliases for your project. This way any UNHANDLED midi data coming into MT from the IN port would be retransmitted unaltered to the OUT port defined.

Anyways....

If you are having trouble changing your MIDI settings and having things break, I would suspect that you have some of your IN/OUT ports hardwired in a preset or a translator somewhere.

As far as the manual goes... Soon I hope.

joe

BIG help!!!
Thanks,
Gabriel

Hello Joesapo,
thanks for the info...

But I still don't get it at all!

A simple back of an envelope schematic would clarify things hugely for me.

I have: Midi interface - BomesMT open - Ableton Live8.04

Please describe the basic setup/ configuration so that MIDI actually arrives into Live via MT.

Looking at the Event Monitor; at present, midi is showing up as an input to MT and being passed thru to the router. No midi is showing up in LIve despite me turning on all of system buttons in Lives Midi config. page.

Any ideas?

cheers,
bagginz

bagginz wrote:Hello Joesapo,
thanks for the info...

But I still don't get it at all!

A simple back of an envelope schematic would clarify things hugely for me.

I have: Midi interface - BomesMT open - Ableton Live8.04

Please describe the basic setup/ configuration so that MIDI actually arrives into Live via MT.

Looking at the Event Monitor; at present, midi is showing up as an input to MT and being passed thru to the router. No midi is showing up in LIve despite me turning on all of system buttons in Lives Midi config. page.

Any ideas?

cheers,
bagginz

If the Router LED is flashing, then you should be actively transmitting MIDI from your project in to the output as a thru connection. I would check and make sure that Live has "Remote" enabled for your MT Virtual port or whichever midi port you have selected as output.

Hello Joesapo,
o.k . thanks for the info....


Bagginz

Hi Gabriels,

gabriels wrote:I'm not using the Virtual Ports in MT because I'm comfortable with MidiYoke (the same thing, right?).

In addition to Joe's info, some more clarification on the virtual ports.

Yoke is a loopback port, i.e. it uses both Windows' API for the input and for the output port. So signals go out to Yoke's input, where it's sent out using Yoke's out:
OX OUT -> Yoke 1 IN -> Yoke 1 OUT -> MT IN
and
MT OUT -> Yoke 2 IN -> Yoke 2 OUT -> OX IN

Bome's virtual ports are more direct, as only one end is using Windows' API. The other end is a direct feed into Bome's Midi Translator:
OX OUT -> Bome's Virtual 1 IN -> MT
and
MT -> Bome's Virtual 1 OUT -> OX IN

Bome's virtual ports were designed from the beginning to be as efficient as possible for best performance (i.e. lowest delay and jitter). Having only one end go through Windows' API will probably save some...

Regards,
Florian

I see that this is an older post/thread, but I have a pretty related question, I think, concerning how MT ports handle data, specifically at the project level. For now anyways, ha ha.

In my rig setup, I am using 3 virtual in ports and 3 virtual out ports - tho it just occurred to me that perhaps I only need to use 2, maybe even just one MT out port. Guess I'll check into that.

Anyways, I have 3 hardware controllers, and I am using either Logic X or MainStage 3 as my software, with various plug-ins. I have just a few translators set up, all related to just one of my controllers, a Korg Nano Kontrol.

When MT processes incoming flagged/defined messages for the translators I have written, assuming I only have ports open/defined at the project level, does MT send this data to be passed on by any/all open out ports? Which in my case would be 3 ports. I believe this is what was going on in my project, and not what I wanted. I seemed to have fixed the problem by defining a single port at the preset level, just for the nanokontrol.

I'm just trying to make sure I understand the data flow thru MT as clearly as possible for most efficient use of the program - and my time as well, hopefully.

Hi sacrebleu,
that's exactly how it works. In a more technical way, this is how MT sends a MIDI message from an outgoing action:

1. does this outgoing action define specific MIDI port(s)? if yes, send the message to this/those port(s) and be done.
2. otherwise, check the preset that this translator is in: does it have defined specific Preset Default MIDI OUT ports? If yes, send the MIDI message to this/those ports and be done.
3. otherwise, check the project for checked Project Default MIDI OUT ports. If there are any, send the MIDI message to those ports and be done.
4. last resort if no ports are specified: send the message to all opened MIDI ports.

For MIDI IN, it works exactly the same: the incoming action triggers only if the message originates from a port specified in the translator, or preset, or project -- in that order.

I find it most useful to organize my presets by MIDI connections and therefore almost exclusively use Preset Default Ports.

Hope this summary helps. The user's manual does have a section about this, too...
Florian