dividing the 16 channels of the input midi port

how can i divide the 16 channels of the input midi port to different virtual ports?
that is useful with the hosts which never see the 16 channels of input midi port
as cubase element , FLstudio and many more.
some applications like Sonar and Protools see the 16 channels well.
any help??

Hi alswefi

If you want to set each channel to run to a different port, then you want to set individual translators, or presets, to send to individual ports.

You would need a different translator for note on, note off, CC, etc, that run on each channel, but other than that you should be fine. You could also create a translator that looks like:
And you'd have a different translator for each one that changes from 0x90 to 0x91, etc. Just keep in might that there aren't 16 available virtual ports through MT Pro, so you would need to include another virutal MIDI port application, like MIDI Yoke or LoopMIDI to get the rest of the ports you'd need.

Does that make sense?
Jared

first thx for your reply
all i need is just 2 channels at least 1 ,2
i,m still newbie and can,t do it my self
if u help me doing that it will be a big favour

is that true? or i miss something?
i tried this ,it works but without the pitch bend is it need a special translator for it??
should the Bome MIDI Translator be opened every time i play?
or maybe there is a method to save the setting without opening it every time ?

thx
alswefi

Hi Alswefi

As to your last question, you need to open MT Pro every time, or it won't be there to route your MIDI messages. There should be a setting to open when your OS activates, though.

If you need pitch bend then add one message in

if pp==0xE0 then exist rules, execute outgoing action

And in your second translator be sure to change 80, B0 and E0 to 81, B1 and E1, respectively.

working like charm
many many many thx , it is a big favour.

Sorry. Old thread.
If I might ask for a bit of clarification.

If I'm listening for a MIDI Msg "pp qq rr", it's for any 3 byte MIDI message for testing, but ignores 2 byte messages, correct?

So for Pgm Change & Channel Aftertouch, I just need to listen for a MIDI Msg "pp qq" which would accept any incoming 2 byte message which I can test for D0, D1, D2, etc & C0, C1, C2, etc, yes?

It looks by your request that you are trying to ignore velocity on Note-on messages, right?

If so, I would listen for any note on at any velocity and then on output set it to always the velocity you wish to pass through ignoring the input velocity. I might add a translator that also takes any incoming note on with velocity of 0 to a note off output message.

Thanks for responding sjcaldwell.

I'm not ignoring velocity, since that is part of the 3 byte Note On msgs. I'm looking at specifically pgm change messages (such as 0xC0) and channel aftertouch (such as 0xD0), which are 2 byte messages.

In the above examples, Note On (with Velocity), Note Off, CC, and Pitch Bend are being routed per the Outgoing Actions, but 2 byte channel messages are unaddressed. or are they...?

@CreepyPants

I would think any messages you do not swallow or have "end with this translator" set, will pass on to the next translator for processing.

If you don't have any translator for the given input condition AND do not have a default route, it will also get absorbed.

Otherwise it would pass through the default route(s).

Any translator can be set to either "swallow input message" (not passing on to further translator)
End with this translator (stop processing)

If neither of the above, then next translator in line picks it up from there until either of the above conditions are met.

Yeah, but I'm thinking I need a separate translator and was just looking for clarification.

That is, with a MIDI incoming message being 2 bytes such as Pgm Chg or Channel Aftertouch, but passing 3 bytes to the outgoing, I'm imagining that the first byte of the next message will get passed and that might caca things up.

That is, if I define the incoming pp qq rr, but it's only a 2 byte message coming in, is the rr now whatever data in the stream is following the two byte message? Or does rr effectively go to 'null'.

And if I pass three bytes after determining it to be a two byte message, am I throwing data in that doesn't work.

In other words:

