Control Surface Integration (CSI) Technical Feature Discussion

[MT4U]

Originally Posted by Geoff Waddington

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Added

ClearFocusedFXParam
ClearFocusedFX   
ClearSelectedTrackFX

Please check them out, and, if they pass, they will be added to production.

ClearFocusedFX is our manual way to provoke that "FX_Window_has_been_closed" event that the Reaper API is not triggering within CSI.

This is a game changer, Geoff.

After the FX Window is closed, if we call ClearFocusedFX, the previous zone is restored, and opening the FX Window again maps the FX Zone back again to perfection, so now I can call a script to close the FocusedFXWindow followed by ClearFocusedFX and have my cake!
Just need to remember to always close the FX Windows with a button on the MCU.

Now with a little scripting I managed to make that infamous "EQ" button on the X-Touch map my favorite EQ, going back where I was before by pressing Cancel.

Thanks a lot, man!

Now I'm gonna have to rethink a lot of things

[Geoff Waddington]

Originally Posted by MT4U

ClearFocusedFX is our manual way to provoke that "FX_Window_has_been_closed" event that the Reaper API is not triggering within CSI.

This is a game changer, Geoff.

After the FX Window is closed, if we call ClearFocusedFX, the previous zone is restored, and opening the FX Window again maps the FX Zone back again to perfection, so now I can call a script to close the FocusedFXWindow followed by ClearFocusedFX and have my cake!
Just need to remember to always close the FX Windows with a button on the MCU.

Now with a little scripting I managed to make that infamous "EQ" button on the X-Touch map my favorite EQ, going back where I was before by pressing Cancel.

Thanks a lot, man!

Now I'm gonna have to rethink a lot of things

Great stuff !!

Could you or someone else please verify that ClearFocusedFXParam and ClearSelectedTrackFX both work so that I can release these changes to production.

[MT4U]

Originally Posted by Geoff Waddington

Great stuff !!

Could you or someone else please verify that ClearFocusedFXParam and ClearSelectedTrackFX both work so that I can release these changes to production.

Haven’t tested them yet, but with ClearFocusedFX, previous zone colors are not being restored. Similar to what was going on with ClearFXSlot.

[MixMonkey]

Originally Posted by Geoff Waddington

Could you or someone else please verify that ClearFocusedFXParam and ClearSelectedTrackFX both work so that I can release these changes to production.

ClearSelectedTrackFX works (and by implication, GoSelectedTrackFX also works- we were discussing earlier)

ClearFocusedFXParam doesn't seem to do anything. I have the focused fx parameter on the MCU master fader- it follows whatever fx control I touch on the C4. Pressing a button on the MCU for ClearFocusedFXParam doesn't clear the focused fx parameter, the master fader still controls the last touched fx parameter.

ClearFocusedFX doesn't seem to work for me. I turned off the C4 fx menu and enabled FocusedFXMapping. Assigned ClearFocusedFX to a button on the C4. When pressed, I see the displays refresh but it goes back to the fx that was focused, rather than Home.

[MT4U]

Originally Posted by MixMonkey

ClearSelectedTrackFX works (and by implication, GoSelectedTrackFX also works- we were discussing earlier)

ClearFocusedFX doesn't seem to work for me. I turned off the C4 fx menu and enabled FocusedFXMapping. Assigned ClearFocusedFX to a button on the C4. When pressed, I see the displays refresh but it goes back to the fx that was focused, rather than Home.

After you close an FX Window, either manually or by script, calling ClearFocusedFX will take you back to where you were before.
If you leave the FX Window open the FX will stay mapped, that's the refresh.

[MixMonkey]

Originally Posted by MT4U

After you close an FX Window, either manually or by script, calling ClearFocusedFX will take you back to where you were before.
If you leave the FX Window open the FX will stay mapped, that's the refresh.

