fbpx
Skip to main content

MIDI Forum

Help with Yamaha FB...
 
Notifications
Clear all

Help with Yamaha FB01 manual and Sysex Messages

13 Posts
3 Users
0 Reactions
9,373 Views
e
 e
Posts: 5
Active Member
Topic starter
 

Is there anyone out there that can help me with a lot of questions about the Yamaha FB01 user manual?
I'm trying to understand how it functions using sysex messages.
The manual has a very cumbersome explanation.
My end goal is to write a program in max/msp that controls all or most relevant functions of the FB01.
But for now, I'm trying to understand the manual and I'm trying to understand how just use it so as to derive the needed values for the command/sysex.
FB01 User Manual
I've also been trying to reference: E.M., "Secrets of the Yamaha FB01"

 
Posted : 24/02/2017 7:21 am
Clemens Ladisch
Posts: 321
Reputable Member
 

I don't know if there are any FB01 experts here.

But if you'd ask a specific question about what the FB01 manual says, maybe we could help you interpret it.

 
Posted : 25/02/2017 9:40 am
Michael Rideout
Posts: 18
Active Member
 

I can try to help you with the MIDI side of it if you can handle the MaxMSP side. I've downloaded the manual and have just started looking at it, but I've got something else I'm doing right now, so I can't post anything yet. What I'll do after I've studied the manual a bit is post some hex code examples of changing some specific parameters, and let you ask questions from there.

 
Posted : 25/02/2017 2:15 pm
e
 e
Posts: 5
Active Member
Topic starter
 

Thanks for the replies. I've been studying the manual a lot these days and have figured out quite a bit since I started but for now my question is about the x+y=data formula that's on page 48 of the manual in the section, Parameter Change by MIDI Channel (Table2). According to the article, "Secrets of the Yamaha FB-01," the formula should be x*16+y=data. This is over my head when it come to trying to understand it and interpret it. Would any one be able to help me understand that part? Thanks in advance.

 
Posted : 25/02/2017 7:54 pm
Michael Rideout
Posts: 18
Active Member
 

Okay, I'm looking at that page right now.

The x value is stored in the low nibble of the "Data High" byte, and the y value is stored in the low nibble of the "Data Low" byte, so apparently the Data value is a 2-nibble (i.e., 1-byte, or 8-bit) value which is split up and transmitted using two bytes, one nibble per byte. I'm not sure why Yamaha did it that way, but I assume they had a reason.

So, for example, let's say that you want to set a particular Voice Data Parameter to a value of 127. If you're working with decimal numbers then you'll need to split the value into two nibbles by dividing it by 16 to get the x nibble, then using the remainder as the y nibble:

x = int (127 / 16) = int (7.9375) = 7
y = 127 - 16 * x = 127 - 16 * 7 = 127 - 112 = 15

Thus, for the Data Low byte you would use 15, and for the Data High byte you would use 7.

Of course, it would be a lot simpler if you were working with hexadecimal numbers, because then you'd already see what the two nibbles are, and could just use one nibble for Data High and the other nibble for Data Low:

127 (decimal) = $7F (hexadecimal)
x = high nibble = $7
y = low nibble = $F

So for the Data Low byte you would use $F (the hexadecimal equivalent of 15), and for the Data High byte you would use $7 (the hexadecimal equivalent of 7).

However, if you're planning to write a program that takes some variable Data value and passes it to the FB-01 in that particular type of SysEx message, you'll want to use a formulaic approach:

DataValue = the 1-byte value you want to set the given Voice Data Parameter to
DataHigh = int (DataValue / 16)
DataLow = DataValue - 16 * DataHigh

 
Posted : 25/02/2017 10:21 pm
Michael Rideout
Posts: 18
Active Member
 

PS -- Since the other types of SysEx messages don't seem to split the Data into two bytes like that, my best SWAG ("Scientific Wild-Ass Guess") would be that the physical memory for the Voice Data Parameters is actually made up of nibbles, or 4 bits per memory location, and that this is why the Data value for the given Voice Data Parameter must be transmitted to the FB-01 as two separate nibbles, or one byte per nibble.

 
Posted : 25/02/2017 10:34 pm
e
 e
Posts: 5
Active Member
Topic starter
 

M.R., Thanks for the reply. I don't know how you were able to figure that out so quickly. I've been staring at that formula for sometime now. I'm impressed. My mind just went, "BOOM!" I understand but I'll still have to study it a bit(no pun in tended) to take it in. Do you have any recommendation for reading material and/or videos that would help so that I could further my studies on the topic you just explained?

 
Posted : 25/02/2017 10:55 pm
Michael Rideout
Posts: 18
Active Member
 

