Bc2000 (for the BCF2000 & BCR2000)

Hi everyone,

Due to various reasons, it's taken "a little" longer than expected,
but finally here it is:

BC Manager version 1.0 is now available from the Yahoo group's Files
section, in the shape of a zip-file in the folder "BC Manager". Please
read the accompanying manual for installation instructions and further
information.

Features include:
- Full control of the BCF2000 and BCR2000, including custom MIDI
message definitions
- On-screen tables of all presets, buttons, encoders, faders and their
parameters
- User-friendly graphical editing of all parameters, including
extensive cut-and-paste facilities and bulk editing
- Various printing facilities
- Extensive set of MIDI communication tools

By the way: hopefully I'll also be able to post an upgraded version of
the MIDI Implementation document in the near future.

Mark.

Mark,

BC Manager is very nice. I loaded it and it seems to work from the 
things I tried. Thanks very much for writing this and making the code 
available to us.

I have a couple of questions.

1) When you edit the parameters for a preset, there is something to 
check about LEARN. What is that?

2) When you using the encoder or button table. Is there a way to change 
the parameters of just the selected encoders to change just the channel. 
for example? It seems that even when you select several rows, you can 
only change the parameters for one encoder at a time.

Thanks again,

Howard

Mark van den Berg wrote:

> 
> 
> Hi everyone,
> 
> Due to various reasons, it's taken "a little" longer than expected,
> but finally here it is:

Mark,welcome back

I can now see why you have been absent from this forum.
A lot good work here. A big 'thanks' for all the effort.

I had a quick tour and it looks to be very complete and I love that
when you reopen the editor it is in the same layout that you closed it in.
Is there a place where the script is visible/editable?

Royce



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

>
> Hi everyone,
> 
> Due to various reasons, it's taken "a little" longer than expected,
> but finally here it is:
> 
> BC Manager version 1.0 is now available from the Yahoo group's Files
> section, in the shape of a zip-file in the folder "BC Manager". Please
> read the accompanying manual for installation instructions and further
> information.
> 
> Features include:
> - Full control of the BCF2000 and BCR2000, including custom MIDI
> message definitions
> - On-screen tables of all presets, buttons, encoders, faders and their
> parameters
> - User-friendly graphical editing of all parameters, including
> extensive cut-and-paste facilities and bulk editing
> - Various printing facilities
> - Extensive set of MIDI communication tools
> 
> By the way: hopefully I'll also be able to post an upgraded version of
> the MIDI Implementation document in the near future.
> 
> Mark.
>

--- In bc2000@yahoogroups.com, Howard Moscovitz <h@...> wrote:
> I have a couple of questions.
> 
> 1) When you edit the parameters for a preset, there is something to 
> check about LEARN. What is that?

Well, very complicated, in any case! As I remember, when I discovered
this feature last summer, it took me about a week to figure it out:

For each preset the BC allows you to define your own sequence of 
(max. 125) MIDI bytes. BC Manager allows you to create this sequence
via the "LEARN output" tab of the preset dialog box.

The BC will output this MIDI sequence in 2 situations:

1. When the preset gets selected (in whatever way), PROVIDED that a
particular preset parameter internally called ".request" has the value
"on". In BC Manager you can set this parameter via the checkbox
labeled "Request (i.e. LEARN output)" on the "Parameters" tab.

2. Whenever you press EDIT + LEARN.

So Behringer's idea apparently was that the MIDI bytes you define
somehow constitute a data request to which the receiving device
replies by sending "the things to learn" back to the BC, hence the
term "LEARN". However, you can of course have the BC send ANYTHING,
not necessarily triggering a response from the other device. One
obvious idea is to have the BC simply send a Program Change message
indicating that the BC has indeed selected THAT preset. So e.g. for
preset 1 you could define "$C0 $01", for preset 2 "$C0 $02", etc.

> 2) When you using the encoder or button table. Is there a way to change 
> the parameters of just the selected encoders to change just the
channel. 
> for example? It seems that even when you select several rows, you can 
> only change the parameters for one encoder at a time.

As you have already found out, the "E" button or the "Edit" menu item
indeed simply edits each selected encoder IN TURN. To set just the
channel of a range of encoders, use the "Set" submenu under the "Edit"
pull-down menu: there you can select the parameter of your choice
(like "Channel") that you want to change in one go for all the
selected encoders. A dialog box pops up in which you can select the
new channel, and even more sophisticated: if you check the "Increment"
box, the FIRST encoder gets set to the channel you've indicated, but
the second becomes 1 higher than the first encoder, and so on. Beware:
you may not actually see the channels change in the encoder table if
"Type" is "None". But you can set "Type" in a bulk operation as well,
so that can be easily fixed...