Interesting. I thought it was the act of focusing that caused the FX to map (ie opening an FX chain window, clicking on an open FX window) not the presence of the open window. If I close the window, the FX unmaps anyway. I haven’t managed to close an FX window without the FX unmapping, so I guess it’s difficult for me to tell

[MT4U]

Originally Posted by MixMonkey

Interesting. I thought it was the act of focusing that caused the FX to map (ie opening an FX chain window, clicking on an open FX window) not the presence of the open window. If I close the window, the FX unmaps anyway. I haven’t managed to close an FX window without the FX unmapping, so I guess it’s difficult for me to tell

Maybe you don't experience it in your workflow, I'll try to describe the situation.

If you have a surface with tracks (MCU, X-Touch) and use those very same tracks to map FX parameters and you have FocusedFXMapping enabled, when you close that FX Window, the track zone doesn't come back.

CSI doesn't know that the window has been closed. As a side effect, if you open that FX window again, CSI will not map it.

If on the other hand, after closing the FX Window you run the ClearFocusedFX CSI action, the track zone comes back properly and opening that FX window again maps it back to your tracks.

It may not seem like a big deal, but add some scripting to the equation and, for example, my EQ button checks the FX Chain and looks for any EQ from a list I have. If it finds any it opens the window, if it finds none, then adds my preferred EQ, and it gets mapped across my surface tracks.

Until now, closing that window would be a problem since CSI wouldn't return to the track zone and wouldn't map the EQ again to my tracks unless I focused a different plug-in and came back to the EQ.

I still can't have a toggle button, but I can press the EQ button and have my EQ shown or added and if I press the "Cancel" button (mapped to FX Window Close and ClearFocusedFX) all works properly and I can press the EQ button again.

That said, this means that Any button on my surface can map Any Plug-In at any given time.

I just hope I was clear enough

[MixMonkey]

Originally Posted by MT4U

Maybe you don't experience it in your workflow, I'll try to describe the situation.

If you have a surface with tracks (MCU, X-Touch) and use those very same tracks to map FX parameters and you have FocusedFXMapping enabled, when you close that FX Window, the track zone doesn't come back.

I see what you mean, and with a seperate surface to map FX to in my workflow, the issue you're describing won't arise. As long as ClearFocusedFX is doing what it's supposed to, it's all good

[Geoff Waddington]

Great testing guys !!

Ok, seems like the only unresolved one is ClearFocusedFXParam.

Is that one an issue, or is it a workflow thing ?

[Funkybot]

Originally Posted by Geoff Waddington

Great testing guys !!

Ok, seems like the only unresolved one is ClearFocusedFXParam.

Is that one an issue, or is it a workflow thing ?

I haven't had a chance to test yet - barely been in Reaper/CSI recently the last week or two - but do we need ClearFocusedFXParam? The "ToggleEnableFocusedFXParamMapping" action is a toggle already so if you want to clear, you'd just press again. Unless I'm just failing to grasp a given use-case.

[Geoff Waddington]

Originally Posted by Funkybot

I haven't had a chance to test yet - barely been in Reaper/CSI recently the last week or two - but do we need ClearFocusedFXParam? The "ToggleEnableFocusedFXParamMapping" action is a toggle already so if you want to clear, you'd just press again. Unless I'm just failing to grasp a given use-case.

That may be true, I'm not sure.

The reason I'm adding all of these is the change to eliminate the "slamming Faders".

That approach was very brute force, but it did ensure everything zeroed upon Zone deactivation.

Just want to make sure all the bases are covered if that is now not the case in certain scenarios.

[MixMonkey]

Originally Posted by Geoff Waddington

Great testing guys !!

Ok, seems like the only unresolved one is ClearFocusedFXParam.

Is that one an issue, or is it a workflow thing ?

I think ClearFocusedFXParam may not have worked for me because I don't have a FocusedFXParam Zone (!) If I haven't got the Zone, I can't leave it (I guess)

I've always had FocusedFXParameter on the MCU master fader (with a Control+ modifier)

