Bomebox/MTP Velocity for Volca Fm?

Noob here. How would I go about getting note-on velocity mapped to the volca in a MTP patch running on my bomebox? From what I understand I would need to convert the note-on velocity to cc41, and send it BEFORE the note-on message, but have never used Midi Translator Pro before. Any help would be appreciated greatly as it might save me buying another piece of hardware to do the job :)

Hi, and welcome to the Bome Forum!

 

The note on velocity message comes with the note.  The note velocity would be a value from 0-127. You would change this in the rules portion of your translator.  As an example say you receive a note-on message with a value of 127 (maximum velocity) and note 60.

If on channel 1 the raw incoming message would look like this:

90 3C 7F

The 3C is the hexadecimal value for 60 and 7F is the hexadecimal value for 127. The 9 in Hex 90 indicates a note on message and the 0 indicates channel 1 (channels are 0-FH or 0-15D).

So say you want reduce every note to 1/2 of the incoming velocity.  This is how you would set up the translator

Incoming: Note On Channel 1 any velocity set velocity to PP

Rules:  pp=pp/2

Outgoing: Note On Channel 1 velocity pp

 

I hope this helps.

Steve

bome@sniz.biz

Independent Bome Programming Specialist

Bome Q&A moderator

 

Hi, Pete,
Just following up. Did this help?

*Sorry. I posted this as an answer rather than a comment, in error. *

I haven’t tried yet. It should help a bit, but in the example you use, the three messages (channel, note-on, and velocity) would still be sent in the same order?  What I think I would need is to replace/translate the velocity value from velocity to midi cc41, AND hold the note-on message until AFTER the cc41 value is sent, so the actual output from the example input you use would represent something like “midi channel 1 cc41 127; note on midi channel 1 60” I think. In case it isn’t clear, I am a noob at this, so please feel free to point out where I’m wrong or what I need to go and learn.

Well normally velocity is sent with the note but it looks like with the Volca FM (reading the document), it looks like it is sent as a seperate CC message but controller looks like it is 41 and that transpose and octave is 40.

I would guess that you would send the velocity message first and then the note so if you wanted a note on at full velocity it would look like:
B0 29 7F 90 3C 7F. Looks like kind of a screwy setup. In fact I don’t think that the last 7F will even count for anything. Very strange. So you will likely need to experiment or contact Korg if you have questions on how the synth works.

If you would want to make a translator from a standard keyboard you would probably need something like this

Incoming: Note On Note 60 channel one any velocity set note to pp and velocity to qq

Outgoing: B0 29 qq 90 pp 7F

That looks like it should help, although I also wonder whether the last velocity message is necessary. In terms of it seeming “screwy” – it actually makes sense in terms of their hardware interface, which includes a sequencer and a real-time velocity slider (and octave slider too). What is screwy (as you notice) is the fact that the device doesn’t have the ability to respond directly to keyboard velocity when played externally. There is at least one third party device (cable plus processor) available to translate this information in real time, and I thought it would be great if a bomebox plus an MTP patch might be competitor, and give us volca fm users another option. If I (or someone else) were to make a patch, would it be ok to make it freely available publically for other bomebox users, or does bome(tm) prefer that each user creates her own?

Hi, I would seem it highly unlikely that the note velocity could get left out. You should be able to sent the project file to another user to use on BomeBox with no problem. The users would need to buy MT Pro if they plan on making any edits. I’ll double check the policy on that for you though since I’m not with Bome but on contract with them to help on this board.

Hi, yes, it’s OK for someone else to edit the file in MT Pro for you to use it with your BomeBox. Also, whenever Steve (or any normal user with MT Pro license) posts a project file here in the Q&A forum, it will be properly signed and it’s OK to be used on a BomeBox. But all that is rather a tolerated side effect than on purpose.

I eventually found the time to get an MTP project set up that does allow me to do this.
It involved setting a translator such that:
Input:
Note on – any note – channel 3 – set note to pp – set velocity to qq
Output:
B2 29 qq 90 pp 7F

