Bc2000 (for the BCF2000 & BCR2000)

This is long and unwieldly to explain:

If I program a knob on the BCR to adjust a NRPN, it sends the NRPN every 
single darn time the value changes, rather than just sending the NRPN 
and stepping the value up and down with Midi CC#6 messages thereafter 
(which the Midi spec lets you do and save lots of bytes).  That means 
that when I twist the knob, this gets emitted (synth is on Midi channel 
9, which is 8 in hex numbered from zero):

B8 63 00
B8 62 6E
B8 06 0C

B8 63 00
B8 62 6E
B8 06 0D

B8 63 00
B8 62 6E
B8 06 0E

B8 63 00
B8 62 6E
B8 06 0F

B8 63 00
B8 62 6E
B8 06 10

...etc, on and on.

Basically, looking at this, it sends B8 (Midi CC to channel 9)...
then 63 (Midi NRPN LSB)...
then zero because the LSB is not used here...

Then B8 again (Midi CC to channel 9)...
then 62 (Midi NRPN MSB)...
then 6E (the actual NRPN we're selecting, 6E hex, 110 decimal)...

Then B8 again (Midi CC to channel 9)...
then 06 (common vanilla data entry slider CC)...
then whatever the current data entry slider value is as the knob turns.

That's what we're seeing above.

Here's the dilemma:

I do understand the intention of Behringer in doing it this way.  It 
makes it so you can turn more than one knob at once, and the receiving 
synth can still understand all of the data coming into it even though 
it's having more than one of its parameters adjusted at the same time.

To explain, NRPN's allow you to just send the first two lines:

B8 63 00
B8 62 6E

only once, and then continuously adjust with a stream of the third line 
by itself.  So you would use the six bytes you see above to select a 
parameter on the synth (such as filter cutoff), and then from there on 
any incoming data entry slider messages will adjust that parameter 
without you having to send the six NRPN bytes again.  In other words, it 
remembers the parameter you last selected, and from there, Midi CC#6 can 
do all the work.

But a knob controller wants to be able to let you twist knobs freely and 
adjust more than one parameter at a time, which would lead to things 
getting blended to together in the data stream, and it's probably just 
easier for Behringer to make a NRPN identify itself in full every time a 
parameter is adjusted just to keep confusion down for the receiving 
synth, and to encourage better realtime tweaking.

However, I'm trying to do this on an Ensoniq ESQ-1, a synthesizer from 
the late 80's.  It was actually one of the very first synthesizers to 
even support remote editing with NRPN's.  As with any bleeding edge 
feature in anything, its implementation barely works.

In the ESQ-1, all of this excessive selecting and reselecting the 
parameter is just making the data stream thicker and confusing the CPU. 
Ensoniq probably never imagined that people would someday want to be 
able to blend streams of multiple NRPN's on the same transmission. 
After all, that's why the Midi spec says you can just select once and 
edit with data entry slider CC's afterward -- because they figure you'll 
do that, rather than sending the full NRPN parameter select for every 
single byte-step of the parameter's value.  We today in our world of 
knob controllers see the value of doing it, but they probably didn't.

This causes the ESQ-1 to behave erratically and sometimes soft-reset 
itself.  The data stream is just too thick, and it can't keep up with 
it, especially with all the parameter selecting and reselecting and 
re-re-selecting it's telling the ESQ-1 to do every six bytes or so.

So the real question is, is there any way I can use the BC Manager 
software to program the BCR2000 to send a NRPN once, and then adjust 
with bare data entry CC#6 messages thereafter, even if this means I lose 
the ability to twist multiple knobs simultaneously?  I realize that the 
ESQ-1 is one of those synths that won't realtime respond to patch 
editing anyway (you have to replay the key to hear the changes), but 
that's fine.  I just want remote editing.

Sorry about the length of the post.  I tried to phrase all of this in a 
way that conveyed the information more briefly a couple of different 
times, and generally failed, so at least here you've got all the facts.

Basically, I want to setup a knob on the BCR to act like the originally 
intended use of Midi NRPN's:

Send NRPN LSB and MSB.

Then send stream of data entry slider (CC#6) messages to adjust until 
finished with that parameter.

Only send another NRPN when I want to twist another dial.


Is there any way to do all that (phew!) on the BCR2000?

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

I'm not a BC guru by any stretch of the imagination, but what I would try is programming a button to send out the NRPN msb & lsb, then use a seperate knob for the CC. Hope this helps.



On Thursday, December 12, 2013 9:56 PM, Brent Busby <brent@...> wrote:
 
  
This is long and unwieldly to explain:

If I program a knob on the BCR to adjust a NRPN, it sends the NRPN every 
single darn time the value changes, rather than just sending the NRPN 
and stepping the value up and down with Midi CC#6 messages thereafter 
(which the Midi spec lets you do and save lots of bytes).  That means 
that when I twist the knob, this gets emitted (synth is on Midi channel 
9, which is 8 in hex numbered from zero):

B8 63 00
B8 62 6E
B8 06 0C

B8 63 00
B8 62 6E
B8 06 0D

B8 63 00
B8 62 6E
B8 06 0E

B8 63 00
B8 62 6E
B8 06 0F

B8 63 00
B8 62 6E
B8 06 10

...etc, on and on.

Basically, looking at this, it sends B8 (Midi CC to channel 9)...
then 63 (Midi NRPN LSB)...
then zero because the LSB is not used here...

Then B8 again (Midi CC to channel 9)...
then 62 (Midi NRPN MSB)...
then 6E (the actual NRPN we're selecting, 6E hex, 110 decimal)...

Then B8 again (Midi CC to channel 9)...
then 06 (common vanilla data entry slider CC)...
then whatever the current data entry slider value is as the knob turns.

That's what we're seeing above.

Here's the dilemma:

I do understand the intention of Behringer in doing it this way.  It 
makes it so you can turn more than one knob at once, and the receiving 
synth can still understand all of the data coming into it even though 
it's having more than one of its parameters adjusted at the same time.

To explain, NRPN's allow you to just send the first two lines:

B8 63 00
B8 62 6E

only once, and then continuously adjust with a stream of the third line 
by itself.  So you would use the six bytes you see above to select a 
parameter on the synth (such as filter cutoff), and then from there on 
any incoming data entry slider messages will adjust that parameter 
without you having to send the six NRPN bytes again.  In other words, it 
remembers the parameter you last selected, and from there, Midi CC#6 can 
do all the work.

But a knob controller wants to be able to let you twist knobs freely and 
adjust more than one parameter at a time, which would lead to things 
getting blended to together in the data stream, and it's probably just 
easier for Behringer to make a NRPN identify itself in full every time a 
parameter is adjusted just to keep confusion down for the receiving 
synth, and to encourage better realtime tweaking.

However, I'm trying to do this on an Ensoniq ESQ-1, a synthesizer from 
the late 80's.  It was actually one of the very first synthesizers to 
even support remote editing with NRPN's.  As with any bleeding edge 
feature in anything, its implementation barely works.

In the ESQ-1, all of this excessive selecting and reselecting the 
parameter is just making the data stream thicker and confusing the CPU. 
Ensoniq probably never imagined that people would someday want to be 
able to blend streams of multiple NRPN's on the same transmission. 
After all, that's why the Midi spec says you can just select once and 
edit with data entry slider CC's afterward -- because they figure you'll 
do that, rather than sending the full NRPN parameter select for every 
single byte-step of the parameter's value.  We today in our world of 
knob controllers see the value of doing it, but they probably didn't.

This causes the ESQ-1 to behave erratically and sometimes soft-reset 
itself.  The data stream is just too thick, and it can't keep up with 
it, especially with all the parameter selecting and reselecting and 
re-re-selecting it's telling the ESQ-1 to do every six bytes or so.

So the real question is, is there any way I can use the BC Manager 
software to program the BCR2000 to send a NRPN once, and then adjust 
with bare data entry CC#6 messages thereafter, even if this means I lose 
the ability to twist multiple knobs simultaneously?  I realize that the 
ESQ-1 is one of those synths that won't realtime respond to patch 
editing anyway (you have to replay the key to hear the changes), but 
that's fine.  I just want remote editing.

Sorry about the length of the post.  I tried to phrase all of this in a 
way that conveyed the information more briefly a couple of different 
times, and generally failed, so at least here you've got all the facts.

Basically, I want to setup a knob on the BCR to act like the originally 
intended use of Midi NRPN's:

Send NRPN LSB and MSB.

Then send stream of data entry slider (CC#6) messages to adjust until 
finished with that parameter.

Only send another NRPN when I want to twist another dial.

Is there any way to do all that (phew!) on the BCR2000?

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

On Thu, 12 Dec 2013, Alexander Kytasty wrote:

> I'm not a BC guru by any stretch of the imagination, but what I would 
> try is programming a button to send out the NRPN msb & lsb, then use a 
> seperate knob for the CC. Hope this helps.

The problem would be that there are nowhere near as many buttons as 
knobs...  The ESQ-1 has about a hundred different NRPN's, enough that 
I'm really going to have to either just choose ones I want, or setup 
multiple presets in the BCR to have enough.  If every NRPN needs to have 
a button, the dilemma becomes much worse.  I suppose it would be ok if I 
could use a knob to adjust what NRPN a button emits, but that's probably 
not possible.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

I don't know if the ESQ-1 selects its NRPN with a common Most Significant Byte (MSB) CC99 but you may only have to send it once (when you select the Preset ) or even if you have to resend it occasionally program a button to send it

Either way you could save a nearly a third of your Midi traffic.

From a switch

B8 63 00

From the data encoder
B8 62 6E
B8 06 0F

B8 62 6E
B8 06 10

From another encoder
B8 62 6F
B8 06 1F

B8 62 6F
B8 06 20

I have never tried this so let me know if it works.

Another experiment is that you could group the NRPN on a switch and increment adjacent parameters.

B8 63 00

B8 63 00

B8 63 00

B8 06 20

This means that you might only have one or two encoders with

B8 06 val

and a whole heap of selectors.

The downside is that the last data byte won't be remembered if you have changed NRPN selection.

The value will jump.

All the best

Royce

On Thu, 12 Dec 2013, rpcfender@... wrote:

> I don't know if the ESQ-1 selects its NRPN with a common Most 
> Significant Byte (MSB) CC99 but you may only have to send it once 
> (when you select the Preset ) or even if you have to resend it 
> occasionally program a button to send it

It probably doesn't need the MSB at all, but it's the BCR's way of 
sending NRPN's.  In other words, I didn't tell it I wanted this format 
of MSB,LSB,CC6...that's just what the BCR seems to do when you set up a 
knob as an NRPN.

I just wondered if there was some more customized way I could do it 
through BC Manager that would let me have more control of it than the 
way it normally assigns NRPN's to knobs.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

Use the 'Custom Output' instead of the 'Standard Output' and put in two lines for each synth parameter..

For example

B8 62 6E
B8 06 val

On Fri, 13 Dec 2013, rpcfender@... wrote:

> Use the 'Custom Output' instead of the 'Standard Output' and put in two lines for each synth parameter..
> For example
>
> B8 62 6E
> B8 06 val

I ended up doing something like this...  I setup one knob with custom 
output to send as its "value" the LSB part of the NRPN MSB/LSB pair. 
(The MSB was hardcoded as zero since it's not used.)  So the knob would 
emit: B8 63 00 B8 62 val

I setup the knob's speed in BC Manager to be 20 values per rotation to 
slow it down, since this NRPN is the part the ESQ chokes on.  (A big 
part of the reason is because the ESQ-1 insists on updating its display 
to actually show the parameter being selected when it receives the NRPN, 
so if it gets too many of them at a time, it gets way behind trying to 
keep the display updated and crashes.)  At 20 values per turn, it 
becomes harder to scroll through the parameters faster than the ESQ-1 
can keep up.  It would still have been nicer if the BCR had been capable 
of setting up one of its top row push encoders to let you select a value 
without transmitting it and then push to actually send it, but 
unfortunately they can't be made to work that way.  That way, you could 
choose a parameter from the BCR's own LED but not have to actually 
transmit Midi during the whole scrolling process...oh well.

Anyway, that took care of the actual NRPN MSB/LSB pair.  So I setup a 
second knob to simply trasmit vanilla data entry slider CC#6, which was 
the easy part, and the ESQ-1 can take that as fast as you can send it.

Between the two knobs, it's workable, though at this point, the only 
advantage you're getting out of the whole thing is the convenience that 
it's remote.  I mean really, rather than laying all your parameters out 
across a knob controller like an old analog with knob-per-function, what 
you've got here is basically a data entry slider setup where one knob 
selects function and the other adjusts its value.  This seems to be the 
best that can be done with the limitations of the ESQ-1 and the BCR2000 
though.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

"So the knob would emit: B8 63 00 B8 62 val"

Did you see if the ESQ-1 would accept a single B8 63 00 message on a button and then B8 62 xx B8 06 val with a different value of xx for each encoder?

Can you change encoders with out having to send another B8 63 00?

When you output B8 63 00 B8 62 val with an encoder I would think the ESQ might prepare by changing the screen and wait for the value message to follow. So with your method it is frantically changing pages for parameters you are not interested in changing as you scroll through???

If this does work it would give you the more old school feel to the synth that you are after.

Try it and let me know if it accepts it.

It certainly works on my Roland FantomS.

You can also use Midi running status

B8 63 00 B8 62 02 B8 06 14

is the same as

B8 63 00 62 02 06 14

so the button would still have MSB

B8 63 00

but the encoder would have LSB and Value

B8 62 02 06 val

Yea !! one less byte per message to save the ESQ input buffer.

Or back to the original

B8 63 00 62 xx 06 val

(Strictly speaking you should end each RPN/NRPN change with B8 64 7F 65 7F to cancel the NRPN, but I like to live dangerously.)

Royce

On Fri, 13 Dec 2013, rpcfender@... wrote:

>> "So the knob would emit: B8 63 00 B8 62 val"
>
> Did you see if the ESQ-1 would accept a single B8 63 00 message on a 
> button and then B8 62 xx B8 06 val with a different value of xx for 
> each encoder?

No...but the only reason I didn't try that is because most of the delay 
is created by the ESQ-1 updating its display every time a NRPN is 
received to make it select a parameter, switching to a whole different 
screen if necessary, and trying to repaint the screen several times a 
second if the NRPN's come in rapidly.  If I was to put any part of the 
NRPN on the same encoder that's sending the data entry slider CC's, that 
NRPN would get resent for every change of value as the knob turns and 
you'd have the same problem (the display goes bonkers and the ESQ-1 
can't keep up).  It doesn't matter because it seems to need a whole 
MSB/LSB pair anyway, but if it worked with LSB alone, it'd still end up 
repainting the display, just with fewer Midi bytes to get it done.

What would be needed is a feature I don't think the BCR has (BC Manager 
seems to have implemented everything it can do, and I don't see this 
feature anywhere in it):

It would be nice if the BCR let you setup a string of custom bytes *as a 
header*, to be sent once at the beginning of a knob rotation, and not 
repeated again until the knob stops turning.  That would let you have 
your cake and eat it too...  You could have lots of knobs that each spit 
out a single NRPN message (or whatever you wanted) when you start 
turning them, but then they be quiet about the NRPN and just send their 
main code for as long as you keep turning.  If you grab a different 
knob, it sends the header code for that knob, and then does the same 
thing sending that other knob's regular code only instead of putting the 
NRPN code into every single value change.  That's what you'd really need 
to do this.

I think Behringer doesn't allow that because it would create the 
situation where the user would need to be warned that if you setup your 
controller this way, there will be no turning two knobs at once for that 
synth.  You can't blend together two simultaneous tweaks unless every 
single parameter change that gets sent is also paired with a NRPN 
parameter select that lets the target device know what that particular 
parameter change is supposed to be an adjustment of.  It makes every 
parameter change effectively end up being nine bytes long of course, but 
at least then you can grab two knobs at once and tweak yourself silly 
(on a modern synth that can keep up with it, and isn't trying to repaint 
its screen every time it gets a NRPN).  And you can even turn two knobs 
at the same time.  By not supporting a header feature like this, 
Behringer's tech support doesn't have to explain anything because it 
can't do it anyway.

Considering that Behringer won't even fix BCEdit to make it as nice as 
BC Manager is, I think they're basically at the point where they'd like 
to just make money on the BCR and BCF and not really make any more 
improvements, so we're probably not going to see any "header code" 
feature added (or anything else) now.

> Can you change encoders with out having to send another B8 63 00?

I did try that...  It needs a full MSB/LSB pair to select a parameter on 
the ESQ-1, even though the MSB is always zero.  So you send "B8 63 00 B8 
62 val" to select something, and the ESQ-1 updates its display, but 
anything less doesn't do anything at all.

> When you output B8 63 00 B8 62 val with an encoder I would think the 
> ESQ might prepare by changing the screen and wait for the value 
> message to follow. So with your method it is frantically changing 
> pages for parameters you are not interested in changing as you scroll 
> through???

Yes, but at least the way I've set it up now, I have it broken up into 
two different knobs, and only the parameter selection knob does that. 
Once you find your parameter, the other knob just sends data entry, and 
it has no problem with that.  Also I've setup the first knob to have 
only 20 values per rotation in BC Manager, so it keeps me from flipping 
through parameters too fast.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

On Sat, 14 Dec 2013, rpcfender@... wrote:

> You can certainly set up the button encoders on the the top row.
> The Button part for the parameter select and the encoder as B8 06 val.
> Although it means all the encoders are the same and therefore redundant, the user interface would be simpler.
> You get 4 groups of 8, so that is 32 parameters at least.
> The two rows of switches give you another 16  and then you can use any top row encoder for the value.
> Have the other controls for CC messages.
>
> You can halve the bytes by programming the encoder to output one 
> message if turned clockwise and another if it is turned 
> counterclockwise.
>
> .tx ifp B8 06 val ifn  B8 63 00 62 xx 06 val
>
> xx is the NRPN parameter number not "xx"
>
> Turn counterclockwise and you get the full message clockwise you get 
> just the value.
>
> Not good bet workable.
>
> The ideal for a lot of these old synths is an interpreting program in between.
> The BC outputting CC messages to give the parameter number in a map and a value to change into a NRPN.
> Then you can, of course, get the computer to request the bulk data and send out CC messages to the BC and it will sync up to the synth.

Wow, I never knew BC script went that far beyond what's available in BC 
Manager.  This will be gime more to experiment with...

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky