Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by _Stevie_

Pardon me, if this has been answered already l but is the following possible?

ability to trigger SWS actions

Already there, from MCU.axt:

Save Reaper 40026
Shift+Save Reaper 40022
Undo Reaper 40029
Shift+Undo Reaper 40030

The param doesn't have to ba a number, it can be a string as in: Reaper _SWS_ABOUT.

Originally Posted by _Stevie_

ability to trigger scripts

Planned.

Originally Posted by _Stevie_

key repetition, especially useful for rewind and fast forward commands

Planned.

Right now, concentrating on matrix concepts.

[Geoff Waddington]

Hmmm...

A surface on a Page uses a particular set of .axt/.fxt files.

That means the sum of all logical matrices can never be bigger than the surface they represent.
-- You could have a matrix that spanned surfaces, but that could be thought of as 2 matrices (presumably tied by a set of characteristics).

So for a given surface, the logical (this Page) representation of the surface is constrained nicely to it's "natural" matrix -- the definition in the .rst/CSI.ini files.

OK, now for parent/sibling/child relationships.

Using our 4 Send/4 FX/FX Params C4 example::

The 4 Send/4 FX matrices are siblings.

The FX Params matrix is a child of the FX matrix.

Any matrix can receive up/down/left/right/back/forth messages.

A matrix may or may not act on navigation messages.

4 Send and 4 FX might respond to up/down for slot navigation.

Pushing an FX top switch would implement a back/forth message (aka drill down) for selecting the proper FX Params for the FX Param section of the matrix.

The child matrix (FXParams) might ignore any navigation messages.
The parent matrix (4 FX) might not pass navigation messages along to the child, or it might alter them in some way, then pass them on.

Using the Channel concept -- really a 1 row x many column matrix, as an example:

Left/right messages are processed, you can scroll through tracks.

Up/Down messages are ignored -- up/down is meaningless in the context of scrolling through tracks.

Back/forth messages are ignored -- back/forth is meaningless in the context of scrolling through tracks.

Just some thoughts on matrices...

[dragonslair]

Is there any place where I can get a tutorial on writing these .rst and .axt files?
I have my Spirit 328 setup as a controller in Reaper (using the Actions list) but would like to try and set it up with bi-directional control.
The 328 does not "emulate" anything else, it sends midi cc's for volume, pan, mute and solo, and sends midi note numbers for the transport controls, it can also receive midi commands.

[Geoff Waddington]

Originally Posted by dragonslair

Is there any place where I can get a tutorial on writing these .rst and .axt files?
I have my Spirit 328 setup as a controller in Reaper (using the Actions list) but would like to try and set it up with bi-directional control.
The 328 does not "emulate" anything else, it sends midi cc's for volume, pan, mute and solo, and sends midi note numbers for the transport controls, it can also receive midi commands.

Ok, had a quick look at the 328 midi spec.

First of all Reaper does not handle receiving SYSEX, so bulk dumps will not be possible, sending SYSEX works just fine.

You can easily make your own .rst/.axt/.fxt files.

They are located within the CSI directory in the Reaper resource path -- there is a Reaper action to show this path.

The concept is dead simple.

The .rst file names the control messages.

Go to CSI config panel (in preferences).

Turn on Midi in monitor, and press Ok to make your way out of the config panels.

Press the Play button on the 328.

The incoming Midi message will be displayed in the ReaConsole window.

example -- 90 5e 7f

OK, make the .rst file:

example -- Sprit328.rst (or whatever you want to name it) and place it in the CSI folder.

OK, make a line in the .rst file:

Play PressFB 90 5e 7f 90 5e 00

That says the Play message is generated whenever that button is pressed.

Now we need to use that Play message to tell Reaper to do something.

This is where the .axt/.fxt file comes in.

There is one more thing, you can have many different Pages in CSI.

Each surface can behave completely differently on each Page.

For now we will just use one Page to keep it simple.

OK, let's tell Reaper to Play when Play is pressed.

Make an .axt file for this page -- example Spirit328.axt -- and place in in the CSI/axt/Spirit328 folder (you will have to create the Spirit328 folder).

Make a line in the .axt file:

Play Play

Voila !!

Now go into the config panel and config the 328 to use the Sprirt328.rst file and the Spirit328.axt file for the Page.

After you have this working you can easily (but tediously) proceed to map the 328.

Tip: Use the MCU .rst and .axt files as a guide.

[mschnell]

Originally Posted by Geoff Waddington

Play PressFB 90 5e 7f 90 5e 00.

Additionally it tells CSI to send 90 5e 7f to turn on a light (that is supposed to be in the Play button) and to send 90 5e 00 to kill it. This usually is the same message that is sent by the surface when the button is released. (Regarding other behavior of Button lights or for using non-Button-located lights, see the discussion on "PressGeneric" above.)

CSI intelligently handles that light to reflect the play state, that is managed by the play and stop buttons on the surface and on the Reaper GUI, and by other means.

Let us know what you find !

-Michael (interested because I am testing CSI with a non MCU compatible device, as well)

[MixMonkey]

Originally Posted by Geoff Waddington

OK, now for parent/sibling/child relationships.

The parent being the logical Page?

Originally Posted by Geoff Waddington

The FX Params matrix is a child of the FX matrix.

Can children have children so that the layers idea can be implemented? or will the FX Params matrix scroll across to reveal more parameters? (wouldn't this mean the FX Params matrix got larger than it's surface?)

Originally Posted by Geoff Waddington

4 Send and 4 FX might respond to up/down for slot navigation

It strikes me that you have two (possibly) competing ways of accessing send and FX slots where you probably only need one.

On the one hand you have the button top push for selecting a particular FX slot so that particular FX's parameters are displayed in the FX Params matrix. This will obviously work and give immediate access to the first four slots.

However, it's disadvantages (as I see them) are that you've always dedicated 4 controls to FX selection regardless of how many slots are in play on a given channel and you've used 4 valuable rotary push encoders to do it. And you still need to provide a method of accessing the slots/sends beyond the first four.

I think a straightforward up/down slot navigation would be the better primary choice (you could still set up direct slot access if you wanted) The C4 has Up/Down buttons (as do many other controllers) I think these are a better choice for slot/send navigation.

In our current example the question would remain about how the Up/Down buttons would be targeted/focussed to either Sends or FX slots (or anything else for that matter)

Regarding accessing FX parameters that can't initially be seen but are defined in the .fxt file, perhaps the C4 Left/Right controls could scroll the FX Params matrix sideways to reveal them? Again a method of targeting those useful navigation controls would be needed,

[Geoff Waddington]

Originally Posted by MixMonkey

The parent being the logical Page?

Yes using our example:

Page -- parent of all SurfaceLogicalMatrices -- e.g. GreenPage

SurfaceLogicalMatrix -- parent of all LogicalMatrices
C4 Sends -- LogicalMatrix
C4 FX -- LogicalMatrix -- parent of C4 FX Params LogicalMatrix
C4 FX Params -- LogicalMatrix

Originally Posted by MixMonkey

Can children have children so that the layers idea can be implemented?

Yes.

Originally Posted by MixMonkey

or will the FX Params matrix scroll across to reveal more parameters?

Yes.

Originally Posted by MixMonkey

(wouldn't this mean the FX Params matrix got larger than it's surface?)

No, the SurfaceLogicalMatrix can get larger, the FX Params matrix is a sliding window over the SurfaceLogicalMatrix.

Originally Posted by MixMonkey

It strikes me that you have two (possibly) competing ways of accessing send and FX slots where you probably only need one.

On the one hand you have the button top push for selecting a particular FX slot so that particular FX's parameters are displayed in the FX Params matrix. This will obviously work and give immediate access to the first four slots.

