Bc2000 (for the BCF2000 & BCR2000)

B0 63 0C B0 62 00 B0 06 00 B0 26 DT

I'm also trying to use sysex but am stumped. This is the Format for an ASM or Prosynth:  
    F0  system exlusive status
    00  Marion Systems manufacturer id...
    00  ...
    59  ...
    01  MSR-2 product id, use 7F as ALL IDs identified
    01  MSR-2 ASM product member,use 7F as ALL IDs identifier
    dd  ASM device id, use 7F as ALL IDs identifier
    pp  ASM message type, 4 =Request Data, 3 =Set Data
    tt  ASM data type, 0=global,1=preset,2=layer,3= tuning table,4=patch map,5=velocity curve,6=patch name,7=parameter
    mm  ASM data 14-bit number msb
    ll  ASM data 14-bit number lsb
    ... data, one 14-bit value per byte
    F7  End of system exclusive message

This is the format for parameter value data:
F0 00 00 59 01 01 dd 03 07 pm pl vm vl ...F7

Thanks for your help.  I'm still learning sysex.  Also, it doesn't help that the synth crashes when sending a sysex message (probably cause I'm doing something wrong). - Frank

ASM System Exclusive Specification
    F0  system exlusive status
    00  Marion Systems manufacturer id...
    00  ...
    59  ...
    01  MSR-2 product id, use 7F as ALL IDs identifier
    01  MSR-2 ASM product member, use 7F as ALL IDs identifier
    dd  ASM device id, use 7F as ALL IDs identifier
    pp  ASM message type, 4 = Request Data, 3 = Set Data
    tt  ASM data type, 0 = global, 1 = preset, 2 = layer, 3 = tuning table, 
                       4 = patch map, 5 = velocity curve, 6 = patch name, 
                       7 = parameter
    mm  ASM data 14-bit number msb
    ll  ASM data 14-bit number lsb
    ... data, one 14-bit value per byte
    F7  End of system exclusive message

Thanks for the info.  It will take me a little time to absorb. Thank you for your time on the matter.  Just curious, I stumbled upon this doing a search and interested me as I'd like to use NRPN messages since the Prosynth is known to be buggy with respect to parameter changes using sysex.  Is this possible?  See below:

"Hi All

So I found I can get -ve values into Miniak via a bcr but not quite as I
 would like it. I wonder ... can the "push encoder", or indeed one of 
the buttons be programmed to take a NRPN value and add a large offset to
 it (click adds on 16184 say?). Here's why I want this:


1] if I extended my code to take two hex values, then suddenly the NRPN stuff becomes clearer

I was passing say 0x241 as a NRPN value from midi-ox.
Of course the C# correctly interprets this as 0x2 x 0x100 + 0x41.
But Midi-ox is infact display 7bit values

IE this should be 0x2 x 0x80 + 0x41 !!

2] Therefore I put midi-ox on the output and could see I _can_ get -ve NRPNs on BCR2000

Set low to be 0, high to be 16384 for NRPN 0xc say (OSC1 waveshape)

Then, 0 -> 100 gives waveshape 0, 100.
Then a massive gap ...
Then from 16284->16384 the -ve values appear :-).

If we could ask the nice people at Berhinger to give a new s14 (for signed 14 bit) that would solve this issue completely.
Then we set the min to be 0x7f1c which is -100 in 7 bit hex (or more simply -100 as a decimal!)" 


-Frank




On Thursday, March 27, 2014 1:26 AM, "rpcfender@..." <rpcfender@...> wrote:
 
  
So from that site 
http://feldkir.ch/MSR-2%20SYSEX.txt

ASM System Exclusive Specification F0  system exlusive status 00  Marion Systems manufacturer id... 00  ... 59  ... 01  MSR-2 product id, use 7F as ALL IDs identifier 01  MSR-2 ASM product member, use 7F as ALL IDs identifier dd  ASM device id, use 7F as ALL IDs identifier pp  ASM message type, 4 = Request Data, 3 = Set Data tt  ASM data type, 0 = global, 1 = preset, 2 = layer, 3 = tuning table,  4 = patch map, 5 = velocity curve, 6 = patch name,  7 = parameter mm  ASM data 14-bit number msb ll  ASM data 14-bit number lsb ... data, one 14-bit value per byte F7  End of system exclusive message So I guess, to adjust a parameter you use
F0 00 00 59 7F 7F 7F 03 07 MSB_Param LSB_Param MSB_Value LSB_Value F7

Assuming the data is sent the same as the MSR-2
"14 bit signed numbers are used to transmit data values. These are transmitted
by sending the most significant 7 bits first and the least significant 7 bits
last. Bit 14 represents the sign bit.
"

my guess is ....
99 = $00 63
98 = $00 62
...
2  = $00 02
1  = $00 01
00 = $00 00
-1 = $7F 7F
-2 = $7F 7E
...
-98 = $7F 1E
-99 = $7F 1D
These are not continuous values as 0 won't wrap around to $7F 7F 
To get the BC to handle negative numbers in a continuous way it needs to use an extra bit (ie in this case 15bits)

99 = $01 00 63
98 = $01 00 62
...
2  = $01 00 02
1  = $01 00 01
00 = $00 00 00
-1 = $00 7F 7F
-2 = $00 7F 7E
...
-98 = $00 7F 1E
-99 = $00 7F 1D

With a minimum of $00 7F 1D and a max of $01 00 63
and ignore the first byte when you output the message (val 7.13 and val0.6 are the BC commands for the data)
It can't do this as it can only handle 14bits.
If only the 14th bit was not used for negative there is a way to fudge the negative number.
This is the same problem as I have for Emu Morpheus and I have never been able to create a solution.

Try using MidiOx and building a sysex parameter message to make sure that your synth does function that way.

All the best
Royce

Thanks Royce!  It's looking like I may have to buy the BCR2000 soon.  I'm sure there could possibly be other controllers (haven't heard of any others) that can do what you describe (i.e. using 2 knobs, one for the positive, the other for the negative values), but the sheer quantity of knobs on the BCR2000 is very appealing.  From what I've read, it seems like it can control anything.  Thank you for your time.  I've learned alot from you.  Best regards, Frank





On Thursday, March 27, 2014 8:23 PM, "rpcfender@..." <rpcfender@...> wrote:
 
  
The problem is that you can use 14 bits to represent numbers from 0 to 16,383 or -8192 to 8191
Midi doesn't care what you thinking the number means, but being continuous range on steps is the problem
Lets look at the binary numbers as we are talking about bits. 14 bits is 00 0000 0000 0000

This is what you need the BC to do (counting down)
00 0000 0000 0011  = 3
00 0000 0000 0010  = 2
00 0000 0000 0001  = 1
00 0000 0000 0000  = 0
11 1111 1111 1111     = -1   is really taking 1 away from 0 and so we loop back to all '1's
11 1111 1111 1110     = -2   ... continue counting down 
11 1111 1111 1101     = -3

This is what it does (counting up)
00 0000 0000 0000  = 0
00 0000 0000 0001  = 1
00 0000 0000 0010  = 2
..
01 1111 1111 1110     = 8190  
01 1111 1111 1111     = 8191  
10 0000 0000 0000   = -8192   a big jump right in the middle of the range
10 0000 0000 0001   = -8191   , but only because we think of it as negative number
..
11 1111 1111 1110     = -2   
11 1111 1111 1111     = -1   

We fool the BC into being continious by using an extra bit that won't appear in our final outputted value
1 000 0011  = 131 but we think of it as 3
1 000 0010  = 130 but we think of it as 2
1 000 0001  = 129 but we think of it as 1
1 000 0000  = 128 but we think of it as 0
0 111 1111   = 127 but we think of it as -1 
0 111 1110   = 126 but we think of it as -2 
0 111 1101   = 125 but we think of it as -3

This works for any number as long as you have that extra bit.
Although we are thinking the range is -3 to 3, we make the range of numbers the BC counts from 125 to 131.
Then we ask the BC only to output the lower 7 bits with the command val0.6 - (the value but only use bits 0 to 6 of the 14bit value)
Suddenly we have continuous positive and negative numbers with 0 at the center.

Unfortunately the biggest range the BC can cope with is 14 bits, but we need 15bits to make the 0 appear in the middle of the range.

So wether is it sysex or NRPN the problem remains.
You can, however, either have it jump from 8191 to -8192 in the middle of the range, (but that won't work for -99 to 99 range) or you can use two encoders.
Enc1 range 0 to 99
Enc2 range 16284 to 16383 (-99 to -1) or you reverse it .to go from -1 to -99

Sorry.
Royce