Bc2000 (for the BCF2000 & BCR2000) group photo

Yahoo Groups archive

Bc2000 (for the BCF2000 & BCR2000)

Index last updated: 2026-04-28 23:16 UTC

Message

Re: BC Manager 1.0 available now!

2008-03-04 by Mark van den Berg

--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:

>> (Perhaps I should mention at this point that I have an FCB1010 myself,
>> and I have also written my own (never-published) FCB1010 editor. I
>> don't have the uno-chip, though.)
> 
> Me too. How many editors of the FCB1010 are there?

Enough, possibly too many, apparently...

But seriously: I started writing mine at a time when there was only an
early version of Ed Dixon's editor available, which I didn't find very
satisfying.  However, in those years I was mainly occupied with
writing an editor for the Boss GS-10 (a guitar multi-effect
processor); I finally did incorporate my FCB1010 editor in the GS-10
editor (which WAS published!), but by that time there were so many
other editors available in the FCB1010 group (not to mention
Ossandust's UnO and editors for it), that I didn't publish my separate
FCB1010 editor.

>> I sent SysEx messages of varying lengths (containing only zeros in
>> between the obligatory F0 and F7) from a sequencer program (Sonar 6,
>> as it happens) to my BCF2000 via its USB MIDI connection. The BCF
>> passed these messages on to its standard MIDI Out, then that was
>> looped back directly to its standard MIDI In, and sent back to the
>> computer via the USB MIDI connection. There the messages were captured
>> by a MIDI monitoring program.
> 
> What is the MIDI byte tx rate you are testing with?
> Are there gaps between bytes or blocks or are you going flat out
> (31.25K bits per second / 10, that is 3125 bytes per second) ?

No idea. That is: I'm simply communicating with Windows' MMSystem: my
MIDI program sets up a SysEx message, then transfers that message as a
whole to MMSystem, which then (supposedly) sends the message to the
device(s).

I seem to remember that the documentation for MMSystem stipulates that
it's up to the actual MIDI device whether the actual sending occurs
synchronously or asynchronously (with respect to the program's
function call). In any case, at most you could manually postpone the
NEXT MIDI message, but as far as I know you can't do anything about
the "internal" timing within the SysEx message.

So I'm not sure to what extent time gaps is an issue here: it seems
simply a matter of buffering.

Windows' MMSystem only passes on a received SysEx message (as a whole)
to the "expectant" MIDI application (Sonar, BC Manager etc.) at the
moment the terminating F7 is received. However, the TIME STAMP that is
reported along with the message indicates the time when the FIRST byte
of the message (i.e. the F0) was received.

Now the MIDI protocol states that a SysEx message gets terminated by
ANY Status byte (>=$80), not just the standard F7
("End-of-exclusive"). In case of a terminator other than F7, MMSystem
does pass the SysEx message on, but reports it as "invalid", and
(sensibly) the terminator is NOT added to the message but becomes the
start of the NEXT message.

In the case of the truncated messages received from the BCF,
MMSystem's algorithm indeed leads to an indefinite waiting period
until the NEXT MIDI message (whatever its nature) is received.

-----------

I've now done some additional testing to find out whether it's the
BCF/BCR's INPUT or OUTPUT MIDI device that's cutting things off at
1019 bytes. The answer turns out to be that it's both:

1. When I have Sonar send SysEx messages to the MIDI output of the
standard, "cheap" sound card of my computer, and route that signal to
the input of the BCF, the result is exactly the same as I described
earlier: the BCF's input indeed has a limit of 1019 bytes per SysEx
message (and a message of 1020 bytes comes back as 1017, etc.).

2. When I send a SysEx message of 1020 bytes to the BCF's output A
(i.e. via the USB cable, of course), the situation is even more
bizarre: the message received back via my sound card consists of 1019
bytes, causing Windows' MMSystem to (correctly) report an "invalid
MIDI message" (because the final F7 is missing), followed by a
separate FE message (i.e. Active Sensing). This makes partial sense,
given the MIDI protocol about any Status byte terminating a SysEx
message; however, I don't understand at all where the FE comes from.
In any case, it seems that the BCF's output is limited to 1019 bytes
too, just as the input is.

-----------

With respect to Behringer's claims (in response to complaints from
customers) that the BCA/BCF/BCR's MIDI facilities are "only peripheral
features" or so, and that they can therefore not be expected to deal
correctly with long SysEx messages, I can only say: Humbug!
I've found that my Boss GS-10, which basically has the same set of
connections as the BCA2000 (audio and MIDI via USB, plus external
standard MIDI I/O), handles long SysEx message perfectly (at least
until the maximum length of 9979 bytes supported by Sonar 6...!). And
the BCF2000 and BCR2000 even don't have audio to send via USB, so it's
actually incomprehensible that they are limited so severely.
But in the promotional descriptions for the BC2000 series on their
website, Behringer don't particularly hold back in praising the MIDI
facilities. I think it's a disgrace, frankly. Maybe we should hire a
top lawyer and sue them!

Mark.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.