[MixMonkey]

Originally Posted by Geoff Waddington

That approach was very brute force, but it did ensure everything zeroed upon Zone deactivation.

Any chance of losing the C4 reset between FX Zones? All my C4 FX Zones set any unused widgets to NoAction, so everything is being overwritten twice each time.

[badboynikus]

Hello guys. I'm using Reapinger, with my Behringer BCF2000. But I made mistake. I updated my CSI to 3.0. And IMPOSSIBLE to find the 1.1 version, with which my Reapinger used to works perfectly.Do you have any clue on where can I find that ? That would be lovely ! Or if you have another solution, I'm open to everything !
Cheers !

[Geoff Waddington]

Originally Posted by badboynikus

Hello guys. I'm using Reapinger, with my Behringer BCF2000. But I made mistake. I updated my CSI to 3.0. And IMPOSSIBLE to find the 1.1 version, with which my Reapinger used to works perfectly.Do you have any clue on where can I find that ? That would be lovely ! Or if you have another solution, I'm open to everything !
Cheers !

This thread is for technical feature discussion.

We have started a new thread for setup, configuration, etc.

https://forum.cockos.com/showthread....278718&page=10

Please have a look at that thread, I have provided a way for you and others to get older versions.

[badboynikus]

Originally Posted by Geoff Waddington

This thread is for technical feature discussion.

We have started a new thread for setup, configuration, etc.

https://forum.cockos.com/showthread....278718&page=10

Please have a look at that thread, I have provided a way for you and others to get older versions.

Wow, thanks a lot. I'm so dumb sometimes. I spent a LONG time looking for it, and it was in front of my eyes... The hidden letter... Thanks again !

[airon]

Those new 3.03 actions for for clearing fx stuff are very helpful. Thank you for making those.

[Geoff Waddington]

Ok, version 3.0 is stabilizing nicely, let's talk about a more formal bug reporting/resolution process.

Github has built in features for this, let's use them.

But how, exactly ?

I think it would be a mistake to just let everyone post bugs directly, often what is perceived as a bug is a configuration/setup or design/architecture issue.

We already have a thread for configuration/setup.

We already have a thread for design/architecture.

Propose we start a third CSI thread for bug reports.

Also suggest there should be a fairly rigorous process to log a bug report, it must be:

reproducible
verified by at least two people
not already reported
not a configuration/setup issue
not a design/architecture issue

If it is a configuration/setup issue, it should be discussed in the configuration/setup thread.

If it is a design/architecture issue, it should be discussed in the design/architecture thread.

Once the bug has cleared all of those hurdles, then, and only then, it will be entered into the issues area of GitHub, most likely the CSI_Install repo.

The goal is to keep the bug list tight, that way there is at least a slim chance I will be able to keep up

Thoughts, suggestions more than welcomed, the floor is open...

[Funkybot]

My first reaction is: bugs might come up in the CSI Device setup thread first anyway, like "hey, am I doing something wrong?" So maybe skip creating a new thread. Otherwise, I fear you'll have bug reports in the device setup thread, device setup questions in the bug reports thread, etc.

I'd think a good process would be:

1. Device setup thread for the "is this a bug or am I doing something wrong" discussion
2. Once confirmed by at least one other user, someone logs on the Github and/or this thread. Some of the regulars like MM, myself, MT4U could try to volunteer to play gatekeeper/reproducer rule.

[Geoff Waddington]

Originally Posted by Funkybot

My first reaction is: bugs might come up in the CSI Device setup thread first anyway, like "hey, am I doing something wrong?" So maybe skip creating a new thread. Otherwise, I fear you'll have bug reports in the device setup thread, device setup questions in the bug reports thread, etc.

I'd think a good process would be:

1. Device setup thread for the "is this a bug or am I doing something wrong" discussion
2. Once confirmed by at least one other user, someone logs on the Github and/or this thread. Some of the regulars like MM, myself, MT4U could try to volunteer to play gatekeeper/reproducer rule.

