Bit Setting Resource

Bome Products
1

Hi All

Ive had a pretty intense day off, coming to grips with MTP...all great so far but it would be great to have a sticky of how to do the basics as far as manipulating RAW data. I have the found the RAW incoming/outgoing really debulks a lot of the filtering. Just some basic concepts like (as I have been away from midi for a number of years):

Assuming the variable of rr, pp, vv as representing the Status/Channel, pp as Data 1 and vv as Value (Data 2)

To extract the

Status Value (Type of Event):

rr???? (do this)

Channel Value:

rr????

Combine Status and Channel:

rr????

I know there are disparate resources on the net but a little toolbox would be great, especially as a single location on the forum here.

A flow chart of how port routing works

Using timers with simple example of eg scanning, forking etc. Id be happy to share my gestures preset as it contains a lot of those bits, maybe having a resource with other contributions. Would have made life a lot easier in learning. Always helps to see how other do things and enriches everyone. Bits and pieces are on the forum. Just a thought.

Great prog.

2

Hi,

To extract MIDI channel from status rr where pp is Byte 2 and Byte 3 is value

// Filter out first digit and put in variable tt

tt=rr&0x0f

// If you want only the status byte without the channel put in tt

// mask

tt=rr&0xf0

//Shift

tt=rr>>7

// Combine Channel and status

// Status

tt=0x90

// MIDI Channel 2

uu=0x01

// Combine them (OR operation) and put them into rr

rr=tt|uu

 

Default Routing will allow everything through its route except for translators that execute outgoing action AND have swallow set. If the translator output is aborted, the output will still follow the default route.

As a matter of personal preference, I tend not to use any default routing and do things in translators instead. Probably because I’m a control freak and don’t like default routing surprises (messages sneaking through the default routes). But you can do it either way.

The key exceptions to this are if I want do do something “quick and dirty” and not spend a lot of time on writing translators, or if I need to allow System Exclusive messages of variable length through.

If I use default routing, I generally 3 translators toward the end of the project file that have output of “None”.

Suppress extraneous one byte messages

Incoming pp

Outgoing None

Suppress extraneous two byte messages

Incoming pp qq

Outgoing None

Suppress extraneous three byte messages

Incoming pp qq rr

Outgoing None

For your last request on timers, feel free to post your projects so others can see and learn (including me). To me timers are one of the most powerful and useful parts of MT Pro and as such can also get you in the most trouble if not used correctly. I generally use them as a “dispatch” function (forking) and looping (iteration). They also come in handy to reduce code complexity for instance if you want multiple complex actions handled in a timer and then use the rules in the timer to manipulate variables and alter the output.

If you have ideas on how we could incorporate this in the MT Pro users manual let me know and I will tee this up for discussion with Florian Bomers.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 

 

 

3

Hi Steven (again 🙂

Default Routing will allow everything through its route except for translators that execute outgoing action AND have swallow set. If the translator output is aborted, the output will still follow the default route.

Great…the flow chart in the manual is brilliant. Just a little flow chart with the above I think would be a an excellent addition.

As a matter of personal preference, I tend not to use any default routing and do things in translators instead. Probably because I’m a control freak and don’t like default routing surprises (messages sneaking through the default routes). But you can do it either way.

Yes; in the other progs I was mentioning…you can filter the actual hardware port so its a direct hardwire. I use a couple of different rigs depending on who Im playing with ie percussion, guitar etc so I want to make sure that no matter whats plugged in, it operates ok…some presets are required just to translate the different hardware into the correct note nums. Ill have a go at using the defined ports.

Excellent! Good having a different perspective;

// Filter out first digit and put in variable tt

tt=rr&0x0f

// If you want only the status byte without the channel put in tt

// mask

tt=rr&0xf0

//Shift

tt=rr>>7

I did it differently by strip/pad; ie keeping the full SB+C, but same outcome;

tt=rr>>4

tt=tt<<4

// Combine Channel and status

// Status

tt=0x90

// MIDI Channel 2

uu=0x01

// Combine them (OR operation) and put them into rr

rr=tt|uu

As far as efficiencies go; it would be a great feature if there could be a ‘stop processing’ option for the current preset. That way you could do the filter at the top of the preset/per preset without having to manage the linear trickle down of trigger events. Alternately a pipe…bit like Pure Data/Max send and receive so that events can pop up in locations down the chain without managing trickle too but the extra stop option would be the lowest hanging fruit I would imagine?

I try and strip out the basic functions for time windowing ie timers on the current project. Im still adding features as they pop up ie with more use of MTP

 

Thanks again for you excellent help Steven

Mark

4

Better efficiency on your code, however I usually copy to a new variable in case I want to use it again later.

You can make the last translator in a preset stop processing if you have the right incoming trigger, no outgoing action and set the stop processing flag. That way MT Pro will immediately start a new cycle. In fact you can do that anywhere in the chain. You can also enable and disable presets in order to skip entire sections. Keep those suggestions coming though.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

5

Not sure what you mean…the tt is local and static scope as soon as its assigned isnt it? Thats the same local scope as
// mask

tt=rr&0xf0

//Shift

tt=rr>>7

?
Anyway, its great there is now somewhere to find the simple solutions and thanks so much for your input.

I meant with the translator stopping, would be great if it was local scope to the preset…that way, the preset isnt triggered at all…and in the main fork, the other presets can pick or choose action based on the same data travelling down the line. If its at the end…it means its already done a bunch of unneeded processing. I guess its more akin to parameter passing on a subroutine and you do the tests before it gets a chance to enter the routine. Unless Im missing something…its a bit clunky to do it without a localised stop?
Cheers
Mark

6

OK well I meant I could just to rr=rr>>7 if I didn’t want to do anything with the lower nibble, however I usually manipulate it and then put it back into the original value. Very often I split and re-assemble the status byte that way.

I see, kind of a “jump over me” preset. which you would have to do by disabling the preset in an “always on” preset” of have the earlier preset disable it. before it gets there and have it re-enabled at the end of the chain.

7

re: Status…gotcha!
I did try using the disable preset when I first started setting up some translators but, whilst the action of turning on and off worked fine, the actual trigger event didnt seem to make it. Ie turned on the required preset and then nothing else happened? The preset activation is a great feature…just didnt seem to work…of course could be operator error ;-/