Bc2000 (for the BCF2000 & BCR2000)

BC Manager 1.4.0 is now available from the Yahoo group's file section
(under "Applications").

New features (among others):

Several file "importing" and "exporting" facilities. 

The "Set" operation can now be applied to several more items:
- Preset settings like "Encoder groups", "Request" etc.
- Individual LEARN and Custom output items.
- The Value 1 and Value 2 parameters of standard CC, NRPN, AT and
GS/XG output.

There are also quite a few optimizations. For details, see the
accompanying manual.  

Enjoy!
Mark.

Awesome job, Mark!
Thanks for the many improvements!
I was able to select my 6 presets for my vfx and save them as 1 .syx
file and was successful at dumping back to bcr using midiox!
This should make transferring complex presets much better.
Well done! 


Love that scroll bar in the bcl, thanks!
I loaded selected presets into the bcl.  When I select 11-16 presets,
they all load but so does the 0 preset which is tacked on the end. Was
that your intention?

Thanks so much!



--- In bc2000@yahoogroups.com, "Mark van den Berg" <markwinvdb@...> wrote:

>
> BC Manager 1.4.0 is now available from the Yahoo group's file section
> (under "Applications").
> 
> New features (among others):
> 
> Several file "importing" and "exporting" facilities. 
> 
> The "Set" operation can now be applied to several more items:
> - Preset settings like "Encoder groups", "Request" etc.
> - Individual LEARN and Custom output items.
> - The Value 1 and Value 2 parameters of standard CC, NRPN, AT and
> GS/XG output.
> 
> There are also quite a few optimizations. For details, see the
> accompanying manual.  
> 
> Enjoy!
> Mark.
>

--- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@...> wrote:
> I loaded selected presets into the bcl.  When I select 11-16 presets,
> they all load but so does the 0 preset which is tacked on the end. Was
> that your intention?

Yes:

When sending presets to the BCF/BCR, BC Manager first sends (to use
your example) memory presets 11-16, then preset 0 (the temporary
preset). This is necessary for restoring preset 0 to the current
values maintained by BC Manager, because preset 0 on the BCF/BCR is
used as a gateway for presets 11-16.

So when I developed the BCL editor window, it seemed logical to copy
this behavior - which is why preset 0 is appended. The idea is that
the user can edit the BCL text, then send it directly to the BCF/BCR
with the same "automatic" restoration facility of preset 0.

But I admit that in other situations (such as yours) it might be
easier to leave out preset 0 at the end. I can build in an
on/off-switch in the BCL editor window's menu, or simply add another
menu-item that leaves out preset 0.

I assumed that you simply wanted to export a SINGLE preset at a time,
so then you can simply use preset 0 itself for this - then you
obviously don't get an extra, appended preset.

HOWEVER (in fact, this makes all my above blabbing a bit pointless):
you can also export presets directly from the preset list window - in
that case you DON'T get the extra preset 0 !

A related, conceptual issue:
If you export presets 11 to 16 to a single syx file, the output file
by definition contains $store (11/12/etc.) statements: doesn't this
conflict with your philosophy of preset files that are totally
flexible (e.g. for Mac users etc.)? I mean: it would be "dangerous"
for a user to upload a file containing fixed memory presets directly
to the BCF/BCR, since it would overwrite BC's memory presets. To
guarantee this particular type of "total flexibility", only a file
containing a single temporary preset would be possible.
On the other hand, files containing memory presets are no problem for
users of e.g. BC Manager; in fact, it would be simpler than having
multiple files: the user simply creates an additional B-Control
context, opens the file containing the memory presets into that
context, and then copies and pastes the presets to the desired
locations in the B-Control context linked to the actual BCF/BCR.