I am currently using a volca fm on channel 3, for which this will pass the note on velocity value correctly as a cc value before the note, to the velocity slider on the volca, which is awesome.
What I couldn’t work out was how to set up translator to work on any/every channel, I tried setting the input channel to oo, and using Boo 29 qq instead of B2 29 qq, but it seemed that MTP wanted to split the message into pairs of characters (I think), so that didn’t work. I think it was interpreting it as Bo o2 9q q9 0p p7 F, but could be wrong. Anyway, I figure it’s either something simple I have overlooked. I could get the note on message to match the input channel, but couldn’t make the cc message do the same. I figure I’m pretty close, and could always make 16 versions of the translator but that seems like overkill.

HI for any channel CC number do this
Incoming oo 29 qq
Rules:
// determine incoming channel number. We are simply masking the lower 4 bits (0x0f)
tt=oo&15
// tt now contains the incoming channel number
// get the command (upper value).
// 0xF0 = 240 decimai
uu=oo&0xF0
// We are only looking for B (cc change command)
if uu!=0xb0 then exit rules, skip outgoing action
// now if we always want to output to MIDI channel 5 (I think you don’t so this is an
// example of how to reconstruct status and channel uu is command and 4 is
/// MIDI channel. you just OR the two values to gether
vv=uu|4
// vv is now 0xB4

Ok, I have come back and re-read this a few times now. It is very helpful, hut there are still some things I don’t fully understand (yet).

For example:
Determining midi channel by “masking lower four bits (0x0f)” – what is going on here? I mean, I understand the result, but I don’t understand where the 0x0f comes from, and what it means. Is the “x” in this string a multiplication? Clearly there is no “x” in the hexadecimal system. I also don’t *really* understand what a bit is, in relation to the message we are dealing with, and therefore what the “lower four bits” really means. Also, I don’t exactly understand how or why “tt=oo&15” achieves this masking and lets tt=incoming channel number.

Moving on:
“Get the command (upper value)”… We are getting the message type here (i.e. Bx for program change, 9x for note-on [where x is the channel in hexadecimal])? Is that correct?

Next:
“// 0xF0 = 240 decimai” I think this is a typo-error for decimal, but I’m not sure why “uu=oo&0xF0” achieves the result we want, which I guess is to “let uu equal message type” [unless I was wrong about what was meant by “Get the command” earlier]. (Is this using more masking, perhaps?)

(Aside:
I managed to negotiate the line “of uu!=0xb0 then exit rules, skip outgoing action” but only after pulling up a pdf of the manual and using the search function to find instances of “!” – my lack of experience with scripting, programming, etc, meant that I did not realise “!=” was a simple “does-not-equal”. I think it was on page 60-something of the manual. I have included this so you have some idea of the ignorance with which I am approaching this. I have, on a few occasions, read through the manual, and the forum, and seen a lot of your videos, but it is exceptionally difficult to take it all in, and I always find I don’t understand or remember the information I need when I need to use it!)

Further:
In the “if uu!=0xb0 then…” line, I don’t understand this now familiar type of string, here represented by 0xb0. I mean, I assume it just means “B (change command)” but I am hazarding guesses at a lot of this.

Final section:
How does ORing the command and the channel together work? My internal logic doesn’t like “let z=a or b” leading to “z=ab”, or “z=a_then_b” although I’m sure this is my stupidity. I am assuming from “// vv is now 0xB4” that vv is now what I would have thought of as B4 (cc change on channel 5).

If you have time:
– I noticed yoy did not include an outgoing message, would this set of rules be used in conjunction with the other rule/translators to achieve the “velocity-to-cc41-and-sent-BEFORE-note-on” result, or did you envisage a single self-contained rule to do the whole process? Is one way obviously better than the other?
-Would replacing the last action in the rule with “vv=uu|tt” mean that vv became a control change message (B) on whatever the input channel was, or am I way off the mark?

And just for clarification:
Some of the four character strings which begin 0x (such as “0xF0” and “0x0f”), have got lower/upper case letters (aside from the lower-case “x”). Is this intentional? Are they case-sensitive strings? Do f and F mean different things there?

Thanks so much for the help you’ve already provided me with this.

