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: Is there any way to (one more question)...?

2008-11-08 by Mark van den Berg

--- In bc2000@yahoogroups.com, "islandgroove2002"
<islandgroove2002@...> wrote:
> first of all when a BC first starts up it has initial values that all 
> snap to the position they were saved as part of the preset. I am 
> wondering if it is possible to set each preset so that it has no 
> initial value when the preset is first initialized so that for 
> example the faders on the BCF would not jump to a position when the 
> device was turned on.

> Second, and this is the one that is causing me the most grief, when a 
> knob, button or fader is adjusted and then you switch to another 
> preset, the values that were last changed in the previous preset are 
> saved so that when the preset is selected again the values jump to 
> how they were last set.

I can't think of any structural way of preventing the BC's behavior in
both these situations: as long as it remains switched on, the BC
maintains the current values for all 32 memory presets: whenever a
preset gets selected, the controls are updated to these current
values. So in effect the 32 presets work like one "super-preset": the
user can switch between presets without ever losing the current values
of the individual presets. (As far as I know, it doesn't matter in
this respect whether you use "standard output" (.easypar) or "custom
output" (.tx/.minmax) definitions.)

One thing you CAN do on the BCF is prevent a FADER from physically
moving to its current ("old") value upon preset selection: in BC
Manager, go to the "General" tab in the fader dialog box and set
"Sync" to "Move" (or possibly "Pickup"). However, note that
"internally" the fader still gets set to the "old" value (so e.g. a
subsequent snapshot sent from the BCF will contain this old value,
irrespective of the "Sync" setting). See the "Motor" and "Override"
sections in "BC MIDI Implementation.pdf" for further details.

A further idea concerning your "power-on problem": you can select
which preset becomes active on power-on: in BC Manager, go to the
"Parameters" tab in the "Global setup" dialog box and set "Startup
preset". So if you make "Startup preset" point to an empty preset
(i.e. one containing no element definitions), you can at least be
certain that the faders never jump when you switch the BCF on.
Obviously you would then have to select a "functional" preset manually
AFTER power-on, but in your case that might indeed be more convenient.

> The problem with that for me is that I may select a conflicting 
> snapshot of values to be transmit while using a different preset and 
> then when I go back to the preset, it snaps to the last adjusted 
> values milliseconds before I send it a burst of entirely different 
> values from my computer so sometimes there is a conflict between the 
> values stored at preset change and the values sent from the computer.

Can you somehow build in a delay between preset selection as such and
sending your subsequent "burst of values from the computer"? Of course
this won't prevent the irritating fader movement etc., but at least
the BCF/R would have enough time to complete its updates before it is
confronted with any data from the computer.

Apart from that, the only solution I can think of would be to always
send a complete preset definition to the BC at the moment when you
currently send your "burst of values" from your computer. However,
leaving aside the question whether you could make your software do
that, BC preset definitions (in "BCL") are extremely lengthy, so I
guess that would be very impractical anyway.

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.