Translator 1: Channel 1 Passthrough
Incoming: MIDI Message
RAW/Sysex
pp qq rr
Rules: if pp==0x90 then exit rules, execute outgoing action
if pp==0x80 then exit rules, execute outgoing action // This is a 3 byte message
if pp==0xB0 then exit rules, execute outgoing action // This is a 3 byte message
if pp==0xE0 then exit rules, execute outgoing action // This is a 3 byte message
if pp==0xC0 then exit rules, execute outgoing action // This is a two byte message
if pp==0xD0 then exit rules, execute outgoing action // This is also a two byte message
Exit rules, skip outgoing action
Outgoing: MIDI Message
RAW/Sysex
pp qq rr
Virtual Port: MT Virtual Port 1

If the Translator receives the msg C0 04 (Program change of 04 to Channel 1), route it to a port, but other messages get routed to a different port, will that screw up the data stream because there is not third byte for "rr".

Note: I'm using Presets to determine routing because I change it for each song. I'm one of those 'old guys' with multi-timbral romplers that handle 16 channels each unit, and some are on the same MIDI port (although I can address each program/bank change separately via SysEx)

The grunt way to do this I'd imagine is set up a separate Translator per channel for a 2 byte messge, but my initial query remains as I'd like to be informed and/or have a more elegant approach.

I think florian will need to answer that one.

I guess the question is on incoming messages, when looking at 2 bytes of a 3 byte input sequence, if you set it to swallow, what happens to the 3rd byte in the next translator? Does it:

1) get swallowed as well?
2) get passed on to the next translator by itself?
3) do all 3 bytes pass to the next translator? (given that it is a 3 byte midi sequence and we only cared about the first two bytes)?


If number 2, do I need to set up a translator rule for that. Please clarify

Is this what you are trying to determine?

Great question by the way!

"I guess the question is on incoming messages, when looking at 2 bytes of a 3 byte input sequence"

Apologies. This is what I'm trying to explain:
The MIDI Message for Aftertouch is NOT a 3 byte input sequence.
Not all MIDI Messages are 3 bytes. Note on/off, etc are. Pgm Change, SysEx, Channel Aftertouch, etc are not.
(Oh, let's get into SysEx! Especially on old synths where the manufacturers have been bought/sold enough that even the 'Legacy Equipment' links are out of date! LOL)

In the examples of MIDI Messages on p38 of the MTPro Manual under Raw MIDI Examples, it lists "pp qq rr" as "Any 3 byte MIDI message".

My question is:
Does MTPro ignore 2 byte MIDI Messages then if Raw MIDI is selected and "pp qq rr" is the variable 'mask'?
And if so, then for 2 byte MIDI Messages, would you just look for Raw MIDI "pp qq" and that would apply to "Any 2 byte MIDI message"?

Note: Effectively I have set up a separate Translator to address Channel Aftertouch, using a 2 byte 'mask' (if that is the correct concept here) rather than a 3, and it seems to work as expected.

I'm just wondering if I'm being consistent and correct with how the back end of MTPro works and hopefully avoid any snafus in the future with MIDI conflicts because I don't fully understand the big picture.

CreepyPants wrote: My question is:
Does MTPro ignore 2 byte MIDI Messages then if Raw MIDI is selected and "pp qq rr" is the variable 'mask'?
And if so, then for 2 byte MIDI Messages, would you just look for Raw MIDI "pp qq" and that would apply to "Any 2 byte MIDI message"?

My guess is the midi parser in BMT determines the length needed for the given message and if it is 3 bytes and the third byte is missing (by seeing another Midi Status byte), it will discard the message.

I did a bit of testing.

I set input message as B0 54 (missing the third) byte input from Bome Virtual in (using MidiOX). Output back to MidiOX. Note on note 60 velocity 127
I then sent that message B0 54 127 to the translator and it did not do anything with it. but I could see the message coming in.

I then changed input translator to B0 54 pp. (where pp is the third byte)

Then I resent the message from MidiOX

BMT then recognized it and processed the output 90 3c 7f

I suspect for incoming sysex it would do similar but the sysex end byte would tell it when to stop unless the BMT sysex buffer is overrun.

Duh@me
I didn't even think of trying to test this with MIDIOx.
I was dogsitting (more like we have a puppy who will destroy things if left unattended) so was working on scripts outside of the studio.

Once I tested it in the studio, it works as imagined as long as I create a separate translator for 2 byte messages.

But I still wonder if I'm going to run into problems once I get all the MIDI data flying around and my superscript is completed. (I'm controlling three 16 channel multi-timbral romplers (guess they're 'vintage' although at least one of them I had when it first came out - 90s or something), an Octatrack, and a DSI Prophet 12 from the Prophet, a Nektar controller splitting the faders, keys, buttons, pads, & knobs to different channels, and of course the OT sequencer...so yeah: lots of crazy conditional routing that changes for different songs)

Still hope to get a glance from Florian or Jared to let me know "hey, you're an idiot - don't do that" or not.

Great kicking ideas around with you sjcaldwell!
Seems so much on this board is someone asking a question and Florian or Jared giving the answer instead of conversations between users. I'd love to hear (on a different thread, of course) about how you use MTPro and/or BomeBox in your rig, and what you use, how you approach your scripts, and how that applies to your creative process! Because: geek.

Happy to share, I think I posted my one and only BMT file a few weeks ago. PM me if you want to learn more or we could maybe start a thread titled "How I use BMT and Bome Box" in the "Anything Else" form. (geek too).

ha, we definitely welcome any geek to geek chatting here!
I wish I had more time for musically geeking out...
Florian

@ Florian
Moar geeking out!
it's good for you

But: Is my assumption correct?
If testing for "MIDI Message" and using variables 'oo pp qq', MTPro will look for 3 byte MIDI messages & ignore 2 byte MIDI Messages, but Incoming "MIDI Message" with variables 'oo pp' will look for 2 byte MIDI messages & ignore 3 byte MIDI Messages?

Functionally this is what is happening for me right now, but I dont' want to use this assumption as the basis for this Preset if it'll cause problems later on.

Hi Creepy Pants,
tough questions here! It caused us quite some smoking heads when visiting an issue with all-variable incoming MIDI messages for version 1.8.0. Because it is possible to react on a series of MIDI messages with just one incoming MIDI action (and we like that functionality). For example, "90 33 pp 90 34 qq" will trigger when you play note 33 (hex) and then note 34.

Since version 1.8.0, we believe we have found a consistent way to handle this. The general rule is: you can concatenate messages in the incoming action, but the length of the last incoming MIDI message must fill up the incoming action exactly, otherwise it is not considered.

Getting back to your incoming action "oo pp qq": the simple case is for an incoming 3-byte MIDI message, where it will always trigger, no matter what came before. If there is a 2-byte MIDI message, it will remember it for oo and pp, and wait for the next MIDI message. If the next one is another 2-byte MIDI message, it will exceed the length, and therefore it will not trigger. It will, however, remember the new 2-byte MIDI message now for oo and pp. Just in case. If now a 3-byte message comes in, the previously remembered 2-byte message is ignored and the 3-byte message triggers.

However, if a 2-byte message comes in, followed by a 1-byte message, it will trigger! Granted, it's quite unlikely, but possible. The same is true for a 1-byte message followed by a 2-byte message, or 3 consecutive 1-byte messages.

If you don't use 1-byte messages in your translators, you can just filter out all 1-byte messages by creating a translator with Incoming = "pp", Stop Processing checked, and Outgoing = None, somewhere BEFORE your 3-byte translator. Otherwise, you can find out if you an interspersed 1-byte message by using Rules to check if pp or qq are greater than 127: Hope that makes sense!
Florian

This makes complete sense and THANK YOU for the response Florian!

I'm often focused on what I want to do but lack the experience/knowledge to allow for other circumstances. This helps me resolve future problems that will make my head split open.

1-byte MIDI messages tend to be Song Select, Song Position Pointer, etc, correct?
Or timing clock F8, right?
(Timing clock: eek!)

I remember from my old code-hack days about the need to test for valid data before processing. This helps step things up. Thank you!

Great explanation Florian and it is in complete alignment with the simple tests I performed on this logic.