Behringer provides a mackie LCD emulator called BCFview that can be used to dislay the current track assignments when using the BCF2000 in mackie LC mode.
- Get the exe here http://www.behringerdownload.de/B-Control_download/BCFview.zip
2, Ensure that you have wine installed and test it with: wine bcfview.exe
Right click in bcfview and choose the BCF2000 INPUT as the connection.
Start an ardour3 session with > 7 tracks. You will need to cycle the bank buttons at least once to get it to sync.
It does not currently display any timecode info or shuttle status, etc. However, this track listing feature is really the most useful.
You can also move the bcfview.exe to an executable path and modify the ardour3 script to start it automatically.
Simply replace the exec line with something like this to prevent opening it multiple times:
if [ -z “$(pgrep BCFview)” ]
exec /opt/BCFview.exe & /opt/ardour3_local/lib/ardour3/ardour-3.0 “$@”
exec /opt/ardour3_local/lib/ardour3/ardour-3.0 “$@”
Here is a screenshot in action:
Ahh so this was what you had a quesiton on last night? I take it you got your answer?
I was trying to activate timecode part. I located the bool in bcf_surface.h and I also put in display_timecode the same as in the mackie code. I fooled around with it for a bit and gave up because it occurred to me there haven’t been many commits to this since boost. If someone has a real MCU and can confirm that the existing code works on the real deal I would be inclined to chip at it some more.
I think there may be an issue with the sysex being different between the MCU and the bcf. I didn’t dig far enough to see if the code is querying this from the device or if it’s hardcoded to the MCU.
I think it’s supposed to display the jog mode, which is really the only thing I’m interested in.
It does display the Jog mode. There is a difference in how it handles the BCF vs the MCU, due to the different number of faders, etc. This should probably be handled cleaner however as there are now other surfaces with other amounts of faders (1, or 4, come to mind) that need to be supported as well, not to mention things like extenders etc. So pretty much this code is overdue for an overhaul and I just don’t have time to do it.
The code determines which surface is is dealing with via the ‘mode’ set in the config file for Ardour.
Yeah I see a lot of hardcoding of strips and things that might need to be changed to max_strips rather than checking get_mackie_emulation() a zillion times.
Question still is, do we know as of today, is the display code working with real MCUs? Do you know anyone who has one that might be using it with the alpha binaries?
The display code is working in A2. I do not believe much about Mackie is working in general with the alphas, I suspect there is some major problems with MIDI handling when talking about the MCU that I have discussed some with Paul but not had time to look into yet. Namely the way MIDI port writing is handled is very different from ALSA and JackMIDI, specifically buffering of the writes, and as a result I suspect we are getting some overflow/truncation problems at anything close to low latencies.
Thanks for the insight. Wow. I didn’t even think about things being busted on that level, but I forgot that A2 was using ALSA.
Well, I can say I’m just pleased as I can be that I’m able to use the BCF at all and this little LCD emulator really enhances that experience. I’ll give it a try with A2 and see what works there.
Thanks for all your hard work!