I'm not sure about further reading. I'm a computer programmer by education and trade, so I was already familiar with things like most significant bit, most significant byte, least significant byte, most significant nibble, least significant nibble, little-endian, big-endian, etc. When I looked at the page you mentioned and saw the bit representations for Data Low (%0000yyyy) and Data High (%0000xxxx), it was obvious that "Low" and "High" refer to least significant and most significant, respectively. And to be honest, if those bit representations hadn't been included then my initial guess would have been that Data = 128 * x + y, where x and y are both 7-bit values (because MIDI data bytes don't normally use all 8 bits, since bit 7 is a flag). But Data Low and Data High are both represented as having 4 "usable" bits-- i.e., yyyy and xxxx, which are positioned in the low nibbles of their respective data bytes-- suggesting that Data Low is the Low Nibble of Data, and Data High is the High Nibble of Data, such that the hexadecimal notation for Data would be $xy, or binary %xxxxyyyy, or decimal 16*x+y. 🙂

 
Posted : 26/02/2017 12:35 am
e
 e
Posts: 5
Active Member
Topic starter
 

M.R., I really appreciate you taking the time to post here. I do have another question if you don't mind.
At the bottom of page 50 (and it continues on page 51) in the user manual in the section Event: Note ON/OFF with Fraction and Decimal there is the formula x+y=duration. Would it be safe to say that the Duration Low and Duration High is what you just explained in your previous post? Where x+y=duration should be x*128+y=duration? I think I understand but could I trouble you for a simple example in the way you did previously with x*16+y=data?

Also, this slightly off topic but related, recently I was doing some research on bits, bytes, binary, data, and the way it's condensed so as to be more familiar with what you explained in the previous posts. Late at night, I found a video that referenced a formal term that used the term "condensed" and "bit." (I was tired and didn't book mark it.) I thought it was useful information. At any rate, for the life of me I can't seem to find that term again. I'm not asking about the video, I was just wondering if you know of a formal term that uses a three letter abbreviation that references condensed bit data or the like?

 
Posted : 26/02/2017 7:57 am
Michael Rideout
Posts: 18
Active Member
 

To address your second question first, I'd have to see the discussion to be sure what it's talking about. I don't recall ever hearing of a compression method that works at the bit level per se, but then I never studied compression techniques.

Of course, in programming it's not uncommon to take a byte of memory and use it to store more than one variable. You can see this in some of the data bytes of the FB-01, where the binary representation shows two or more variables in a single byte-- e.g., on page 53, for byte $0B of the Voice Data Format, the binary representation is given as %0wxyz000, so that's four separate variables compressed into a single data byte. I've been out of the programming picture for a bit, but as far as I know this sort of thing isn't usually seen in modern-day programming, since (1) memory is so cheap and plentiful these days, and (b) today's high-level programming languages usually have a bit variable type. Thus, for the most part, modern programmers no longer need to write routines for bit-masking and bit-shifting a data byte in order to isolate a particular bit or group of bits from the byte.

Also, when working with numerical characters (i.e., digits), a programmer might want to "pack" or compress the digits. Decimal numbers use 10 digits (0 to 9), and a nibble can hold a value from 0 to 16, so two decimal digits can be packed into one byte.

As for your question about Duration Low and Duration High, I believe you're correct, since Duration Low has 7 data bits (%0yyyyyyy). It looks like Yamaha is using the plus symbol to indicate concatenation, at least in the cases of Data Low/Data High and Duration Low/Duration High. If that's correct, "x+y" basically means "concatenate the x data bits and the y data bits together, in that order"-- i.e., %xxxxxxxyyyyyyy, or %xxxxyyyy, or %xxyyy, etc., according to how many x bits and y bits there are.

In general, the number you'd multiply the x value by will depend on how many y bits there are, since that will determine which bit position the x bits start in. In this case you could use the following formulas when sending a desired Duration Value to the FB-01:

DurationValue = the value you want to use for the note's duration
DurationHigh = int (DurationValue / 128)
DurationLow = DurationValue - 128 * DurationHigh

A more general formula could be as follows:

MyValue = the value you want to split up into low and high parts
MyWidth = the number of bits that the low part should have
MyHigh = int (MyValue / 2 ^ MyWidth)
MyLow = MyValue - 2 ^ MyWidth * MyHigh

Of course, that's just pseudocode, as I have no idea what MaxMSP code looks like.

You could write a generalized function or routine like that, but I'd think it would be simpler to just have specific formulas for specific variables.

 
Posted : 26/02/2017 12:44 pm
Michael Rideout
Posts: 18
Active Member
 

Sorry, I should have said (a) and (b), or (1) and (2), not (1) and (b). :p It's too bad we can't edit our posts to correct typos. 🙁

 
Posted : 26/02/2017 12:47 pm
e
 e
Posts: 5
Active Member
Topic starter
 

M.R., I can't thank you enough for your help. I really appreciate it. With the info you gave me I feel I can understand the manual so much better now. I don't want to monopolize your time and continuously bombard you with asinine question and requests. I think I'll try going forward from here with what I know now. So, I'll leave the this thread with Thank you, Thank you Thank you. d(^^ )

 
Posted : 26/02/2017 7:23 pm
Michael Rideout
Posts: 18
Active Member
 

You're welcome, noisekrux! 🙂 And feel free to ask more questions as they arise; it's no trouble for me.

 
Posted : 27/02/2017 1:26 am
Share: