Just got a BCF2000, excited to try it out and see the faders moving with the M:C. I can get the knobs to send CC to the BCF and get the faders moving, but it looks like changing or reloading patterns does not send CC messages. This really hurts the usefulness of the motors. I contacted support. It seems like something easy to do, and I’d be happy even if the update took a bit of time, doesn’t have to be instantaneous. Just wondering if anyone else ran into this and if there are any possible workarounds.
The only Elektron device which supports this kind of synchronization for external controllers is the Octatrack. It doesn’t send CCs automatically, but you can send a CCs value request at any time to it and it answers with a bunch of CC messages.
I always have wondered why not more of their devices support this.
5 Likes
Another interesting fact I didn’t realize until I tried it a while ago on my MD and MM is that none of their devices send CC from the sequencer, apart from explicit CC params in MIDI tracks.
This is understandable as I know that MIDI is quite slow.
But even just sending them at the beginning of a pattern or when reloading the pattern would be so incredibly useful while being little effort on Elektron. If they stagger the upload over time, it shouldn’t be a great burden on the machine.
One could not only sync up motorized faders or LED encoders, but record a snapshot of the “kit” into a DAW or what have you.
1 Like
To be fair I know also no none Elektron device with at least 8 audio tracks which does this and there are good reasons for not doing it.
Doing it automatically for all CCs for all tracks would seriously jam the MIDI connection, especially when you consider all the other stuff which might need MIDI bandwidth (clock, notes from all tracks, MIDI lfos and even messages from other devices).
Running only at 31,250 bits/second there isn’t much bandwidth there in the first place (each CC requires 3 bytes). But even before the connection gets seriously jammed you would experience all kind of instabilities (notes being late etc.pp.).
BTW, there is another issue at hand: when you modulate a parameter with a LFO it will also not send a corresponding CC. When you think this through each modulated internal parameter would need to become a kind MIDI LFO itself sending a constant stream of CCs to provide full synchronization.
1 Like
Right, but a single CC for each param sent out at the moment of pattern change/load as slowly as is reasonable should not result in that much instability - let’s say it’s 32 x 6 on M:C, that’s just 384 bytes. You can send it out 4 params at a time (8 bytes), with a gap of 1ms in between, and the update would take 48ms. The gap could be as long as 5ms and it would still only take <250ms, which for the purpose would be fine.
However, I just realized that with the BCF, I don’t think it can track CC’s that are not mapped to any control on the active preset. So it might all be moot. Maybe implementing Data Request would be better, but I don’t know if the BCF can send that message, or sysex in general.
It’s 576 bytes (3 bytes each) … 
The data request on the OT is simply a CC itself. Elektron doesn’t use sysex messages, beside for backups/uploads/firmware installation.
1 Like
Ahh! My mistake 
I still think it could work on MC’s end … but, as I just added to my last post, I have no idea if it would even work as expected on the BCF side … not a huge deal, though initially disappointing.
Yeah, so it looks like Behringer didn’t think of cache-ing incoming CC’s that aren’t mapped in the current preset. But, there is a Data Request function. If Elektron added support for that to all their other devices including M:C … well what do you think? Wouldn’t that be helpful?