Before I forget: thanks very much for your videos! (To anybody else
reading this: NO, this is not what you're thinking...) I'll look at
them as soon as I can; in particular: as soon as I have installed
shockwave flash: last week I had a harddisk crash - it's already taken
me about two days to install a new OS plus my main applications...

Mark.

--- In bc2000@yahoogroups.com, "Mark van den Berg" <markwinvdb@...> wrote:
>
> --- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@> wrote:
> > I loaded selected presets into the bcl.  When I select 11-16 presets,
> > they all load but so does the 0 preset which is tacked on the end. Was
> > that your intention?
> 
> Yes:

Ok - I was just wondering.

> 
> When sending presets to the BCF/BCR, BC Manager first sends (to use
> your example) memory presets 11-16, then preset 0 (the temporary
> preset). This is necessary for restoring preset 0 to the current
> values maintained by BC Manager, because preset 0 on the BCF/BCR is
> used as a gateway for presets 11-16.
> 
> So when I developed the BCL editor window, it seemed logical to copy
> this behavior - which is why preset 0 is appended. The idea is that
> the user can edit the BCL text, then send it directly to the BCF/BCR
> with the same "automatic" restoration facility of preset 0.
> 
> But I admit that in other situations (such as yours) it might be
> easier to leave out preset 0 at the end. I can build in an
> on/off-switch in the BCL editor window's menu, or simply add another
> menu-item that leaves out preset 0.

I don't think that is necessary.

> 
> I assumed that you simply wanted to export a SINGLE preset at a time,
> so then you can simply use preset 0 itself for this - then you
> obviously don't get an extra, appended preset.


Yes - that makes sense.

> 
> HOWEVER (in fact, this makes all my above blabbing a bit pointless):
> you can also export presets directly from the preset list window - in
> that case you DON'T get the extra preset 0 !


Yes - and that is what I did!  Great!


> 
> A related, conceptual issue:
> If you export presets 11 to 16 to a single syx file, the output file
> by definition contains $store (11/12/etc.) statements: doesn't this
> conflict with your philosophy of preset files that are totally
> flexible (e.g. for Mac users etc.)? I mean: it would be "dangerous"
> for a user to upload a file containing fixed memory presets directly
> to the BCF/BCR, since it would overwrite BC's memory presets. To
> guarantee this particular type of "total flexibility", only a file
> containing a single temporary preset would be possible.

Yeah - I thought about this. Yes I do want flexibility, however, I
also want simplicity more. My philosophy on flexibility was more for
me, the creator of the preset. 
I don't want a user to get bogged down with the details of where and
what so much.  (Granted - I don't know if anyone has even downloaded
this preset or ever will!) Unless you are a programmer or really into
this stuff, you are a musician and you don't want to know, you want
the tools to help you do you work, not how they work.  I am just
trying to make it streamlined for that person. I have made it easy.
Download the .syx send it with whatever sysex utility you have.  If
you are on a mac no problem, just send it, it just overwrites 11-16.
Also - I warn in several places, in red and bold that it will do this
and to make sure you have backed up your presets.
I also encourage them to try bcmanager. 

I remember finding the mackie preset two years ago and learning that I
had to send a separate .syx the store.syx files to get the preset
saved. This was a bit cumbersome and unsettling. This was before I
know what I know now.  Do we want users educated? Resounding Yes!
However, how much music have I made sense finding that preset?
Then getting so into mackie emulation, building my own translator,
then finding your program and building a few presets.  I know you
understand.

So my using presets 11-16, I would have liked to use 1-6 to be the
most obvious, however, the all controls are on 1 usually...  So 11 =
voice 1, 12=voice 2 etc.  Makes it easy to see (bcr led readout) which
voice you are on and 11 is pretty far down the line of presets to not
interfere with most other stuff that might be on a bcr. 
I know, I know... but life is compromise.


> On the other hand, files containing memory presets are no problem for
> users of e.g. BC Manager; in fact, it would be simpler than having
> multiple files: the user simply creates an additional B-Control
> context, opens the file containing the memory presets into that
> context, and then copies and pastes the presets to the desired

Yes - I see this as a great solution. For the user of bcmanager. 
I need to do another short flash movie on this and capturing sysex for
synth control.  

> locations in the B-Control context linked to the actual BCF/BCR.
> 
> Before I forget: thanks very much for your videos! (To anybody else
> reading this: NO, this is not what you're thinking...) I'll look at

Hahahahaha.
Yeah I put them in the files section there.
They are also on my site.
I used a program called Wink. However, they were my first with that
program and the mouse moves around somewhat erratically.  Perhaps my
next one will be a bit more stable.

> them as soon as I can; in particular: as soon as I have installed
> shockwave flash: last week I had a harddisk crash - it's already taken
> me about two days to install a new OS plus my main applications...

Bummer, I hate that.

Again, thanks for all the changes.
Kip

--- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@...> wrote:
> I used a program called Wink. However, they were my first with that
> program and the mouse moves around somewhat erratically.

Yeah, I noticed that. Glad to hear it wasn't because of my computer
(at least in this case!).

> Perhaps my next one will be a bit more stable.

I've been wondering: can you edit a video after you've recorded it?
Cut certain scenes, replace them etc.? Or is it just a "one-go" deal?

I have played your first video, but I only got as far as the bit about
the "Invalid model" message: in the video you treat it as a "fact of
life", but of course it's something that shouldn't happen, and since
someone else reported something similar a few weeks ago, I've now
spent quite some time studying this problem:

I think this error message can occur ONLY (but correct me if I'm
wrong) if "Startup detection" has been set to "Verify identity...".
The problem is probably caused by an Identity Reply message coming
back from e.g. a BCF too late, namely when BC Manager has already sent
an Identity Request to e.g. a BCR: BC Manager is then expecting a
reply from that BCR, not any more from the BCF.

So if you get this error message regularly, you might try increasing
"Waiting time" in the "Detect B-Control options" dialog box (accessed
from the main window's Options pull-down menu). Let me know if this
helps - if it doesn't, there is something even more sinister going on...

Related to this, and perhaps even more important:
If a BCF or BCR reports back too late during a full connection scan
(cf. "Scan enabled MIDI ports"), this may cause the assignment of an
invalid "MIDI output port", as displayed in the B-Controls window. So
if the "Identity" column in the B-Controls window is empty for one of
your B-Controls, and if running "Receive identity" doesn't fix this
(i.e. if you get no reply), it might mean that the previous full
connection scan has assigned the wrong MIDI output port. You could try
to correct this manually (via MIDI -> Options in the B-Controls
window), or set "Waiting time" to a higher value and run "Detect
B-Controls" manually.

Version 1.4.1 (or 1.5.0!) will probably have an increased default
waiting time, so that these problems become much less likely to occur.

Mark.

--- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@...> wrote:
> Yes - it can be edited, however, it should probably be shot again.
> By shot i mean winked. 
> Wink <http://www.debugmode.com/wink/download.php> is what I used to 
> created the "getting started" vids.
> I was still learning how to use this program and how to record mouse
events.
> 
> You apparently don't like what I have done...

Haha, I didn't say that! Basically I was just curious, and I was
wondering what problems I would cause you if I changed something
fundamentally in BC Manager that would require a change to one of your
videos...

> I do _/not/_ get the error on Verify.
> All works fine on Verify - however, that is after I have already
detected.
> When I do *"scan enabled ports  *" I get the Midi sysex error wrong 
> model address 004962B8.
> This happens every time  I do this when "scan" is on.
> "If I go to "verify" all is well.
> Also - I don't have a  BCF, just a BCR, so I cannot comment on multiple 
> devices.

> Ok - "scan"  I set wait time from 300, 500, 1000 and still get the same 
> error on startup.
> So - ?

It would appear that it is not a timing problem then, if you still get
it at 1000 msec. E.g. my own BCF and BCR (connected via USB) tend to
respond within 10 msec, so even 100 should be more than enough in most
situations.

> What is the default on first run? none, verify or scan?

During the first run (i.e. if BCMan.ini doesn't exist yet) BC Manager
 version 1.4.0 performs a full scan using 100 msec per MIDI output
port. So this scan sends an Identity Request to the first MIDI output
port, then listens for 100 msec on all MIDI input ports, then sends an
ID request to the next MIDI output port, etc.

What I still don't understand is how you can get "wrong model" during
scans, since the scan's Identity Request messages are generic, and the
routine processing any replies should accept both BCF and BCR.
(That's why I thought the "wrong model" error could only occur during
the "verify" operation: that operation specifically targets all the
previously defined BCFs and BCRs, and does produce "wrong model" if
e.g. a BCF responds when a BCR has been targeted.)

Just some ideas:

- Do you get the same error message when you execute "Detect
B-Controls" from the MIDI pull-down menu of the B-Controls window? If
you do, you could first start "Record" in the "MIDI input messages
(general)" window (open via the main window), then execute "Detect
B-Controls", upon which any actual incoming MIDI SysEx response
messages should be recorded in the MIDI input messages window - I'd be
very interested in the actual response message(s). And what happens to
the B-Controls list, in particular the "Identity" column?

- Do you have some other Behringer device (non-BCF/BCR, perhaps a
BCA2000?) that might produce this error?

- Is there some strange loop in your setup, possibly because of your
BCR's U-mode or MIDI cables, or your MIDI Yoke setup?

- What USB driver are you using for your BCR? Windows' standard "USB
Audio Device" or Behringer's 1.1.1.0/1.1.1.1/1.2.1.3? (Yeah, I know,
I'm getting desperate...)

Mark.

--- In bc2000@yahoogroups.com, "Mark van den Berg" <markwinvdb@...> wrote:
>
> --- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@> wrote:
> > Yes - it can be edited, however, it should probably be shot again.
> > By shot i mean winked. 
> > Wink <http://www.debugmode.com/wink/download.php> is what I used to 
> > created the "getting started" vids.
> > I was still learning how to use this program and how to record mouse
> events.
> > 
> > You apparently don't like what I have done...
> 
> Haha, I didn't say that! Basically I was just curious, and I was
> wondering what problems I would cause you if I changed something
> fundamentally in BC Manager that would require a change to one of your
> videos...

Don't sweat the vids... let your program develop as it may.
We the users will adapt as necessary.

> 
> > I do _/not/_ get the error on Verify.
> > All works fine on Verify - however, that is after I have already
> detected.
> > When I do *"scan enabled ports  *" I get the Midi sysex error wrong 
> > model address 004962B8.
> > This happens every time  I do this when "scan" is on.
> > "If I go to "verify" all is well.
> > Also - I don't have a  BCF, just a BCR, so I cannot comment on
multiple 
> > devices.
> 
> > Ok - "scan"  I set wait time from 300, 500, 1000 and still get the
same 
> > error on startup.
> > So - ?
> 
> It would appear that it is not a timing problem then, if you still get
> it at 1000 msec. E.g. my own BCF and BCR (connected via USB) tend to
> respond within 10 msec, so even 100 should be more than enough in most
> situations.
> 
> > What is the default on first run? none, verify or scan?
> 
> During the first run (i.e. if BCMan.ini doesn't exist yet) BC Manager
>  version 1.4.0 performs a full scan using 100 msec per MIDI output
> port. So this scan sends an Identity Request to the first MIDI output
> port, then listens for 100 msec on all MIDI input ports, then sends an
> ID request to the next MIDI output port, etc.
> 
> What I still don't understand is how you can get "wrong model" during
> scans, since the scan's Identity Request messages are generic, and the
> routine processing any replies should accept both BCF and BCR.
> (That's why I thought the "wrong model" error could only occur during
> the "verify" operation: that operation specifically targets all the
> previously defined BCFs and BCRs, and does produce "wrong model" if
> e.g. a BCF responds when a BCR has been targeted.)
> 
> Just some ideas:
> 
> - Do you get the same error message when you execute "Detect
> B-Controls" from the MIDI pull-down menu of the B-Controls window? If
> you do, you could first start "Record" in the "MIDI input messages
> (general)" window (open via the main window), then execute "Detect
> B-Controls", upon which any actual incoming MIDI SysEx response
> messages should be recorded in the MIDI input messages window - I'd be
> very interested in the actual response message(s). And what happens to
> the B-Controls list, in particular the "Identity" column?

Mark, I am no following you.
I have attempted, it just does not seem to scan anything unless, I
restart, then I can't record the midi.
If I close all the devices, then scan it does not do anything.
If I then add a bcr, then go to scan it does not do anything, until i
restart he prog, then I can't recored because record is not recording
until I open the program.
Ok got it... working... the detect ...

results -

bcr2000(1) 183.533 sysex 20 followed by data "F0 00 20 32 00 15 02 42
43 52 32 30 30 30 20 31 2E 31 30 F7"
Midi Yoke NT:1  183.639 sysex 8 data "F0 00 20 32 7F 7F 01 F7"

You are on to something with midiyoke....
Let me disable that port from the scan.

You have it!

When all midiyokes are disabled in, MidiDevices menu, the there is no
scan error.

So... unless we disable those midiyoke midiports we will get that
error. Let me try it with just midiyoke2... the answer is yes. The
error returns with midiyoke2 enabled.  Now the message comes from
Midiyoke NT:2. 
So it scans the first midiyoke port gets the error than leaves it.
Try it.
My bcr mode is U-1.
I don't have my midiyokes routing to anything. They are just installed.

Kip

> 
> - Do you have some other Behringer device (non-BCF/BCR, perhaps a
> BCA2000?) that might produce this error?
> 
> - Is there some strange loop in your setup, possibly because of your
> BCR's U-mode or MIDI cables, or your MIDI Yoke setup?
> 
> - What USB driver are you using for your BCR? Windows' standard "USB
> Audio Device" or Behringer's 1.1.1.0/1.1.1.1/1.2.1.3? (Yeah, I know,
> I'm getting desperate...)
> 
> Mark.
>

--- In bc2000@yahoogroups.com, "k5kip_1999" <k5kip_1999@...> wrote:
> results -
> bcr2000(1) 183.533 sysex 20 followed by data "F0 00 20 32 00 15 02 42
> 43 52 32 30 30 30 20 31 2E 31 30 F7"

This is a "Send Identity" (reply) message (cf. the command byte "02")
from a BCR (cf. the "15").

> Midi Yoke NT:1  183.639 sysex 8 data "F0 00 20 32 7F 7F 01 F7"

This is an "Identity Request" message (cf. the command byte "01"),
with generic Device (cf. the first 7F) and Model (cf. the second 7F) IDs.

> You are on to something with midiyoke....
> Let me disable that port from the scan.
> 
> You have it!
> 
> When all midiyokes are disabled in, MidiDevices menu, the there is no
> scan error.
> 
> So... unless we disable those midiyoke midiports we will get that
> error. Let me try it with just midiyoke2... the answer is yes. The
> error returns with midiyoke2 enabled.  Now the message comes from
> Midiyoke NT:2. 
> So it scans the first midiyoke port gets the error than leaves it.
> Try it.
> My bcr mode is U-1.
> I don't have my midiyokes routing to anything. They are just installed.

First of all I should mention that I have never had time to try MIDI
Yoke yet, so I can't help you much in that area.

However, your results confirm what I suddenly realized after our
previous correspondence last Friday: the "Wrong model" message during
scans can be a result of a FEEDBACK loop from a MIDI output port to a
MIDI input port:

BC Manager scans for BCs by sending an "Identity Request" message to
each MIDI output port, then listens on all MIDI input ports for the
chosen "waiting time". The idea is that any connected BC replies with
a "Send Identity" message.

However, if the original Identity Request is returned to BC Manager
(via a feedback loop), this produces the "Wrong model" error message.
In fact, this error message is "correct" - it's just a bit uninformative.

In the upcoming BC Manager (vs. 1.5.0), I've improved the message you
get upon this type of feedback: BC Manager 1.5.0 actually reports that
there is a feedback loop, and even tells you which path this loop
takes, i.e. from which MIDI output to which MIDI input port.

So in your case the "wrong model" error message must indeed have been
caused by a feedback loop via MIDI Yoke: BC Manager's Identity Request
message is indeed the F0 00 20 32 7F 7F 01 F7 which you've reported.

To what extent this feedback loop is serious or not and what you can
do about it, is another matter. Just try BC Manager 1.5.0 when it
comes out, then we'll see further - but in general I'd say: problem
solved.

Mark.