Sounds good, the setup thread already has the word bug in the title, so let's keep it that way.

Let's go ahead and use that thread to start the process with the Hardware Sends bug, can you state that bug over there ?

[spkr4thdd]

Originally Posted by MT4U

my EQ button checks the FX Chain and looks for any EQ from a list I have. If it finds any it opens the window, if it finds none, then adds my preferred EQ, and it gets mapped across my surface tracks.

Hi MT4U!

I don't suppose you could share that script? I had a similar one for channel strips, but I've purchased a new Mac, thought I'd transferred all I needed and realised I had pretty much zero of the Reaper stuff I'd tweaked (including all my CSI stuff etc).
It would be great to have a working one as a template.

Hope you don't mind me asking?

[MT4U]

Originally Posted by Funkybot

My first reaction is: bugs might come up in the CSI Device setup thread first anyway, like "hey, am I doing something wrong?" So maybe skip creating a new thread. Otherwise, I fear you'll have bug reports in the device setup thread, device setup questions in the bug reports thread, etc.

I'd think a good process would be:

1. Device setup thread for the "is this a bug or am I doing something wrong" discussion
2. Once confirmed by at least one other user, someone logs on the Github and/or this thread. Some of the regulars like MM, myself, MT4U could try to volunteer to play gatekeeper/reproducer rule.

Count me in.