However, it's disadvantages (as I see them) are that you've always dedicated 4 controls to FX selection regardless of how many slots are in play on a given channel and you've used 4 valuable rotary push encoders to do it. And you still need to provide a method of accessing the slots/sends beyond the first four.

Right, but for someone, this may be ideal.

Originally Posted by MixMonkey

I think a straightforward up/down slot navigation would be the better primary choice (you could still set up direct slot access if you wanted) The C4 has Up/Down buttons (as do many other controllers) I think these are a better choice for slot/send navigation.

Sure, that should be possible too.

Originally Posted by MixMonkey

In our current example the question would remain about how the Up/Down buttons would be targeted/focussed to either Sends or FX slots (or anything else for that matter)

Agree, we need to be able to state what navigation means in a given context (LogicalMatrix, SurfaceLogicalMatrix, etc.).

Originally Posted by MixMonkey

Regarding accessing FX parameters that can't initially be seen but are defined in the .fxt file, perhaps the C4 Left/Right controls could scroll the FX Params matrix sideways to reveal them? Again a method of targeting those useful navigation controls would be needed,

Sure.

This is exactly the rational for allowing external files (.rst/.axt/.fxt) to define how all of this behaves in your system, customized to your workflow.

The trick is coming up with a reasonable syntax to describe all the scenarios you mention as well as many more.

It's a tricky beast, but also a fun challenge

[Freex]

Originally Posted by Geoff Waddington

Yes using our example:

Page -- parent of all SurfaceLogicalMatrices -- e.g. GreenPage

SurfaceLogicalMatrix -- parent of all LogicalMatrices
C4 Sends -- LogicalMatrix
C4 FX -- LogicalMatrix -- parent of C4 FX Params LogicalMatrix
C4 FX Params -- LogicalMatrix



Yes.



Yes.



No, the SurfaceLogicalMatrix can get larger, the FX Params matrix is a sliding window over the SurfaceLogicalMatrix.



Right, but for someone, this may be ideal.



Sure, that should be possible too.



Agree, we need to be able to state what navigation means in a given context (LogicalMatrix, SurfaceLogicalMatrix, etc.).



Sure.

This is exactly the rational for allowing external files (.rst/.axt/.fxt) to define how all of this behaves in your system, customized to your workflow.

The trick is coming up with a reasonable syntax to describe all the scenarios you mention as well as many more.

It's a tricky beast, but also a fun challenge

Maybe I'm reading this wrong, but if I understand correctly, and using the C4 example ( and describing the matrix size in terms of row x column)