Mark.

--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:
> I can now see why you have been absent from this forum.

Yeah, well, after I had publicly announced a deadline of "end of
August" and missed it, I entered into a state of mind where I thought
that all my efforts should be directed towards the program.
Consequently I went into some kind of hermitation (is that a word?),
although it may have looked like I "had done a runner".

I must say that I'm very impressed how you have been taking on the job
of helpdesk (and shame on Behringer and all those other companies who
DON'T offer any post-purchase assistance for their products!),
considering your expertise and unending efforts towards all kinds of
extremely technical questions concerning particular MIDI devices.

Still, I did feel guilty sometimes for not engaging in some of the
discussions that concerned me. But looking back over the last year, I
estimate that I've spent some 2000 hours reverse-engineering the BCF
and BCR, writing the MIDI implementation document, and BC Manager. Not
quite healthy... So as you can imagine, during the last few months I
sometimes got so mentally fed up with the whole project that I
sometimes didn't work at it for weeks.

In any case I can promise that from now on I won't disappear for six
months again, although right now I feel like opening a bottle of wine
and getting incredibly drunk to celebrate "finishing" BC Manager, so I
might be writing rather jolly replies to questions about BC Manager
for a few days...

> Is there a place where the script is visible/editable?

I presume you mean the BCL "source code": you can open a "BCL editor"
window (one for each B-Control) from the "View" pull-down menu of the
"B-Controls" window.

A note to clear up a potential incomprehensibility you may run into:
if you perform "Receive global setup" or "Receive temporary preset"
from the "BCL editor" window's "MIDI" pull-down menu, you can only see
the B-Control's response in the (GLOBAL) "MIDI input messages: BCL"
window. You can open this window via the "BC Manager" (main) window's
"View" pull-down menu (via the "MIDI" submenu); you must also press
the "Record" button in that window before any response is actually
recorded/displayed.

By the way, checking this feature for you now I've just discovered the
first slight inconsistency in this version of BC Manager: in the "MIDI
input messages: BCL" window, the "Stop" menu item should be grayed
(disabled) by default. (For how could you stop before you've started?)
Ah well, I should be able to publish version 1.0.1 before the end of
August...

Mark

Hello Mark,

I own a BCA2000. I assume the midi interface of the BCA is the same as 
the other BCx devices. I use it to connect to a Behringer FCB1010. I 
use an application called Ripwerx. It is able to do a looptest using a 
large sysex message. (see FCB1010 UNo group here in yahoogroups). Are 
you aware of such a limitation in the behringer midi interface 
implementation or is this an error by Mike Reilley the programmer of 
Ripwerx. 

I have another application, able to send an sysex to the FCB1010 over 
the BCA2000

I'm not sure this is an application or software incompatibility.

Thanks for reading,


Frans van den Berge
info at muziekschuur.nl

--- In bc2000@yahoogroups.com, "muziekschuur" <fvandenberg@...> wrote:
> I own a BCA2000. I assume the midi interface of the BCA is the same as 
> the other BCx devices. I use it to connect to a Behringer FCB1010. I 
> use an application called Ripwerx. It is able to do a looptest using a 
> large sysex message. (see FCB1010 UNo group here in yahoogroups). Are 
> you aware of such a limitation in the behringer midi interface 
> implementation or is this an error by Mike Reilley the programmer of 
> Ripwerx. 
> 
> I have another application, able to send an sysex to the FCB1010 over 
> the BCA2000
> 
> I'm not sure this is an application or software incompatibility.

I've looked at your correspondence with Mike in the FCB1010uno-group.
(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.)

The MIDI setup you're using is quite complex: the MIDI data flows
through several software and hardware layers. The fact that Dixon's
editor does go well would seem to indicate that it's a problem at
least in part related to Mike's program. But the problem might lie
elsewhere too. For one thing, the FCB1010 is notorious for its quirky
handling of MIDI data.

To make a comparison (as you're suggesting) between the BCA2000 and
the BCF/BCR2000 is somewhat tricky, since the BCF/BCR2000 operate in
several different connection modes. I don't know how the BCA works in
this respect, so it's perhaps not immediately clear what any test
results actually mean. However, for what it's worth, I've just done a
small experiment that might be relevant:

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.

It turned out that SysEx messages of 1020 bytes or longer (counting
the starting F0 and finishing F7 as well) were returned incorrectly.
In fact, the longer the message, the more bytes disappeared. So a
message of 1019 bytes was returned correctly, but in case of 1020
bytes, the return message was only 1017 (!) bytes long (in fact, the
terminating F7 was missing, so the Windows MIDI input driver returned
an error saying "invalid MIDI message". And a SysEx message of 5000
bytes returned as 4984 bytes, so 16 were swallowed.

So the SysEx handling of the BCF/BCR2000 (or its drivers) indeed seems
faulty, and it would be interesting for you to do a similar experiment
with your BCA2000 to see if the exact same limitation exists. (Just
leave the FCB1010 out of the loop, to avoid complications.)

One other thing you might try: does the Ripwerx looptest to the
FCB1010 go well when you route it through the MIDI I/O ports of a
standard (non-USB) MIDI computer interface (e.g. a cheap, standard
sound card) instead of the BCA2000?

Mark.

This is simply incredible. Thanks very much for making this available 
for free. I look forward to trying it out!

fab


--- In bc2000@yahoogroups.com, "Mark van den Berg" <markwinvdb@...> 
wrote:
>
I
> estimate that I've spent some 2000 hours reverse-engineering the BCF
> and BCR, writing the MIDI implementation document, and BC Manager. > 
Mark
>

Hi Mark

> (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?

> 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) ?

I found the USB to be very slow, but I'm not sure if it is hardware or
the driver. Surly it is interrupt driven so I guess it is more likely
to be the driver.

Do the Mac folk out there have trouble??????

Royce

--- 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.

Thanks for the clear and detailed response, Mark.

--Howard

Mark van den Berg wrote:
  To set just the

> channel of a range of encoders, use the "Set" submenu under the "Edit"
> pull-down menu: there you can select the parameter of your choice
> (like "Channel") that you want to change in one go for all the
> selected encoders.

--- In bc2000@yahoogroups.com, "fas1piano" <fas1piano@...> wrote:
> Thanks very much for making this available 
> for free. I look forward to trying it out!

"You're welcome" is the polite reply here, I suppose...

But talking about the fact that BC Manager is freeware:
Maybe some 9 months ago, when I announced that I had started writing
BC Manager, someone in this group suggested that he'd even be
interested if I made it shareware. I have never really considered
this, for several reasons, all amounting to the feeling that it would
be more trouble than benefit: setting up a method for payment,
building in a registration method, trying to prevent piracy. Perhaps
most importantly: I would simply not feel comfortable asking money
from people I consider, in some abstract way, "my friends".
Relationships between me and the other members in the group would get
subtly "different". And what about the people who have (in whatever
way) contributed to the program? Royce for instance, or that German
guy who wrote the first report on the BCF/BCR's MIDI implementation:
shouldn't they get a share of the profits too? And people might get
more reluctant to contribute to the program in the future (pointing
out bugs or making suggestions for new features etc.), for in a sense
they would then become some kind of unpaid employees. Maybe I'm
exaggerating a bit, but I would find this all a bit unpleasant - so
that's why BC Manager is free.

Another, perhaps more interesting point related to the time it's taken
me to write BC Manager:
Some months ago there was a discussion in this group about Behringer's
lack of further development of anything related to the BCF and BCR.
Just imagine that they had ordered one of their employees to further
develop BC-Edit in such a way that it had got to the level of BC
Manager: considering the amount of time it has taken me, this might
have taken a full year's work, so it might have required an investment
(in terms of salary) of maybe 70.000 euros (i.e. over US$100.000
nowadays). They would have had to sell a lot of BCFs and BCRs to get
that investment back! I don't condone their lack of commitment, but I
do think that this clearly demonstrates the core of the problem: they
simply stopped all development once the allotted budget was spent -
it's just the way these companies work. Behringer may be a LITTLE
worse than most others, but they're certainly not alone: I've had
similarly frustrating experiences concerning my Boss GS-10 guitar
multi-effect processor: when I sent a list of bugs in the firmware and
software, I never even got a response back from Roland/Boss.
So I'm afraid we'll be left to our own devices, in all respects...

Mark.

Great idea in principle. My problem is I a not a paypal member and I 
am not sure whether to trust them. Would there be an alternative 
payment method (visa or master card)?

I will also admit that I hope for a more extensive manual in the 
future, I am just too awkward it seems...

fab


--- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@...> wrote:
>
> Hi Mark
> 
> > But talking about the fact that BC Manager is freeware:
> > Maybe some 9 months ago, when I announced that I had started 
writing
> > BC Manager, someone in this group suggested that he'd even be
> > interested if I made it shareware. I have never really considered
> > this, for several reasons, all amounting to the feeling that it 
would
> > be more trouble than benefit: setting up a method for payment,
> > building in a registration method, trying to prevent piracy. 
Perhaps
> > most importantly: I would simply not feel comfortable asking money
> > from people I consider, in some abstract way, "my friends".
> 
> I've been thinking about this since I opened my mouth and mentioned 
that
> themaker4 shouldn't charge for his efforts (Msg #712)
> I think perhaps I was wrong.
> 
> The thing about 'free' software for me is that, I was going to 
produce
> it anyway for my own use, so it isn't a big deal if someone else 
uses
> it.
> The time it took to code has been paid for by solving a problem I 
had.
> 
> There are other programs I have written for free.
> These are ones that, although they are useful for someone, require 
very
> little time to produce.
> 
> Your situation is somewhat different.
> You could have written all the presets you ever wanted with the 
tools
> that were available already.
> This is not true of many others that find it new or a bit difficult 
and
> benefit from the editor.
> The code you produced is sizable and clearly has it has taken a long
> time and skill to produce
> 
> Professional musicians are traditionally poor (that's why I learned 
to
> code and to design electronic gear that I couldn't afford to buy) 
which
> is why I like 'if you can afford to pay something then great, if not
> then just have fun' and seems the way to go.
> 
> Hopefully enough people who can afford it will respond and there 
will be
> enough money to justify any new features and the support for 
everyone.
> 
> The open source community is great, but if you need a bug fix or a 
new
> feature right now, it is a bit rich to demand that the programmer
> respond straight away when he/she needs to make some money 
elsewhere to
> survive.
> 
> Strangely the open source guys do respond very quickly, but that is
> usually because there is at least a few of them out there.
> For a single coder the burden is substantial.
> 
> > Relationships between me and the other members in the group would 
get
> > subtly "different". And what about the people who have (in 
whatever
> > way) contributed to the program? Royce for instance, or that 
German
> > guy who wrote the first report on the BCF/BCR's MIDI 
implementation:
> 
> I'm happy for you to charge/get donations to help support this 
product.
> I think you have already been very generous with your excellent BC 
sysex
> document.
> I don't think this community would feel any different.
> 
> > shouldn't they get a share of the profits too?
> 
> No. It's public domain info now (to which you have contributed
> substantially anyway).
> 
> > And people might get
> > more reluctant to contribute to the program in the future 
(pointing
> > out bugs or making suggestions for new features etc.),
> 
> Don't worry, people never get sick of telling you where you went 
wrong
> and everyone always wants extra features.
> 
> > for in a sense
> > they would then become some kind of unpaid employees. Maybe I'm
> > exaggerating a bit, but I would find this all a bit unpleasant - 
so
> > that's why BC Manager is free.
> 
> I don't think you will make a living from the editor, but it might 
help
> you to continue the development/support .
> It might enable/encourage  you to produce more editors/programs for 
the
> BCs and perhaps other gear .
> 
> It's clear the Behringer (and other gear manufactures) wont go any
> farther.
> They have an economic imperative that we don't and although it is 
value
> adding for their product I see it as becoming 'our' product.
> Clearly the Uno FCB1010 is no longer a Behringer product.
> 
> Thanks for your efforts (and don't for get the 10% commission we 
spoke
> about [:)] )
> 
> Anyone know how to setup a PayPal Donation ware button? It might be 
a

> good new thread to start.
> 
> All the best
> 
> Royce
>

Also, the "thank you Mark!" was not so much about the editor being 
free, but more about an editor that permits copy and paste and 
changing many parameters at the same time! finally...now i just need 
to understand how it all works!

fab



--- In bc2000@yahoogroups.com, "fas1piano" <fas1piano@...> wrote:
>
> Great idea in principle. My problem is I a not a paypal member and 
I 
> am not sure whether to trust them. Would there be an alternative 
> payment method (visa or master card)?
> 
> I will also admit that I hope for a more extensive manual in the 
> future, I am just too awkward it seems...
> 
> fab
> 
> 
> --- In bc2000@yahoogroups.com, "rpcfender" <rpcfender@> wrote:
> >
> > Hi Mark
> > 
> > > But talking about the fact that BC Manager is freeware:
> > > Maybe some 9 months ago, when I announced that I had started 
> writing
> > > BC Manager, someone in this group suggested that he'd even be
> > > interested if I made it shareware. I have never really 
considered
> > > this, for several reasons, all amounting to the feeling that it 
> would
> > > be more trouble than benefit: setting up a method for payment,
> > > building in a registration method, trying to prevent piracy. 
> Perhaps
> > > most importantly: I would simply not feel comfortable asking 
money
> > > from people I consider, in some abstract way, "my friends".
> > 
> > I've been thinking about this since I opened my mouth and 
mentioned 
> that
> > themaker4 shouldn't charge for his efforts (Msg #712)
> > I think perhaps I was wrong.
> > 
> > The thing about 'free' software for me is that, I was going to 
> produce
> > it anyway for my own use, so it isn't a big deal if someone else 
> uses
> > it.
> > The time it took to code has been paid for by solving a problem I 
> had.
> > 
> > There are other programs I have written for free.
> > These are ones that, although they are useful for someone, 
require 
> very
> > little time to produce.
> > 
> > Your situation is somewhat different.
> > You could have written all the presets you ever wanted with the 
> tools
> > that were available already.
> > This is not true of many others that find it new or a bit 
difficult 
> and
> > benefit from the editor.
> > The code you produced is sizable and clearly has it has taken a 
long
> > time and skill to produce
> > 
> > Professional musicians are traditionally poor (that's why I 
learned 
> to
> > code and to design electronic gear that I couldn't afford to buy) 
> which
> > is why I like 'if you can afford to pay something then great, if 
not
> > then just have fun' and seems the way to go.
> > 
> > Hopefully enough people who can afford it will respond and there 
> will be
> > enough money to justify any new features and the support for 
> everyone.
> > 
> > The open source community is great, but if you need a bug fix or 
a 
> new
> > feature right now, it is a bit rich to demand that the programmer
> > respond straight away when he/she needs to make some money 
> elsewhere to
> > survive.
> > 
> > Strangely the open source guys do respond very quickly, but that 
is
> > usually because there is at least a few of them out there.
> > For a single coder the burden is substantial.
> > 
> > > Relationships between me and the other members in the group 
would 
> get
> > > subtly "different". And what about the people who have (in 
> whatever
> > > way) contributed to the program? Royce for instance, or that 
> German
> > > guy who wrote the first report on the BCF/BCR's MIDI 
> implementation:
> > 
> > I'm happy for you to charge/get donations to help support this 
> product.
> > I think you have already been very generous with your excellent 
BC 
> sysex
> > document.
> > I don't think this community would feel any different.
> > 
> > > shouldn't they get a share of the profits too?
> > 
> > No. It's public domain info now (to which you have contributed
> > substantially anyway).
> > 
> > > And people might get
> > > more reluctant to contribute to the program in the future 
> (pointing
> > > out bugs or making suggestions for new features etc.),
> > 
> > Don't worry, people never get sick of telling you where you went 
> wrong
> > and everyone always wants extra features.
> > 
> > > for in a sense
> > > they would then become some kind of unpaid employees. Maybe I'm
> > > exaggerating a bit, but I would find this all a bit unpleasant -
 
> so
> > > that's why BC Manager is free.
> > 
> > I don't think you will make a living from the editor, but it 
might 
> help
> > you to continue the development/support .
> > It might enable/encourage  you to produce more editors/programs 
for 
> the
> > BCs and perhaps other gear .
> > 
> > It's clear the Behringer (and other gear manufactures) wont go any
> > farther.
> > They have an economic imperative that we don't and although it is 
> value
> > adding for their product I see it as becoming 'our' product.
> > Clearly the Uno FCB1010 is no longer a Behringer product.
> > 
> > Thanks for your efforts (and don't for get the 10% commission we 
> spoke
> > about [:)] )
> > 
> > Anyone know how to setup a PayPal Donation ware button? It might 
be 

> a
> > good new thread to start.
> > 
> > All the best
> > 
> > Royce
> >
>

Never miss a thing. Make Yahoo your homepage.

--- In bc2000@yahoogroups.com, "fas1piano" <fas1piano@...> wrote:
> I will also admit that I hope for a more extensive manual in the 
> future, I am just too awkward it seems...

No, it's not you! Let's face it: the manual is just too sketchy!
After I had packaged the program, I wrote the manual in a mad,
one-afternoon dash. This was good in that it made immediate
publication of the program possible, but obviously the manual needs to
be extended. I'll see if I can write a version in which all the
features are explained one by one, window by window and button by
button - this is what I intended originally anyway. Hopefully it'll be
ready by the end of the month. (But you'll notice that I'm not saying
WHICH month!)

I'm also hoping to publish an upgraded version of the MIDI
implementation document. We'll see which one comes first...

As to the freeware/paypal business: thank you all for your kind words!
I've always been bad with money - I'll think about your suggestions
and consult one or two people, then I may come back to the issue (or
simply build in a sneaky "your trial period has expired" patch in the
next version, haha! - just kidding).

Mark.

Thanks Mark, all of this sounds excellent! Maybe a simple list with 
commands for modifying the encoders etc. would be easier to write than 
a whole manual with screenies and whatnot? anyways, thanks again for 
all these efforts!

fab