My setup is:
- Windows 10
- X-Touch + 1 Extender
- X-Touch One (My 1st surface, using it as a button repository these days)
- No OSC for now (maybe next year, time permitting)
- A bunch of synths (welding a 19" 16 port MIDI patch bay right now...)

I believe it's quite different from MM's & FB's and I'm happy to keep up with the development best I can.

[MT4U]

Originally Posted by spkr4thdd

Hi MT4U!

I don't suppose you could share that script? I had a similar one for channel strips, but I've purchased a new Mac, thought I'd transferred all I needed and realised I had pretty much zero of the Reaper stuff I'd tweaked (including all my CSI stuff etc).
It would be great to have a working one as a template.

Hope you don't mind me asking?

Of course. I was thinking about making a small video about those when I find the time, but I can post an example or "how-to" easily, but I believe it would belong on the other forum... is that right?

[spkr4thdd]

That's great, thank you.

Originally Posted by MT4U

I can post an example or "how-to" easily, but I believe it would belong on the other forum... is that right?

I think so, yes. Maybe not even a CSI thread, as it's really about scripting.

[MixMonkey]

Originally Posted by Funkybot

I'd think a good process would be:

1. Device setup thread for the "is this a bug or am I doing something wrong" discussion
2. Once confirmed by at least one other user, someone logs on the Github and/or this thread. Some of the regulars like MM, myself, MT4U could try to volunteer to play gatekeeper/reproducer rule.

+1 for this, kinda what happens at the moment. It would be good to have a list of known bugs (that are awaiting fixes), so that a few of the "is this a bug or am I doing something wrong" requests could be headed off at the pass..

I think between us we can cover quite a lot of the issues, but there are bound to be occasions where the problem is specific to a surface that none of us have (SSL UF8, XTouch Compact etc) Hopefully other users of those surfaces will pitch in.

[Geoff Waddington]

Originally Posted by MixMonkey

+1 for this, kinda what happens at the moment. It would be good to have a list of known bugs (that are awaiting fixes), so that a few of the "is this a bug or am I doing something wrong" requests could be headed off at the pass..

I think between us we can cover quite a lot of the issues, but there are bound to be occasions where the problem is specific to a surface that none of us have (SSL UF8, XTouch Compact etc) Hopefully other users of those surfaces will pitch in.

Cool.

As far as a list, just click the link in blue below and go to the Issues tab in GitHub, then click on an issue of interest to expand -- there's only one so far

[MixMonkey]

Originally Posted by Geoff Waddington

As far as a list, just click the link in blue below and go to the Issues tab in GitHub, then click on an issue of interest to expand -- there's only one so far

Excellent!

[Geoff Waddington]

Originally Posted by MixMonkey

Excellent!

Check the other thread for how the process is happening, any suggestions more than welcomed...

[jacksoonbrowne]

Originally Posted by Geoff Waddington

Cool.

As far as a list, just click the link in blue below and go to the Issues tab in GitHub, then click on an issue of interest to expand -- there's only one so far

Now there are two ...

I was able to post an issue.
And I don't have Admin rights.

You may want to lock that down.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Now there are two ...

I was able to post an issue.
And I don't have Admin rights.

You may want to lock that down.

I think this is now sorted.

Can someone who has a GitHub account (other than Funkybot) please try to post an issue and let me know what happens.

[MixMonkey]

Originally Posted by Geoff Waddington

Can someone who has a GitHub account (other than Funkybot) please try to post an issue and let me know what happens.

Yep, fixed now. I get:

An owner of this repository has limited the ability to open an issue to users that are collaborators on this repository.

[spkr4thdd]

Geoff,

I've only been back with CSI about 36 hours (having last used 1.1) and have to say I'm blown away! I'm loving the fact that Behringer have opened up the colours outside of their xctl protocol, it's great seeing the X-Touch in all its glory. And my setup is already streets ahead of where it was after months of configuration and tweaking previously, thank you! (Auto FX Mapping is a Godsend!)

I do have a question though (there's always one!)...

Noting the text in bold below (from the Behringer documentation), is there any possibility of implementing the split/inverse colours in the upper and lower display sections of the X-Touch scribble strips?

I'm think that this would one great if we could invert the segment if a plug-in is disabled or something?

LCDs:
• sysex (hex) F0 00 20 32 dd 4C nn cc c1 .. c14 F7
• dd: device id (X-Touch: 0x14, X-Touch-Ext: 0x15)
• nn: LCD number 0..7
• cc: bits 0-2: backlight color (black, red, green, yellow, blue, magenta, cyan, white)
• cc: bit 4: invert upper half of LCD
• cc: bit 5: invert lower half of LCD
• c1..c14: ascii characters (1..7: upper half, 8..14: lower half)

Obviously this isn't important/priority, but I'd be interested to know if you think it can be implemented?

[Geoff Waddington]

Originally Posted by spkr4thdd

Geoff,

I've only been back with CSI about 36 hours (having last used 1.1) and have to say I'm blown away! I'm loving the fact that Behringer have opened up the colours outside of their xctl protocol, it's great seeing the X-Touch in all its glory. And my setup is already streets ahead of where it was after months of configuration and tweaking previously, thank you! (Auto FX Mapping is a Godsend!)

I do have a question though (there's always one!)...

Noting the text in bold below (from the Behringer documentation), is there any possibility of implementing the split/inverse colours in the upper and lower display sections of the X-Touch scribble strips?

I'm think that this would one great if we could invert the segment if a plug-in is disabled or something?

LCDs:
• sysex (hex) F0 00 20 32 dd 4C nn cc c1 .. c14 F7
• dd: device id (X-Touch: 0x14, X-Touch-Ext: 0x15)
• nn: LCD number 0..7
• cc: bits 0-2: backlight color (black, red, green, yellow, blue, magenta, cyan, white)
• cc: bit 4: invert upper half of LCD
• cc: bit 5: invert lower half of LCD
• c1..c14: ascii characters (1..7: upper half, 8..14: lower half)

Obviously this isn't important/priority, but I'd be interested to know if you think it can be implemented?

That SysEx doesn't look anything like MCU mode, are you sure they say it is for MCU mode, and not another mode ?

[spkr4thdd]

Originally Posted by Geoff Waddington

That SysEx doesn't look anything like MCU mode, are you sure they say it is for MCU mode, and not another mode ?

Ah, damn. It's MIDI mode. I thought I'd found something workable after having the xctl document tucked away for a while. I've attached that on the off chance, as it seems to be a different set of values, and isn't caveated with the "Xctl mode only" note.

[andrewx]

In my Track zone I have

OnZoneActivation     SetXTouchDisplayColors Cyan

When some track gets removed from the TCP - display colors start following the project's TCP colors, and to make them cyan again, I need to run the "RefreshAllSurfaces" action. Is it possible to maintain colors unchanged after track removal?

[Geoff Waddington]

Originally Posted by andrewx

In my Track zone I have

OnZoneActivation     SetXTouchDisplayColors Cyan

When some track gets removed from the TCP - display colors start following the project's TCP colors, and to make them cyan again, I need to run the "RefreshAllSurfaces" action. Is it possible to maintain colors unchanged after track removal?

I think that's a feature request.

Maybe a new Action -- ToggleAutoTrackColoring.

What do you think folks ?

[Funkybot]

Originally Posted by andrewx

In my Track zone I have

OnZoneActivation     SetXTouchDisplayColors Cyan

When some track gets removed from the TCP - display colors start following the project's TCP colors, and to make them cyan again, I need to run the "RefreshAllSurfaces" action. Is it possible to maintain colors unchanged after track removal?

Originally Posted by Geoff Waddington

I think that's a feature request.

Maybe a new Action -- ToggleAutoTrackColoring.

What do you think folks ?

If I'm not mistaken, I think this is a setup issue caused by this:

Zone "Track"
    DisplayUpper|            TrackNameDisplay { Track }

andrewx, if you have that in your Track zone, change that to just this...

Zone "Track"
    DisplayUpper|            TrackNameDisplay

Does that resolve it? Probably one for the device setup thread.

That { Track } portion is telling CSI to use the track colors, which I think is why it's going back to following track colors.

[Geoff Waddington]

Originally Posted by Funkybot

If I'm not mistaken, I think this is a setup issue caused by this:

Zone "Track"
    DisplayUpper|            TrackNameDisplay { Track }

andrewx, if you have that in your Track zone, change that to just this...

Zone "Track"
    DisplayUpper|            TrackNameDisplay

Does that resolve it? Probably one for the device setup thread.

That { Track } portion is telling CSI to use the track colors, which I think is why it's going back to following track colors.

You're exactly right, I should have been more clear.

The solution you state solves it more permanently.

I'm talking about when you want to display Track colours in the Track Zone but avoid the side effect andrewx pointed out.

Usage would be something like:

OnZoneActivation     ToggleAutoTrackColoring
OnZoneActivation     SetXTouchDisplayColors Cyan

OnZoneDeactivation   ToggleAutoTrackColoring
OnZoneDeactivation   RestoreXTouchDisplayColors

[Funkybot]

Originally Posted by Geoff Waddington

You're exactly right, I should have been more clear.

The solution you state solves it more permanently.

I'm talking about when you want to display Track colours in the Track Zone but avoid the side effect andrewx pointed out.

Usage would be something like:

OnZoneActivation     ToggleAutoTrackColoring
OnZoneActivation     SetXTouchDisplayColors Cyan

OnZoneDeactivation   ToggleAutoTrackColoring
OnZoneDeactivation   RestoreXTouchDisplayColors

Gotcha. That would work. Seems pretty esoteric but sure why not!

[andrewx]

Originally Posted by Funkybot

If I'm not mistaken, I think this is a setup issue caused by this:

Zone "Track"
    DisplayUpper|            TrackNameDisplay { Track }

andrewx, if you have that in your Track zone, change that to just this...

Zone "Track"
    DisplayUpper|            TrackNameDisplay

Does that resolve it? Probably one for the device setup thread.

That { Track } portion is telling CSI to use the track colors, which I think is why it's going back to following track colors.

Removed that { Track } thing, but colors still change anyway.