I removed the CSI folder and the dll and started with a fresh project, and now the EQ and comp are both responding again. If this is repeatable I have a way to proceed.

I've just checked out the files I posted with a new, completely vanilla, portable Reaper install.

I put the BCR2000 into U-4 mode (I use USB, it's S-4 if you use MIDI) and sent the sysex using MIDIOX (slow but reliable) The BCR LED did its circular thing showing it's receiving the sysex file. I saved the data into patch 1.

I created a CSI folder in the Reaper resource folder containing the fxt, axt and mst folders ( I didn't copy the folders from the CSI download) and populated them with the files from my BCR2000mk2 download.

I put the reaper_csurf_integrator64.dll in UserPlugins folder in the Reaper resource folder.

I opened Reaper, opened the Preferences window and the Control/OSC/Web option and added Control Surface Integrator. I selected it, hit edit and added one Page 'Tracks'.

Within that page I added the BCR2000 (Click Add MIDI) selected the appropriate MIDI in and MIDI out choices and made the selections for: Surface (BCR2000mk2.mst), Action (BCR2000mk2.axt) and FX (BCR2000mk2(this one's a folder)

I clicked OK all the way out of the Preferences window and quit Reaper (a bug in the windows version of CSI causes the plugin to stop working after changes are made to it's setup in the Control/OSC/Web prefs)

I started Reaper again, created a new project and added 8 tracks, one by one. As each track was added, the LED ring around the top row of encoders (to the immediate left of the LED display) lit half way (ie LEDs from 6 o'clock to 12 o'clock were on)

As Group 1 was selected on the BCR2000, the top row of encoders were controlling channel pan. The half way lit LED ring shows pan was at centre.

A single LED on each of the bottom row of controllers came on to represent the channel fader at zero. Channel level is controlled by this row of encoders.

The upper row of buttons control channel mute, the lower row, solo. The top row encoder push selects that channel (in Group 1)

I created 3 sends on a track and selected Group 2 on the BCR2000. Now the top row encoders control send level and the encoder push controls send mute. Initially send 1 is controlled across the tracks, but using the lower 2 User Buttons (bottom right on the BCR2000) you can step back and forward through the sends on a track (using the push to mute a send is a good way to remind yourself which send you are controlling)

I added a ReaEQ to a track and when its window opened, LEDs on the middle two rows of encoders lit to indicate FX parameters available for control. The lower row has EQ Gain on controls 1,3,5 and 7. The upper row has EQ Freq and Q for 4 bands across 8 controls

I selected all the tracks I had created and duplicated them 3 times. Now you can use the upper two User Buttons to bank across the tracks in jumps of 8.

Group 3 also controls channel pan, but this time the push toggles between Pan and Width.

And that's about it

If you want to gain an understanding of how the mapping works, I would suggest opening the .mst file and .axt files next to each other in text editor windows and see how the various actions are mapped to the controls and the controls have their messages defined.

The same goes for fxt files- check out how the FX parameters are mapped to controls.

Once you get the idea, you can edit the axt/fxt files to change what the buttons and encoders control and bend the setup to suit your own way of working.

Once you get the idea, you can edit the axt/fxt files to change what the buttons and encoders control and bend the setup to suit your own way of working.

Thanks for that detailed run through. Just to be clear, from you first BCR config through to now, I've never had any trouble getting this set up and working. I am also now very familiar with the contents of all the files by now

What I've been trying to communicate is that AFTER getting this set up and working the problems start. Especially when using BCR in conjunction with BCF in MCU mode.

Once it is all working, I have found that for no apparent reason, the FX will stop responding to the BCR. It's not a mapping or set up issue, as it worked just before.
Starting again from scratch with new install of CSI, BCR and new project so far is the only way I can guarantee getting it all working again.

This makes it frustrating and slow to develop mappings and scripts around CSI as I routinely find it stops working.

What would be really great is a way for me to help debug this, because I'm running blind. I don't know whether extension development easily permits writing to a log, but that would be ideal, and we could use a CSI.ini param to set the log level.

What I've been trying to communicate is that AFTER getting this set up and working the problems start. Especially when using BCR in conjunction with BCF in MCU mode.

I see. Does the issue occur if you use the BCR2000 on its own, without the BCF in the setup at all?

If you use them both together I suspect they will both be trying to control identical things- faders, pans etc. This shouldn't be a problem, but you never know.

If you just want to use the BCR2000 to just control FX, delete everything in BCR2000mk2.axt except the last line- TrackOnFocusedFX MapSingleFXToWidgetsForTrack. Then all the widgets will be available for FX control and nothing else will be controlled.

Did you manage to update the BCR2000 firmware to 1.10?

I've added BCR2000mk2.bcr to the download. I went with sysex because I thought it would be more 'universal' but if you're using BCManager (and you should be ) the file's there now.

Did you get a chance to test my BCF2000 setup? Can't do that here as I don't have a BCF2000.

Last edited by MixMonkey; 02-13-2019 at 07:04 AM.
Reason: Clarification

I see. Does the issue occur if you use the BCR2000 on its own, without the BCF in the setup at all?

If you use them both together I suspect they will both be trying to control identical things- faders, pans etc. This shouldn't be a problem, but you never know.

If you just want to use the BCR2000 to just control FX, delete everything in BCR2000mk2.axt except the last line- TrackOnFocusedFX MapSingleFXToWidgetsForTrack. Then all the widgets will be available for FX control and nothing else will be controlled.

Did you manage to update the BCR2000 firmware to 1.10?

I've added BCR2000mk2.bcr to the download. I went with sysex because I thought it would be more 'universal' but if you're using BCManager (and you should be ) the file's there now.

Did you get a chance to test my BCF2000 setup? Can't do that here as I don't have a BCF2000.

Mostly I'll try to set up both BCF and BCR, because I'm highly motivated to have them working in tandem.

Controlling the same things is not an issue. The MCU fxt folder is empty. There may be some hex value overlap between the two, but they are different surfaces on different ports. I can't see this being the issue, especially since it's intermittent.

I'm working on mappings that work for me, and yes the BCR will be mostly for fx. However the issue has been 100% around fx control actually. For instance in MK2 the fader assignment was working at the same time as fx was broken.

I will try that line, thanks. I didn't try the BCF yet, as mentioned MCU is working great, but will happily try it to help yourself and others who might want to go down that route.

I'll try again with mk2 and the .bcr, thanks. I updated to 1.10 a while back. I don't expect you to memorise all my posts, and do appreciate your efforts to help.

Mostly I'll try to set up both BCF and BCR, because I'm highly motivated to have them working in tandem.

Yes, I appreciate that, but if you're trying to troubleshoot an issue you need to remove as many potential causes as you can to get to the problem.

Quote:

Controlling the same things is not an issue. The MCU fxt folder is empty. There may be some hex value overlap between the two, but they are different surfaces on different ports. I can't see this being the issue, especially since it's intermittent.

The fact that there may be some hex overlap isn't the point. The point is that the MCU.axt and the BCR2000mk2.axt will be trying to control the same parameters. It may not be the cause of the problem but it won't hurt to remove it as a possible cause.

Mostly I'll try to set up both BCF and BCR, because I'm highly motivated to have them working in tandem.

Controlling the same things is not an issue. The MCU fxt folder is empty. There may be some hex value overlap between the two, but they are different surfaces on different ports. I can't see this being the issue, especially since it's intermittent.

I'm working on mappings that work for me, and yes the BCR will be mostly for fx. However the issue has been 100% around fx control actually. For instance in MK2 the fader assignment was working at the same time as fx was broken.

I will try that line, thanks. I didn't try the BCF yet, as mentioned MCU is working great, but will happily try it to help yourself and others who might want to go down that route.

I'll try again with mk2 and the .bcr, thanks. I updated to 1.10 a while back. I don't expect you to memorise all my posts, and do appreciate your efforts to help.

Make sure you get the latest CSI (Feb 11, I think), there was a fix in there that might affect you.

Yes, I appreciate that, but if you're trying to troubleshoot an issue you need to remove as many potential causes as you can to get to the problem.

The fact that there may be some hex overlap isn't the point. The point is that the MCU.axt and the BCR2000mk2.axt will be trying to control the same parameters. It may not be the cause of the problem but it won't hurt to remove it as a possible cause.

Good advice, but if the issue doesn't happen when just using one device, there is not much more to do than try introducing the other.

Sorry I wasn't clearer. There is no direct overlap of the controls affected. This is what I meant by the MCU fxt folder is empty - with the BCR, there is no mapping to control FX, and FX is where all the issues lie. I will use what you've said over the last couple of posts to completely eliminiate any overlap issues by reducing until found.

I am not giving up, just making the comment it could be easier to debug with some logging.

This is a surely contrived example, but I think it shows the concept, what do you think ?

I think this will work, it certainly shows the versatility of the Navigation.

So, when you enter the sub-zone, all that is on the 8 Rotaries is: Rotary1 SendXVolume, Rotary2 SendXPan, Push1 SendXPre/Post, Push2 SendXStereo/Mono and Push3 SendXPhaseInvert. Where X is the Send selected in the Previous Zone.

I think this will work, it certainly shows the versatility of the Navigation.

So, when you enter the sub-zone, all that is on the 8 Rotaries is: Rotary1 SendXVolume, Rotary2 SendXPan, Push1 SendXPre/Post, Push2 SendXStereo/Mono and Push3 SendXPhaseInvert. Where X is the Send selected in the Previous Zone.

Nope, I've been staring at Geoff's last post and the code for almost an hour and still don't quite grasp the new format. But, it was the same many months ago when i first started with CSI, and at some point it all clicked. waiting for another click....

You may be right, but am I the only one here who's lost all understanding of what it is?? ��

Quote:

Originally Posted by poetnprophet

Nope, I've been staring at Geoff's last post and the code for almost an hour and still don't quite grasp the new format. But, it was the same many months ago when i first started with CSI, and at some point it all clicked. waiting for another click....

It doesn't help that I'm editing that post every hour or so

Let's go through it.

The first Zone named Entree is just what the old .axt file was, except the Channel definition has altered slightly.

Channel is now the Zone with no name at the the end of the Entree Zone.

There is new shorthand -- e.g. Mute1-8 -- to make is easier to describe repetitive things. Instead of saying:

Mute1
Mute2
Mute3
Mute4
Mute5
Mute6
Mute7
Mute8

you can say Mute1-8, much more compact but still (hopefully) understandable.

The line:

Alt+Select1-8 GoZone TrackSplaySends

says that when you press Alt+Select5 you activate the Zone named TrackSplaySends for the Track currently on Channel 5.

Interesting question... I think if the selected Channel is on this surface, things can stay the same, the same Track is selected it has just changed positions on the surface.

Things get interesting if banking causes the selected Track to exit this surface.

I think there may be a dependancy in the code here that I don't quite understand.

I'd imagined () that when you'd Splayed Sends or FX Parameters across the MCU Rotaries, that the rest of the MCU and the 2XTs would continue to bank and function normally.

The MCU Rotaries would stay fixed on the Alt+Selected track's sends/FX until: i) The sub-zone was exited or ii) Another track was Alt+Selected.

It's not a big deal if the sub-zone exits when the track is banked off the surface. I was expecting behaviour more akin to the way the C4 stays fixed on a focussed FX when the MCU/XT/XT is banked around, only changing when the FX focus changes.

I think there may be a dependancy in the code here that I don't quite understand.

I'd imagined () that when you'd Splayed Sends or FX Parameters across the MCU Rotaries, that the rest of the MCU and the 2XTs would continue to bank and function normally.

The MCU Rotaries would stay fixed on the Alt+Selected track's sends/FX until: i) The sub-zone was exited or ii) Another track was Alt+Selected.

Yes, that's exactly how I envision it

Quote:

Originally Posted by MixMonkey

It's not a big deal if the sub-zone exits when the track is banked off the surface. I was expecting behaviour more akin to the way the C4 stays fixed on a focussed FX when the MCU/XT/XT is banked around, only changing when the FX focus changes.

That's the tricky bit.

The C4 is "dedicated" the XT/MCU rotaries are "taken over".

Let's assume you have an XT and an MCU side by side.

You Alt+Select a Track on the XT -- the XT rotaries are now Send levels.

Ok so you have a selected Track -- that means one of the 8 XT select buttons is lit up.

Now you bank so that the selected Track is now on the MCU.

The lit, selected Track is now on the MCU, but the rotaries that control the Sends are still on the XT.

If you press Alt+Select for the selected Track the rotaries on the XT will be restored to initial Zone.

If you press Alt+Select again, this time the MCU rotaries will be taken over, since the selected Track is now on the MCU.

Not consistent

I wish I could think of a way to make it more C4-ish, but I can't.

Any ideas better than exiting the Zone upon selected track leaving surface, let me know, we'll use them

This is fine Once you know this is how it works, you'll adjust accordingly. I'd just bank the track under scrutiny onto the MCU, then Alt+Select it.

Or more likely use the C4 for all these kind of things It certainly reinforces the case for having a C4/Console1 type controller in your setup.

It sure does, I used to have a C4 now I have a Console1, wish I could add a C4 as well, the C1 is killer for "the usual suspects" -- front end gain/saturation - transient shaping -- EQ -- Compression -- back end gain/saturation, but for Verbs, complex EQ's like the UAD Massive Passive, and other more esoteric processing, I wish I had my C4 back as well as the C1, it simply mapped better for those jobs

I wish I had my C4 back as well as the C1, it simply mapped better for those jobs

eBay is your friend I bought my MCU new, but everything else has come from there.

I can't believe they stopped making the C4. 32 Rotaries, each with pushes and a two line display is pretty much the optimal controller format for anything that isn't 'channel' orientated.

Actually I can believe they stopped making it, making the physical unit is one thing, expecting DAW manufacturers to provide software support for it is quite another- you end up being reliant on other companies to render your product useful.

Thank heavens the MCU protocol 'stuck', although now you have hardware/software companies like Presonus making controllers that operate in a 'Native' mode with their own DAW and using the MCU protocol as a fall back compatibility mode to make it somewhat useful to users of other DAWS, which is fair enough, I suppose. It's their ball.

Certainly better than Avid's approach, where it's completely proprietary, very expensive and obsoleted at a point of their choosing, in the hope you'll shell out £50K for another go on the merry-go-round

Question: is it at all possible to use the keyboard Alt Shift Control buttons to use in place of those on the mixer? The Qcon ProX is nice, but the button layout is not practical at all haha.

Thanks for reminding me, been meaning to look into that, it's especially useful for those with low button counts on their surface, really expands what you can do AND doesn't steal Shift/Control, etc. from your button count.

[edit] Just checked, looks like we can use at least 2 -- Shift/Control on PC -- Shift/Command on Apple, so that's a good start.