A byte has 8 bits. A bit is just a switch On or Off - 0 or 1
1111 1111 is the 8 bits grouped as two 4 bit nibbles. A nibble can have a vale of 0 to 15
Hexidecimal (hex) uses 0 1 2 3 4 5 6 7 8 9 A B C D E F to describle these 16 values so our byte can be shown as FF with each nibble = 15
As the BC can use both decimal or hex, it uses $ to mean a hex number.
$FF
$10 = 16
Midi defines two types of bytes, Status byte with the Most Significant bit set and the data byte with it cleared.
Status 1xxx xxxx
Data 0xxx xxxx (x= 0 or 1)
The first Status bytes have the lower nibble for the channel (0 to 15 = channel 1 to 16)
1000 xxxx = $8x NoteOff channel xxxx
1001 xxxx = $9x NoteOn channel xxxx
1010 xxxx = $Ax Polyphonic Key pressure channel xxxx
1011 xxxx = $Bx Continious Controller channel xxxx
etc
the $Fx messages are special and don't have a channel as the second nibble.
The other type of byte is Mid data and can have a value of 0 to 127.
So for example, after a sysex message start $F0 you can't have a byte with bit7 set (bit0 is the least significant bit) until the End of Sysex $F7
To get get bigger numbers than 127 you need to combine two (or more) 7 bit numbers and in Midi it is generallt 2 bytes and you think of this as a single 14 bit wide number xx11 1111 1111 1111 but really it is x111 1111 x111 1111
This means you can count from 0 to $3FFF or 16383 in decimal.
If this is a bit confusing grab my converted on my web site
http://www.bwalk.com.au/Convert/Convert.htmlSo the byte on the left is the Most Significant byte (MSB) and yes you guessed it, the one on the right is the Least Significant byte (LSB)
"....
in the midi manual part2 is 20 and part 16 is 60...what are the other parts"
You might like to grab the MC909 editor. All of the Roland editors I have have the out going Midi message displayed (in hex) in the top to the right.
The patch parameter addressing is a bit confusing. It is a two byte number
11 00 tt pp is the Patch on Part 1 and tt is the tone (20, 22, 24, 26) and pp is the parameter
11 20 tt pp Part 2
11 40 tt pp Part 3
11 60 tt pp Part 4
12 00 tt pp Part 5
12 20 tt pp Part 6
12 40 tt pp Part 7
12 60 tt pp Part 8
13 00 tt pp Part 9
13 20 tt pp Part 10
13 40 tt pp Part 11
13 60 tt pp Part 12
13 00 tt pp Part 13
13 20 tt pp Part 14
13 40 tt pp Part 15
13 60 tt pp Part 16
"add 00 20 00 the first Tone of four.....
why not starting from patch info?"
This is the way Roland gives the address of the parameters. The gaps in the address are often used in later devices so there is backward compatibility to earlier gear. Very smart of Roland.
Take the start of the Part and add the Tone Offset to get to the start of
that tone in
that Part.
Add the offset to get the parameter of
that tone in
that part.
"This parameter needs 2 bytes, so if you sent............
why 2bytes?"
Check page 12 of the Midi spec Roland
The value is divided into two data bytes (0000 aaaa is the MSB and 0000 bbbb is the LSB) because the range is 0 to 127 plus more to use 1/4, 1/8 etc notes of the current tempo..
"$F0 $41 $10 $00 $59 $12 $11 $00 $20 $0A $01 $0A Checksum $F7
Now the parameter is set to $1A - see page 12 up the top.....
why $1A...??"
As above 1 = MSB and A= LSB.
The lower nibble of the MSB becomes the upper nibble of the value and the lower nibble of the LSB is the lower nibble of the value.
"| 00 03 | 000a aaaa | Tone Random Pitch Depth (0 — 30)
...those 000a aaaa...what they signify? we have the offset address wich is enough to write a string...or not?"
000a aaaa just shows which bits could be set in byte 'a' of the value. t has nothing to do with the address.
So the max number for this parameter is $1F or 31 decimal.
So the max value possible in a byte looks like 0aaa aaaa or 0 to 127
In the tone delay you had 0000 aaaa (MSB) and 0000 bbbb (LSB) so the max number of either byte is $0F or 15 so $00 to $FF but you can't have $FF for a data byte as bit7 is set for numbers greater than $7F.
So you break it into 2 nibbles and place it into 2 bytes hence the aaaa and bbbb.
"
last
question: shoundn't i send sysex from mc909 to midiox and start and
correct messages (and then resend them to the bcr2000 via your
software)? in other words: seen that many times there is no
correspondance between what is sent by the mc909 and what the BCR2000
send, should i trust what sysex the mc909 sends?"
I'm a little confused here. Why are you sending Sysex from the MC909?
You are not using LEARN on the BC here. You are programming it directly.
At any rate check out the MC909 editor and look at the displayed output sysex strings.
The editor is really a graphic version of what you want the BC to do.
All the best
Royce