Ok, I have come back and re-read this a few times now. It is very helpful, hut there are still some things I don’t fully understand (yet).

For example:
Determining midi channel by “masking lower four bits (0x0f)” – what is going on here? I mean, I understand the result, but I don’t understand where the 0x0f comes from, and what it means. Is the “x” in this string a multiplication? Clearly there is no “x” in the hexadecimal system. I also don’t *really* understand what a bit is, in relation to the message we are dealing with, and therefore what the “lower four bits” really means. Also, I don’t exactly understand how or why “tt=oo&15” achieves this masking and lets tt=incoming channel number.

SJC> OK if you look at a binary value of a 8 bit MIDI Bite it looks like this

1111 1111

I separated the values by “nibble” which is 4 bits. The right most bit of each
nibble represents 1, the next one 2, the next one 4 and the left most bit is 8

So to represent different numbers
000=1
0001=1
0010=2
0011=3
0100=4
0101=5
0110=6
0111=7
1000=8
1001=9
1010= 10 decimal (A Hex which is represented as 0xa)
1011= 11 decimal ( 0xb)
1100=12 decimal (0xc)
1101=13 decimal (0xd)
1110-14 decimal (0xe)
1111-15 decimal (0x0e)

so 1111 1111 represents 0xff (first nibble 0xf0, second nibble 0x0f)

the MIDI command for note on is 0x9n where n is the channel number starting with zero. So 0x90 is note on MIDI channel 1. 0x91 would be note on MIDI channel 2
and so on.

What we do here is OR the bits together. The operator for or is “|”

1 OR 1 = 1
1 OR 0 = 1
0 OR 1 = 1
0 OR 0 = 0

So if we take the first nibble 0xB0 and OR with the channel number we get the
full note on and channel message

1011 0000 (0xb0)
OR
0000 0000 (0x0)
=========
1011 0000 (0xb0)

If we OR it with channel 1 we get

1011 0000 (0xb0)
OR
0000 0001 (0x1)
=========
1011 0000 (0xb1)

So essentially we are building the note on message with the channel number in
the rules

<SJC

Moving on:
“Get the command (upper value)”… We are getting the message type here (i.e. Bx for program change, 9x for note-on [where x is the channel in hexadecimal])? Is that correct?

SJC > Yes
<SJC

Next:
“// 0xF0 = 240 decimai” I think this is a typo-error for decimal, but I’m not sure why “uu=oo&0xF0” achieves the result we want, which I guess is to “let uu equal message type” [unless I was wrong about what was meant by “Get the command” earlier]. (Is this using more masking, perhaps?)

SJC> Not a typo. For an 8 bit number the lowest bit on the higher nibble is 16

So 0xf0 converted to decimal is 240

1 times 16
plus
1 times 32
plus
1 times 64
plus
1 times 128

128+64+32+16 =240
<SJC

(Aside:
I managed to negotiate the line “of uu!=0xb0 then exit rules, skip outgoing action” but only after pulling up a pdf of the manual and using the search function to find instances of “!” – my lack of experience with scripting, programming, etc, meant that I did not realise “!=” was a simple “does-not-equal”. I think it was on page 60-something of the manual. I have included this so you have some idea of the ignorance with which I am approaching this. I have, on a few occasions, read through the manual, and the forum, and seen a lot of your videos, but it is exceptionally difficult to take it all in, and I always find I don’t understand or remember the information I need when I need to use it!)

SJC> Thats OK, we all started here at one time or another. Part of the learning experience.

Further:
In the “if uu!=0xb0 then…” line, I don’t understand this now familiar type of string, here represented by 0xb0. I mean, I assume it just means “B (change command)” but I am hazarding guesses at a lot of this.

SJC> If uu is note equal to hex b0 (decimal 176) then ..

0xb0 is the command (upper nibble) for a control (CC) message on channel 1

For instance if you want to change controller number 1 on MIDI channel 2 it would be
0xb1 0xnn 0xvv

where nn is the controller number and vv is the value
<SJC

Final section:
How does ORing the command and the channel together work? My internal logic doesn’t like “let z=a or b” leading to “z=ab”, or “z=a_then_b” although I’m sure this is my stupidity. I am assuming from “// vv is now 0xB4” that vv is now what I would have thought of as B4 (cc change on channel 5).
SJC>
Hopefully this is explained above already)
OxB4 is Control change on MIDI channel 5)
<SJC

If you have time:
– I noticed yoy did not include an outgoing message, would this set of rules be used in conjunction with the other rule/translators to achieve the “velocity-to-cc41-and-sent-BEFORE-note-on” result, or did you envisage a single self-contained rule to do the whole process?
Is one way obviously better than the other?

SJC> Including all rules in one translator vs multiple translator is usually a matter
of choice. For me, if I already have a translator that handles a given function, I try and leverage it rather than duplicate it in multiple translators. That way, if I later need to change it, I can change it in one place rather than many).
<SJC

-Would replacing the last action in the rule with “vv=uu|tt” mean that vv became a control change message (B) on whatever the input channel was, or am I way off the mark?
SJC> You are right on
<SJC

And just for clarification:
Some of the four character strings which begin 0x (such as “0xF0” and “0x0f”), have got lower/upper case letters (aside from the lower-case “x”). Is this intentional? Are they case-sensitive strings? Do f and F mean different things there?

SJC> Case is insensitve in MT Pro 0xf0 is the same as 0XF0.
<SJC

Thanks so much for the help you’ve already provided me with this.

SJC> Your quite welcome!

<SJC

What a ridiculous amount of useful information. That was really helpful, you have cleared up a lot of that for me! I managed to understand the masking using “&” from the OR example you use – just working out that the AND and OR functions work on a bit level, and what that really means, has made everything make a lot more sense. Understanding the relationship between the different ways of expressing the midi data, and the OR/AND operator function, means my head feels a lot less explody. Thanks very much. I would like to mark this issue “resolved” one day, but I have a suspicion that I’ll have to overcome some kind of “global variables” issues (in my understanding) when it comes to playing this thing in monophonic mode (“legato” trills result in the first note being retriggered at the second note’s pull-off at the velocity the second note was played at, as that was the last time a value was sent to cc41, of course!) but I am a little way off that level of rules creation and definitely will try things out for myself first. I guess I’ll probably see you back here – whatever they are paying you, it’s not enough!

Glad I could help! You can mark this as resolved if you want. That way others will know where the gems are hidden. If you have any more questions, you can just open up a new topic to that specific question.

Thanks for the good word about the pay. I’m happy with the current situation!

Steve

Cool. Well, there’s more than enough info here to solve the problem, I now have a three-voice “yamaha dx7-style” synth that will respond to velocity over midi 🙂

It is worth mentioning that I also had to pass note off messages through to avoid hanging notes.

I will try and post the project a bit later on when I’m at a PC, that way others can make use of it if they like, then I’ll mark it “resolved”.

As a further aside (I know florian had asked for feedback on this, so don’t feel it is necessary to respond directly to this, unless you want to point me towards a general “site feedback” thread that I couldn’t find) – the non-consecutive nature of questions, answers, and comments on this new Q&A site is more difficult (for me) to use than the old forum, despite the massive amounts of help provided here. I also feel this format is less conducive to public discussion (it feels more like “ask steve and maybe florian”), which could be seen as a good thing or a bad thing, and the non-boxed display of posts on a white background doesn’t help much. Obviously there are swings and roundabouts to this format, of course. Maybe I am just very used to “traditional” forums.

Hi, Pete. I will pass this along to Florian.

Steve

Pete, it’s OK to discuss the Q&A site here. A traditional forum has the benefit that discussions just go on in chronological order. However, we also want the forum to become an archive of problem solutions. For someone looking for a solution, it’s very time consuming to read through dozens of posts to find the one which gives the solution. This “new” Q&A site allows the separation of possible or partial answers vs. discussion. I believe it’s much easier later to find the gist in this Q&A.
However, I see the point that during discussions, things can get confusing. We’re open to change the support forum system once again, but would need to find something that is better than both…
We also hope that we’ll be able to fix some of the other minor annoyances with the current system soon.
Florian