You could have a matrix defined for the sends that was 1 row by 12 columns (so 12 sends.
You could have the same for the FX matrix 1 x12 (by this I mean on/off &/or wet/dry)

Now we have it setup that we can only see 1x4 of each,
And below is a 3x8 for the FX params

If this it true so far, then the matrix for the FX pramas could be any size as well, probably not that practical for it to be, but if potentially it could be.

Then surely wee could have the slots up and down navigating up/down and the TracksL&R navigating Left and right.

Then if by default they navigated the main fx params (matrix window) should that be left and right to show an extra set of knobs or down/up to either show an extra row or cycle to the next FX params.

Then use SHIFT+ with the same UpDownLR to navigate the Sends,
and use OPTION+ for the FX (control window)

It also leaves CONTROL+ and ALT+ if you wanted to break up your layout further. And ofcouse even further if you doubled up CONTROL+SHIFT+ etc.

Could, would this work. Or have i read things wrong?

Of course if I'm right in what I'm reading, and not reading too much into it, then you could have your sends as a 3x4 matrix (still haveing 12 sends) but navigating up/down as opposed to left right.

[Geoff Waddington]

Originally Posted by Freex

Maybe I'm reading this wrong, but if I understand correctly, and using the C4 example ( and describing the matrix size in terms of row x column)

You could have a matrix defined for the sends that was 1 row by 12 columns (so 12 sends.
You could have the same for the FX matrix 1 x12 (by this I mean on/off &/or wet/dry)

Now we have it setup that we can only see 1x4 of each,
And below is a 3x8 for the FX params

If this it true so far, then the matrix for the FX pramas could be any size as well, probably not that practical for it to be, but if potentially it could be.

Then surely wee could have the slots up and down navigating up/down and the TracksL&R navigating Left and right.

Then if by default they navigated the main fx params (matrix window) should that be left and right to show an extra set of knobs or down/up to either show an extra row or cycle to the next FX params.

Then use SHIFT+ with the same UpDownLR to navigate the Sends,
and use OPTION+ for the FX (control window)

It also leaves CONTROL+ and ALT+ if you wanted to break up your layout further. And ofcouse even further if you doubled up CONTROL+SHIFT+ etc.

Could, would this work. Or have i read things wrong?

Of course if I'm right in what I'm reading, and not reading too much into it, then you could have your sends as a 3x4 matrix (still haveing 12 sends) but navigating up/down as opposed to left right.

Yup, you've nailed it, we want to be able to do all those things and much much more.

It's basically navigation through a 3 dimensional matrix -- which can include sub-matrices, perhaps dependant on the parent.

The tech is not trivial, but it's not all that sophisticated either.

It's basically navigation through a 3 dimensional matrix -- which can include sub-matrices.

It's finding an easy way to describe it in a file that's the tricky bit

[dragonslair]

Originally Posted by Geoff Waddington

Ok, had a quick look at the 328 midi spec.

First of all Reaper does not handle receiving SYSEX, so bulk dumps will not be possible, sending SYSEX works just fine.

You can easily make your own .rst/.axt/.fxt files.

They are located within the CSI directory in the Reaper resource path -- there is a Reaper action to show this path.

The concept is dead simple.

The .rst file names the control messages.

Go to CSI config panel (in preferences).

Turn on Midi in monitor, and press Ok to make your way out of the config panels.

Press the Play button on the 328.

The incoming Midi message will be displayed in the ReaConsole window.

example -- 90 5e 7f

OK, make the .rst file:

example -- Sprit328.rst (or whatever you want to name it) and place it in the CSI folder.

OK, make a line in the .rst file:

Play PressFB 90 5e 7f 90 5e 00

That says the Play message is generated whenever that button is pressed.

Now we need to use that Play message to tell Reaper to do something.

This is where the .axt/.fxt file comes in.

There is one more thing, you can have many different Pages in CSI.

Each surface can behave completely differently on each Page.

For now we will just use one Page to keep it simple.

OK, let's tell Reaper to Play when Play is pressed.

Make an .axt file for this page -- example Spirit328.axt -- and place in in the CSI/axt/Spirit328 folder (you will have to create the Spirit328 folder).

Make a line in the .axt file:

Play Play

Voila !!

Now go into the config panel and config the 328 to use the Sprirt328.rst file and the Spirit328.axt file for the Page.

After you have this working you can easily (but tediously) proceed to map the 328.

Tip: Use the MCU .rst and .axt files as a guide.

I tried all this, but no joy.
I traced the problem to the midi, the CSI is not receiving any midi, when I turn on the input monitor, I get nothing.
The 328 is transmitting, and the controls mapped through Actions work fine, so Reaper is receiving midi, but the CSI is not (it is configured properly)
Any suggestions?

[Geoff Waddington]

Originally Posted by dragonslair

I tried all this, but no joy.
I traced the problem to the midi, the CSI is not receiving any midi, when I turn on the input monitor, I get nothing.
The 328 is transmitting, and the controls mapped through Actions work fine, so Reaper is receiving midi, but the CSI is not (it is configured properly)
Any suggestions?

First make sure the 328 midi inputs and outputs are disabled in Preferences->Audio->Midi Devices

Then make sure your CSI surface midi is set to 328 midi.

Remove all surfaces except the 328 from Surfaces in the CSI config panel.

Feel free to post the content of your CSI, .rst and .axt files here.

[dragonslair]

I remember reading that earlier, so they have been disabled in midi devices.
I removed the other pages, but still nothing

[Geoff Waddington]

Originally Posted by dragonslair

I remember reading that earlier, so they have been disabled in midi devices.
I removed the other pages, but still nothing

OK please post the contents of the CSI.ini, the .rst, and .axt files that you use.

[dragonslair]

Here you go.

Spirit328.rst

Play PressFB 90 5e 7f 90 5e 00
Stop PressFB 90 5f 7f 90 5f 00
Record PressFB 90 5d 7f 90 5d 00
FastForward PressFB 90 5c 7f 90 5c 00
Rewind PressFB 90 4f 7f 90 4f 00

Spirit328.axt

Play Play
Stop Stop
Record Record
Fastforward Fastforward
Rewind Rewind

CSI.ini

MidiInMonitor On
MidiOutMonitor On
VSTMonitor Off

Page Spirit328 FollowTCP NoTrackColoring 0 0 0
MidiSurface Spirit328 16 Bankable 21 21 Spirit328.rst Spirit328 Spirit328

[Geoff Waddington]

Originally Posted by dragonslair

Here you go.

Spirit328.rst

Play PressFB 90 5e 7f 90 5e 00
Stop PressFB 90 5f 7f 90 5f 00
Record PressFB 90 5d 7f 90 5d 00
FastForward PressFB 90 5c 7f 90 5c 00
Rewind PressFB 90 4f 7f 90 4f 00

Spirit328.axt

Play Play
Stop Stop
Record Record
Fastforward Fastforward
Rewind Rewind

CSI.ini

MidiInMonitor On
MidiOutMonitor On
VSTMonitor Off

Page Spirit328 FollowTCP NoTrackColoring 0 0 0
MidiSurface Spirit328 16 Bankable 21 21 Spirit328.rst Spirit328 Spirit328

There is a typo in the .axt:
Fastforward Fastforward
should be:
FastForward FastForward

Other than that everything looks fine.

The Spirit328.axt is the only file in the CSI/axt/Spirit328 folder ?

[dragonslair]

Yes, it's the only file there.
Like I said before, the problem seems to be that the CSI is not receiving the midi info for some reason.

[Geoff Waddington]

Originally Posted by dragonslair

Yes, it's the only file there.
Like I said before, the problem seems to be that the CSI is not receiving the midi info for some reason.

Is there more than one set of inputs and outputs on the 328 ?

When you say, controls mapped through actions, can you explain in detail how you set this up, might be a clue in there.

[dragonslair]

Open up the Actions list, select an action then click ADD and move a control or push a button on your controller, and it maps it to that action.
I have the 328 mapped that way, but it is only a one way communication.
These don't work with the midi disabled in Preferences, so there should be no conflict there.

[Geoff Waddington]

Originally Posted by dragonslair

Open up the Actions list, select an action then click ADD and move a control or push a button on your controller, and it maps it to that action.
I have the 328 mapped that way, but it is only a one way communication.
These don't work with the midi disabled in Preferences, so there should be no conflict there.

Ah, gotcha.

You seem to have everything right...

Can't think of anything else to check right now, but I'm sure there must be something or it would be working

We'll eventually, dare I say it, slay this dragon

[dragonslair]

And there is only one set of midi inputs and outputs on the 328.
The only thing I can think of, is that there is a problem with the CSI program, I'll try downloading it again tomorrow, and re-installing it, and see if it makes any difference.
It was a bit of a problem installing it, first I had to download and install Service pack 1 for Windows 7, then I had to install Visual C 15 redist. before it would work at all, so something might have gotten screwed in the process.
A System Requirements note would have been helpful.

[mschnell]

I once had a similar issue.

I manually modified the Midi interface numbers in the CSI.ini file and restarting Reaper several times, and suddenly it worked after re-editing it to the original state it got via the CSI configuration.

lately this did not happen again.

-Michael

[_Stevie_]

Hm, I have a similar issue in Windows. Not sure if it's OS related, though.
But it works on my Mac.

In my case, it's the Steinberg CMC-CH. When I start Reaper, the MIDI input monitor works.
Then, I press some buttons and the device is dead. I have to restart Reaper, to get MIDI input again.
But the device is never usable, functions don't seem to be assigned and buttons don't glow.

[Geoff Waddington]

Originally Posted by dragonslair

And there is only one set of midi inputs and outputs on the 328.
The only thing I can think of, is that there is a problem with the CSI program, I'll try downloading it again tomorrow, and re-installing it, and see if it makes any difference.
It was a bit of a problem installing it, first I had to download and install Service pack 1 for Windows 7, then I had to install Visual C 15 redist. before it would work at all, so something might have gotten screwed in the process.
A System Requirements note would have been helpful.

Thanks, now that I know what curveballs Win 7 will throw, I'll include that note -- don't have a Win 7 environment here.

We once had a bizarre problem with files in the Win 7 environment, where there were "ghost" files generated that were not refreshing on an install, reinstalling a few times did the trick.

[mschnell]

Originally Posted by Geoff Waddington

We once had a bizarre problem with files in the Win 7 environment, where there were "ghost" files generated that were not refreshing on an install, reinstalling a few times did the trick.

IIRC, "ini" files can be accessed via a dedicated API in Windows. Maybe Reaper uses same, and maybe you use a dedicated Reaper API for the ini file(s) ?

-Michael

[Geoff Waddington]

Originally Posted by mschnell

IIRC, "ini" files can be accessed via a dedicated API in Windows. Maybe Reaper uses same, and maybe you use a dedicated Reaper API for the ini file(s) ?

-Michael

Thanks for the tip, I am already using the Reaper function GetResourcePath(), don't think that's the problem, otherwise no Windows installs would work, not just this one.

[Geoff Waddington]

Ok, let’s try and blend some of this great matrix discussion into a first draft.

Of course, this will not cover all use cases, but let’s see if we can describe a few from the discussion.

First off, let’s introduce something that’s been planned from the start, a feature we’ll call NavLink.

It’s simply a checkbox option in Page.

When you bank on a NavLinked Page, all other NavLinked Pages are also banked in lockstep.

So let’s set up the Sends example.

You would probably map the Sends Channels differently — maybe something like:

RecArm — Pre/Post
Upper Display — Track name as usual — this would be repeated across the top
Lower Display — Send Track Name

That would be a nice visual clue that you are in Sends mode.

You could have up/down buttons below the transport step through the Sends.

Or you could have Shift+BankLeft/Shift+BankRight step through the Sends.

Anyway, you get the idea.

So we have a Matrix defined by using a separate NavLinkedPage.

In this Matrix left/right means Track left/right.

In this Matrix up/down means scroll through the Sends.

OK use case number one — Check !


We also might want to split up the controller into sections — aka subMatrices.

We need a way to navigate these subMatrices.

Suggest we cap it to 4 subMatrices max for now and utilize the modifiers:



So, holding Shift would scroll the upper left subMatrix, holding Option would scroll the upper right subMatrix, etc.

You could define the unmodified scroll keys as any one of the four.

Just some thoughts from Saturday morning.

[MixMonkey]

Originally Posted by Geoff Waddington

OK use case number one — Check !

Perfect! Right down to using DisplayLower to show the send name- you read my mind! (I guess DisplayLower could still be SendTouchControlled SendNameDisplay SendLevelDisplay, when SendLevel is mapped to the fader?)

Originally Posted by Geoff Waddington

Suggest we cap it to 4 subMatrices max for now and utilize the modifiers

4 is plenty. Regarding the modifiers determining the nav target, this will work fine, but I wondered whether it would be simpler to have the concept of an 'active' sub-matrix, determined by the last control touched. So if you've tweaked a send, the nav controls target the sends sub-matrix until you select an FX to edit, say,(our usual Send/FX/FXParam example) Then they target the FX select sub-matrix. When you select your FX and edit a couple of params the navs target the FX params matrix to allow you to scroll for additional parameters. It would mean that the nav controls target without any real user intervention, making the work flow smoother.

[Geoff Waddington]

Originally Posted by MixMonkey

Perfect! Right down to using DisplayLower to show the send name- you read my mind! (I guess DisplayLower could still be SendTouchControlled SendNameDisplay SendLevelDisplay, when SendLevel is mapped to the fader?)

Yup, that's how I'd map it.

Originally Posted by MixMonkey

4 is plenty. Regarding the modifiers determining the nav target, this will work fine, but I wondered whether it would be simpler to have the concept of an 'active' sub-matrix, determined by the last control touched. So if you've tweaked a send, the nav controls target the sends sub-matrix until you select an FX to edit, say,(our usual Send/FX/FXParam example) Then they target the FX select sub-matrix. When you select your FX and edit a couple of params the navs target the FX params matrix to allow you to scroll for additional parameters. It would mean that the nav controls target without any real user intervention, making the work flow smoother.

Thought about that but it's tricky.

In our example suppose you had last touched an FX param -- does an FX param mean bank the FX section, or the FX Param section, context can very quickly cause confusion.

Suppose you had just touched a Sends Level and now wanted to bank FX, you'd have to touch (change) an FX value to grab attention from the Sends

The hard notion of quadrants solves some potentially very confusing scenarios, especially when you add the ability to map the most used one to the unmodified scroll buttons as a default.

[MixMonkey]

Originally Posted by Geoff Waddington

Thought about that but it's tricky.

No problem, modifiers it is then

[Freex]

I'd also "thumbs up the modifiers", while last touched is a nice concept, in practice e you can easily be lost in pushing unnecessarily buttons.
At least with mods you know what your moving. No accidents, or at least less.
And since they're only for navigation, it's a one action use, therefore if you ended up co stately moving back and forth, odds are your current matrix setup is not suitable for your work flow.
Just seems to me like the most intuitive setup.

[Geoff Waddington]

New build is up: https://stash.reaper.fm/v/33037/CSI%20pre%20alpha.zip

You MUST either use the new CSI files OR change your Page lines from this:

Page GreenPage FollowTCP NoTrackColoring 75 255 166

to this:

Page GreenPage FollowTCP NoSynchPages NoTrackColoring 75 255 166

You can also use SynchPages.

All Pages that have SynchPages checked bank in lockstep.

This will be very useful for things like the Sends example we discussed a few posts back.

Just have to write all those Sends actions


@michael, could you please try PressFBR, PressReleaseR, and PresssReleaseFBR -- R meaning resend on release.

[MixMonkey]

Working here
Deleted the old CSI.ini and recreated from scratch. All ok as before, looking forward to those Sends actions!

[Geoff Waddington]

Hmmm...

What seems to be a simple thing....

Ok, let's talk sends, but this applies to scrolling in general.

You have set up a separate (synched) Page for Sends with the usual suspects (Fader, Pan, Mute, etc.)

Now you want to step through the Sends slots.

You set up an up/down pair to do this.

So far so good.

The endpoint of scrolling up is easy -- the first slot.

Down is the tricky direction.

Ideally you shouldn't be able to scroll forever, you should hit end stops like Track banking does.

Is the bottom based on the Track with the most total Sends, or the Track with the most total Sends that is also currently visible on the surface ?

What happens when you bank, does the "depth" readjust ?

All comments/suggestions more than welcomed.

[Skijumptoes]

For me, As long as sends is the last item (After Fader/Pan etc.) it should just go up to a fixed figure as required by the user.

i.e. let's say max of 10 sends was specified, page down to Send 1,2,3...10 - no matter which track you are on.

That way you can always move to a new send slot regardless if any exist to start with, and keep that send slot focused as you bank across tracks.

[MixMonkey]

Originally Posted by Geoff Waddington

Is the bottom based on the Track with the most total Sends, or the Track with the most total Sends that is also currently visible on the surface ?

Ideally, the track with most sends that's currently on the surface, so it would change when banked. However it's fine to just set the limit using the track in the entire project with most sends, if that's much easier to code.

If DisplayLower is showing the send name, it'll be obvious when the bottom is reached as the display will go blank.

Edit: Just saw Ski's fixed number idea- I'd be quite happy with this too

[Geoff Waddington]

Originally Posted by Skijumptoes

For me, As long as sends is the last item (After Fader/Pan etc.) it should just go up to a fixed figure as required by the user.

i.e. let's say max of 10 sends was specified, page down to Send 1,2,3...10 - no matter which track you are on.

That way you can always move to a new send slot regardless if any exist to start with, and keep that send slot focused as you bank across tracks.

Originally Posted by MixMonkey

Ideally, the track with most sends that's currently on the surface, so it would change when banked. However it's fine to just set the limit using the track in the entire project with most sends, if that's much easier to code.

If DisplayLower is showing the send name, it'll be obvious when the bottom is reached as the display will go blank.

Edit: Just saw Ski's fixed number idea- I'd be quite happy with this too

Thanks guys, using the concept of a slot index, how about this:

Slot index is capped at track with max number of Sends.

However, for any given Track, if there is not a Send at an index , the Send with the max index for that Track is displayed/controlled.

This seems to fit better with the Reaper list-based Sends approach -- as opposed to the ProTools slot-based Sends approach.

What do you think ?

[MixMonkey]

Originally Posted by Geoff Waddington

However, for any given Track, if there is not a Send at an index , the Send with the max index for that Track is displayed/controlled.

What do you think ?

Once I get used to the idea that I might not be looking at a row of 'Send1s' (for instance), this will work well. I agree, it is better suited to Reapers approach.

[mschnell]

Originally Posted by Geoff Waddington

@michael, could you please try PressFBR, PressReleaseR, and PresssReleaseFBR -- R meaning resend on release.

Sorry, but it does not seem to work.

While PressReleaseFB does send something on Release (and hence works for the select buttons, even though I think that PressFBR should be used), PressFBR (which I think needs to be used for the toggle buttons) does not send anything on release.

(I assume PressFBR is to use the second for detecting the release message and for encoding the Kill Light message to send.)

-Michael

[Geoff Waddington]

New build is up: https://stash.reaper.fm/v/33037/CSI%20pre%20alpha.zip

First cut at Sends Page -- see CSI.ini for config examples.

Make sure to set your MCU to use MCUSends axt directory -- See MCU for example.

Shift+ChannelLeft = Up
Shift+BankLeft = Down

Volume, Pan, Mute, Send Track name display, Touch shows Send Level.

[poetnprophet]

Hello Geoff and everyone. I jumped in here a while back before an alpha was launched. I got familiar with the thread again, but it didn't help because I am honestly [more] lost and not sure if this is yet ready for someone like me with no coding skills.

I am using this surface: https://www.roland.com/global/products/v-studio_700/ with the MCU standard with Reaper and it works pretty darn well just as it is. All channel strips work 100% and about 90% of the other buttons can be programmed to actions. I don't really want to change any of that right now.

I'd really like to try this out because this control surface has a section with 12 rotaries and a display, similar to like a C4...but these just don't work as it is for anything, and it would be great to use them for plugs/etc. I have things downloaded/installed and can launch the app, but I almost totally lost after that.

Sorry for the ignorance. It's ok to tell me to come back later when it's ready.
Dave