Control Surface Integration (CSI) Technical Feature Discussion

[Mr. Green]

Originally Posted by Freex

Are you using Geoff's CSI?
It has an option to show in a window all messages coming IN, a quick turn of the knob with each strip selected would indicate whether things change,

Ideally you should be seeing something like,
Strip channel 1 - b0 10 ##
Strip channel 2 - b0 11 ##
Strip channel 3 - b0 12 ##

Especially in Mackie Mode, also if you could check it in Native mode would most likely add a good bit of info too.

Yes I am. The results using the Native mode are very interesting.
When using the pan knob, only the Master Fader gets the three variables (1 IN 2 OUTs). The channels, however, only get 1 IN and 1 OUT, and they appear to be the same variables regardless of which channel is selected. Turning the knob faster also seems to generate different variables. Of course, selecting another channel generates it's own set of variables (6 OUTs followed by 2 INs). Also, the Select button on the FP8 does change and remain lit on whichever track is selected.

Scribble Strips are completely blank though.

All of the buttons appear to be sending messages, but the only ones that generate actions close to their intended use are the Transport buttons (mostly) and the Automation Mode buttons.

[Mr. Green]

I'll also add that while the faders do work in writing automation and setting levels, they are not responding any movement commands.

[Freex]

Originally Posted by Mr. Green

Yes I am. The results using the Native mode are very interesting.
When using the pan knob, only the Master Fader gets the three variables (1 IN 2 OUTs). The channels, however, only get 1 IN and 1 OUT, and they appear to be the same variables regardless of which channel is selected. Turning the knob faster also seems to generate different variables. Of course, selecting another channel generates it's own set of variables (6 OUTs followed by 2 INs). Also, the Select button on the FP8 does change and remain lit on whichever track is selected.

Scribble Strips are completely blank though.

All of the buttons appear to be sending messages, but the only ones that generate actions close to their intended use are the Transport buttons (mostly) and the Automation Mode buttons.

I guess the big ask is that you map out the surface, only check box Midi IN messages as it will not pollute your window with info you don't need (for mapping),
Then go thru your surface, one knob or button or fader at a time and note the midi message IN, really it's the first 2 sets of 2 digit numbers as the range (last 2 sets) is usually 00 7F, there are really only a hand full of types,
Rotary Encoder = Knob
RotaryPush Button = push on knob
Fader = Fader
Fadertouch = message sent when you touch the fader without moving it.
Button = Button
Button with release = the like of shift,alt,option buttons

If you look at any of the rst files in CSI you'll get the idea.
You don't need them in prefect to map it out, just note the name and go from there.
Post real values as that will invariably help Geoff understand the way it's functioning.

[Mr. Green]

Originally Posted by Freex

I guess the big ask is that you map out the surface, only check box Midi IN messages as it will not pollute your window with info you don't need (for mapping),
Then go thru your surface, one knob or button or fader at a time and note the midi message IN, really it's the first 2 sets of 2 digit numbers as the range (last 2 sets) is usually 00 7F, there are really only a hand full of types,
Rotary Encoder = Knob
RotaryPush Button = push on knob
Fader = Fader
Fadertouch = message sent when you touch the fader without moving it.
Button = Button
Button with release = the like of shift,alt,option buttons

If you look at any of the rst files in CSI you'll get the idea.
You don't need them in prefect to map it out, just note the name and go from there.
Post real values as that will invariably help Geoff understand the way it's functioning.

I'll do my best!
(might need a day or two though)

[Mr. Green]

Ok - here we go...

Faderport 8 IN values/Native (Studio One) mode:

ALL pushbuttons (including rotary encoders) output the following variable:
push = 7f
release = 00

Pan/Param knob adjust
b0 10
variable output:
clockwise 1 step = "01"
counter-clockwise 1 step = "41"
increased steps (speed) outputs higher variables:
clockwise "02", "03", "04" etc. Max value = 3f
counter-clockwise "42", "43", "44" etc. Max value = 7f

Pan/Param push on knob
90 20

Select buttons
ch1:
90 18

ch2:
90 19

ch3:
90 1a

ch4:
90 1b

ch5:
90 1c

ch6:
90 1d

ch7:
90 1e

ch8:
90 1f

Mute buttons
ch1:
90 10

ch2:
90 11

ch3:
90 12

ch4:
90 13

ch5:
90 14

ch6:
90 15

ch7:
90 16

ch8:
90 17

Solo buttons
ch1:
90 08

ch2:
90 09

ch3:
90 0a

ch4:
90 0b

ch5:
90 0c

ch6:
90 0d

ch7:
90 0e

ch8:
90 0f

ALL faders output the following variable:
touch = 7f
release = 00

Fader touch
ch1:
90 68

ch2:
90 69

ch3:
90 6a

ch4:
90 6b

ch5:
90 6c

ch6:
90 6d

ch7:
90 6e

ch8:
90 6f

ALL faders output 1:1 range variable:
Min value (bottom position) = 00
Max value (top position) = 7f

Fader adjust
ch1:
e0

ch2:
e1

ch3:
e2

ch4:
e3

ch5:
e4

ch6:
e5

ch7:
e6

ch8:
e7

Arm button
90 00

Solo Clear button
90 01

Mute Clear button
90 02

Bypass button
90 03

Macro button
90 04

Link button
90 05

Shift button (left)
90 46

Track button
90 28

Edit Plugins button
90 2b

Sends button
90 29

Pan button
90 2a

Audio button
90 3e

VI button
90 3f

Bus button
90 40

VCA button
90 41

All button
90 42

Shift button (right)
90 06

Latch button
90 4e

Trim button
90 4c

Off button
90 4f

Touch button
90 4d

Write button
90 4b

Read button
90 4a

Prev button
90 2e

Next button
90 2f

large scroll wheel adjust
b0 3c
variable output:
clockwise 1 step = "01"
counter-clockwise 1 step = "41"
increased steps (speed) outputs higher variables:
clockwise "02", "03", "04" etc. Max value = 3f
counter-clockwise "42", "43", "44" etc. Max value = 7f

large scroll wheel push button
90 53

Channel button
90 36

Zoom button
90 37

Scroll button
90 38

Bank button
90 39

Master button
90 3a

Click button
90 3b

Section button
90 3c

Marker button
90 3d

Loop button
90 56

RWND button
90 5b

FFWD button
90 5c

Stop button
90 5d

Record button
90 5f

Play button
90 5e

[Freex]

Pretty much all of that is basically the same as Mackie Mode.
Just that Single Pan/Panara knob,
Can you double check it definitely doesn'y give different Message on different strips selected?

Good work you're half way to having a real surface template.

[Geoff Waddington]

Originally Posted by Freex

Pretty much all of that is basically the same as Mackie Mode.
Just that Single Pan/Panara knob,
Can you double check it definitely doesn'y give different Message on different strips selected?

Good work you're half way to having a real surface template.

Thanks for supportin' the folks whilst I'm slavin' away in the back room

Good on ya' !

@Mr.Green, does the pan message change if you select a different channel ?

[Freex]

Originally Posted by Geoff Waddington

Thanks for supportin' the folks whilst I'm slavin' away in the back room

Good on ya' !

@Mr.Green, does the pan message change if you select a different channel ?

It's the least I can do. (If it saves you a bit of time).

Now what are you doing here, there's work to do, get back to work. lol

[Mr. Green]

Hey guys - a few things to note:

Those results are the FP8 in it's native Studio One mode connecting with the MCU.rst template in the CSI setup. If I should connect with a different template, please let me know.

I'm definitely getting a few different variable outputs trying things out in MCU (Logic) mode (also connecting with the MCU.rst template). Plus the scribble strips are working. I'll post those results next...

[Mr. Green]

Faderport 8 IN values/MCU (Logic) mode:

connecting to CSI via MCU.rst Template

Rotary encoder knobs output no variable when pressed.

ALL buttons output following unless otherwise indicated:
push = 7f
release = 00

Pan/Param knob adjust
1st two variables conditional,
3rd variable output:
clockwise 1 step = "01"
counter-clockwise 1 step = "41"
increased steps (speed) outputs higher variables:
clockwise "02", "03", "04" etc. Max value = 3f
counter-clockwise "42", "43", "44" etc. Max value = 7f

Pan/Param push on knob
n/a

Pan/Param knob
ch1:
b0 10

ch2:
b0 11

ch3:
b0 12

ch4:
b0 13

ch5:
b0 14

ch6:
b0 15

ch7:
b0 16

ch8:
b0 17

Select buttons
ch1:
90 18
plus Section or Marker button
90 20

ch2:
90 19
plus Section or Marker button
90 21

ch3:
90 1a
plus Section or Marker button
90 22

ch4:
90 1b
plus Section or Marker button
90 23

ch5:
90 1c
plus Section or Marker button
90 24

ch6:
90 1d
plus Section or Marker button
90 25

ch7:
90 1e
plus Section or Marker button
90 26

ch8:
90 1f
plus Section or Marker button
90 27

Mute buttons
ch1:
90 10

ch2:
90 11

ch3:
90 12

ch4:
90 13

ch5:
90 14

ch6:
90 15

ch7:
90 16

ch8:
90 17

Solo buttons
ch1:
90 08

ch2:
90 09

ch3:
90 0a

ch4:
90 0b

ch5:
90 0c

ch6:
90 0d

ch7:
90 0e

ch8:
90 0f

ALL faders output the following variable:
touch = 7f
release = 00

Fader touch
ch1:
90 68

ch2:
90 69

ch3:
90 6a

ch4:
90 6b

ch5:
90 6c

ch6:
90 6d

ch7:
90 6e

ch8:
90 6f

ALL faders output 1:1 range variable:
Min value (bottom position) = 00
Max value (top position) = 7f

Fader adjust
ch1:
e0

ch2:
e1

ch3:
e2

ch4:
e3

ch5:
e4

ch6:
e5

ch7:
e6

ch8:
e7

ARM button
n/a (temporarilly illuminates record arming for selected channels)
Pressing Shift button (right) followed by the ARM button sends ARM function enable for any non-enabled channels in the current visible set of 8.


Select buttons (ARM function enable/disable)
ch1:
90 00

ch2:
90 01

ch3:
90 02

ch4:
90 03

ch5:
90 04

ch6:
90 05

ch7:
90 06

ch8:
90 07

Solo Clear button
90 47 7f
90 08 7f
90 08 00
90 47 00

Mute Clear button
90 47 7f
90 10 7f
90 10 00
90 47 00

Bypass button
90 49

Macro button
90 47

Link button
90 48

Shift button (left)
90 46

Track button
90 32 7f
90 32 00
90 2a 7f
90 2a 00

Edit Plugins button
90 2b (push/release sent on "push")

Sends button
90 29 (push/release sent on "push")

Pan button
90 2a (push/release sent on "push")

Audio button
90 40 7f
90 40 00
plus Shift button (right)
90 3f 7f
90 3f 00

VI button
90 41 7f
90 41 00
plus Shift button (right)
90 3e 7f
90 3e 00

Bus button
90 43 7f
90 43 00
plus Shift button (right)
90 44 7f
90 44 00

VCA button
90 42

All button
90 33

Shift button (right)
n/a

Latch button
90 4e 7f
90 4e 00
plus Shift button (right)
90 50 7f
90 50 00

Trim button
90 4c 7f
90 4c 00
plus Shift button (right)
90 46 7f
90 51 7f
90 51 00
90 46 00

Off button
n/a
plus Shift button (right)
90 51

Touch button
90 4d 7f
90 4d 00
plus Shift button (right)
90 53 7f
90 53 00

Write button
90 4b 7f
90 4b 00
plus Shift button (right)
90 52 7f
90 52 00

Read button
90 4a
plus Shift button (right)
n/a

Prev button (conditional)
plus Channel or Master button
90 30
plus Zoom button
90 60
plus Scroll button
b0 3c 41 (repeated 37 times)
plus Bank button
90 2e
plus Section or Marker button
90 5b

Next button (conditional)
plus Channel or Master button
90 31
plus Zoom button
90 61
plus Scroll button
b0 3c 01 (repeated 37 times)
plus Bank button
90 2f
plus Section or Marker button
90 5c

large scroll wheel adjust (conditional)
counter-clockwise plus Channel button
90 30 (push/release sent on "adjust")
clockwise plus Channel button
90 31 (push/release sent on "adjust")
counter-clockwise plus Zoom or Section button
90 62 (push/release sent on "adjust")
clockwise plus Zoom or Section button
90 63 (push/release sent on "adjust")
counter-clockwise plus Scroll button
b0 3c 41
clockwise plus Scroll button
b0 3c 01
counter-clockwise plus Bank button
90 2e (push/release sent on "adjust")
clockwise plus Bank button
90 2f (push/release sent on "adjust")
counter-clockwise plus Marker button
90 5b (push/release sent on "adjust")
clockwise plus Marker button
90 5c (push/release sent on "adjust")
clockwise plus Master button from lowest to highest (fully counter-clockwise to fully clockwise):
IN -> FP8 e8 00 00
IN -> FP8 e8 20 01
IN -> FP8 e8 40 02
IN -> FP8 e8 60 03
IN -> FP8 e8 00 05
IN -> FP8 e8 1f 06
IN -> FP8 e8 40 07
IN -> FP8 e8 60 08
IN -> FP8 e8 00 0a
IN -> FP8 e8 20 0b
IN -> FP8 e8 3f 0c
IN -> FP8 e8 60 0d
IN -> FP8 e8 00 0f
IN -> FP8 e8 20 10
IN -> FP8 e8 40 11
IN -> FP8 e8 60 12
IN -> FP8 e8 00 14
IN -> FP8 e8 20 15
IN -> FP8 e8 40 16
IN -> FP8 e8 60 17
IN -> FP8 e8 7f 18
IN -> FP8 e8 20 1a
IN -> FP8 e8 40 1b
IN -> FP8 e8 60 1c
IN -> FP8 e8 00 1e
IN -> FP8 e8 20 1f
IN -> FP8 e8 40 20
IN -> FP8 e8 60 21
IN -> FP8 e8 00 23
IN -> FP8 e8 20 24
IN -> FP8 e8 40 25
IN -> FP8 e8 60 26
IN -> FP8 e8 00 28
IN -> FP8 e8 20 29
IN -> FP8 e8 40 2a
IN -> FP8 e8 60 2b
IN -> FP8 e8 00 2d
IN -> FP8 e8 20 2e
IN -> FP8 e8 40 2f
IN -> FP8 e8 60 30
IN -> FP8 e8 7f 31
IN -> FP8 e8 20 33
IN -> FP8 e8 40 34
IN -> FP8 e8 60 35
IN -> FP8 e8 00 37
IN -> FP8 e8 20 38
IN -> FP8 e8 40 39
IN -> FP8 e8 60 3a
IN -> FP8 e8 00 3c
IN -> FP8 e8 20 3d
IN -> FP8 e8 40 3e
IN -> FP8 e8 60 3f
IN -> FP8 e8 00 41
IN -> FP8 e8 20 42
IN -> FP8 e8 40 43
IN -> FP8 e8 60 44
IN -> FP8 e8 00 46
IN -> FP8 e8 20 47
IN -> FP8 e8 40 48
IN -> FP8 e8 60 49
IN -> FP8 e8 00 4b
IN -> FP8 e8 20 4c
IN -> FP8 e8 40 4d
IN -> FP8 e8 60 4e
IN -> FP8 e8 00 50
IN -> FP8 e8 20 51
IN -> FP8 e8 40 52
IN -> FP8 e8 60 53
IN -> FP8 e8 00 55
IN -> FP8 e8 20 56
IN -> FP8 e8 40 57
IN -> FP8 e8 60 58
IN -> FP8 e8 00 5a
IN -> FP8 e8 20 5b
IN -> FP8 e8 40 5c
IN -> FP8 e8 60 5d
IN -> FP8 e8 00 5f
IN -> FP8 e8 20 60
IN -> FP8 e8 40 61
IN -> FP8 e8 60 62
IN -> FP8 e8 7f 63
IN -> FP8 e8 20 65
IN -> FP8 e8 40 66
IN -> FP8 e8 60 67
IN -> FP8 e8 00 69
IN -> FP8 e8 20 6a
IN -> FP8 e8 40 6b
IN -> FP8 e8 60 6c
IN -> FP8 e8 00 6e
IN -> FP8 e8 20 6f
IN -> FP8 e8 40 70
IN -> FP8 e8 60 71
IN -> FP8 e8 00 73
IN -> FP8 e8 20 74
IN -> FP8 e8 40 75
IN -> FP8 e8 60 76
IN -> FP8 e8 00 78
IN -> FP8 e8 20 79
IN -> FP8 e8 40 7a
IN -> FP8 e8 60 7b
IN -> FP8 e8 00 7d
IN -> FP8 e8 20 7e
IN -> FP8 e8 40 7f
IN -> FP8 e8 70 7f

large scroll wheel push button
n/a

Channel button
90 64 (push/release sent on "push")
plus Shift button (right)
90 36

Zoom button
90 64 (push/release sent on "push")
plus Shift button (right)
90 37

Scroll button
90 64 (push/release sent on "push")
plus Shift button (right)
90 38

Bank button
90 64 (push/release sent on "push")
plus Shift button (right)
90 39

Master button
n/a
plus Shift button (right)
90 3a

Click button
90 59
plus Shift button (right)
90 3b

Section button
**conditional:if previous navigation mode was either "Section" or "Marker", precede new variable output with repeat of previous variable output (push and release)
90 55
plus Shift button (right)
90 3c

Marker button
**conditional:if previous navigation mode was either "Section" or "Marker", precede new variable output with repeat of previous variable output (push and release)
90 54
plus Shift button (right)
90 3d

Loop button
90 56

RWND button
90 5b

FFWD button
90 5c

Stop button
90 5d

Record button
90 5f

Play button
90 5e

[Geoff Waddington]

Whoaaa -- you're workin' WAY too hard

Have a look at the MCU.rst file, yours should look very similar, with some variations -- the Right Shift modifier entires, for instance.

[Mr. Green]

Originally Posted by Geoff Waddington

Whoaaa -- you're workin' WAY too hard

Have a look at the MCU.rst file, yours should look very similar, with some variations -- the Right Shift modifier entires, for instance.

Ok - what should I do with that rst file? (please forgive me as I am just now entering at this stage of development). Should I try plugging in the values I posted here?

[Geoff Waddington]

Originally Posted by Mr. Green

Ok - what should I do with that rst file? (please forgive me as I am just now entering at this stage of development). Should I try plugging in the values I posted here?

Exactly, although you will find there is not much plugging to do

Almost everything I see in your post is standard Mackie stuff.

So, first make a copy of MCU.rst.

Rename it to FaderPort8.rst

Now, using the data you posted, verify that most of the mappings agree.

Here is an example:

Your post info:
Play button
90 5e

Line from Faderport8.rst:
Play Button 90 5e 00 7f

Just verify that your data agrees with what's in the file.

I seem to recall that they were using the Right Shift to support the function keys 36-3d, so you probably want to map that the same way.

Any questions more than welcomed, thanks for the effort !

When the file is ready, just make sure it is in the same folder as all the other .rst files.
Then you can select Faderport8.rst in the configuration dialog.
Now, every time Reaper loads it will use Faderport8.rst for your surface.

[Mr. Green]

Originally Posted by Geoff Waddington

Exactly, although you will find there is not much plugging to do

Almost everything I see in your post is standard Mackie stuff.

So, first make a copy of MCU.rst.

Rename it to FaderPort8.rst

Now, using the data you posted, verify that most of the mappings agree.

Here is an example:

Your post info:
Play button
90 5e

Line from Faderport8.rst:
Play Button 90 5e 00 7f

Just verify that your data agrees with what's in the file.

I seem to recall that they were using the Right Shift to support the function keys 36-3d, so you probably want to map that the same way.

Any questions more than welcomed, thanks for the effort !

When the file is ready, just make sure it is in the same folder as all the other .rst files.
Then you can select Faderport8.rst in the configuration dialog.
Now, every time Reaper loads it will use Faderport8.rst for your surface.

Thx! So I'm using that file now, and you're right; not much is really different yet. I don't yet have any Plugin control or Send level control (which are the two features I really need the most). Is that part still in the works?

[Freex]

Originally Posted by Mr. Green

Thx! So I'm using that file now, and you're right; not much is really different yet. I don't yet have any Plugin control or Send level control (which are the two features I really need the most). Is that part still in the works?

Yes, long story short, Geoff had to rethink things to make CSI even more customisable and super compatible with pretty much every surface.

The download at the minute, is a pre-alpha that has lots missing but allows us users to check everything that should work, does work.

For plugin control you need to develop .fxt files that basically tell the CSI what to do when it sees plugin-A on a channel. This part Geoff has had a big rethink on, mainly in part due to controller like the Mackie C4,

There is also the .axt file this tells the CSI how the midi info should be handled. If some of your parameters in the rst are different then you'll not see any change until you redefine the action associated with them.
Now as far as I'm aware thsee files could change, or need adjusted, as Geoff works thru the redesign. But messing with them will give you a better understanding of how all the files work together.

[Geoff Waddington]

Originally Posted by Freex

Yes, long story short, Geoff had to rethink things to make CSI even more customisable and super compatible with pretty much every surface.

The download at the minute, is a pre-alpha that has lots missing but allows us users to check everything that should work, does work.

For plugin control you need to develop .fxt files that basically tell the CSI what to do when it sees plugin-A on a channel. This part Geoff has had a big rethink on, mainly in part due to controller like the Mackie C4,

There is also the .axt file this tells the CSI how the midi info should be handled. If some of your parameters in the rst are different then you'll not see any change until you redefine the action associated with them.
Now as far as I'm aware thsee files could change, or need adjusted, as Geoff works thru the redesign. But messing with them will give you a better understanding of how all the files work together.

Yeah, about time for a redesign update, methinks...

About the only file that will see major change is CSI.ini, I hope.

Recall that a Cell is a collection of Widgets.

A typical example is a Channel Cell, which, on an MCU, contains:
DisplayUpper
DisplayLower
Rotary
RotaryPushTop
RecArm
Solo
Mute
Select
Fader
FaderTouch

A C4 Matrix Cell contains:
DisplayUpper
DisplayLower
Rotary
RotaryPushTop

A Console 1 Compressor Section Cluster Cell contains:
Wet/Dry
Ratio
Threshold
Attack
Release

Ok, the types:

Widget -- a single item -- Button, Display, Fader, Rotary, etc.
Cell -- contains one or more Widgets

Channel Cell -- contains Widgets stacked vertically
Channels -- horizontal layout of Channel Cells

Matrix Cell -- contains Widgets in some arbitrary layout -- e.g. C4 Cell
Matrix -- row/column layout of Matrix Cells

Cluster Cell -- contains Widgets is some arbitrary layout -- e.g. Console 1 Compressor Section

We already have Channel Cell working in the pre alpha

Just need to add Matrix and Cluster
Matrix is new, but Cluster kind of already exists, if you think about it.
Cluster is essentially an .fxt file in a slightly different format.

When we map an FX to a surface, we are really just changing from the "natural" surface type (e.g. Channel) to Cluster type -- Clusters make sense for things like FX.

Here's the Aha moment, occurred yesterday.

Why not provide the ability for the surface to morph, just like the Actions do by using different .axt files in different Virtual Surfaces.

Zones were always a mess.
Once you have Zones, you need Sub-Zones, Context specific Zones, etc., a mess.

So, with all that preamble out of the way, here's the latest thinking:

Introducing a new type of file -- .rsx -- real surface translation.

The hex is defined once only in the .rst file.

An .rsx file simply takes the names generated by the .rst file and morphs them according to new rules.

For instance, instead of thinking in an MCU Channel sense, you could think of the RecArm, Solo, Mute, and Select switches as a 4 row, 8 column matrix of switches.

The .rsx file provides the remapping from Channel sense to Matrix sense.

This allows any arbitrary grouping (clustering) of widgets, not just continuous blocks.

Now CSI is actually made simultaneously more flexible and less complex, a rare piece of luck indeed !

We know about Widgets, Cells, Channels, Matrices, Clusters.

Now the new containment structure:

A Page contains a number of Virtual Surfaces.
Virtual Surfaces on a Page:
Bank together
Shift together
Follow TCP/MCP visibility together
etc.

A Virtual Surface is a Real surface in a Page context that:
Uses an .axt file for mapping Widgets to Actions on this Page
Uses an .fxt file for mapping Widgets to FX on this Page
Possibly uses an .rsx file to morph the surface for our nefarious deeds on this page -- MWU-HHA-HA!

So no more Layouts, Zones, etc.

Just Pages comprised of Virtual Surfaces.

What say you ?

[fundorin]

Now it sounds more logical to me.
I still wish that you'd use JSON for FX mappings. Makes like much easier and allows some extra functionality, like mapping parameter ranges, continuous switches, toggling between predefined values of the certain parameter, etc.

[Mr. Green]

Originally Posted by Geoff Waddington

What say you ?

Sounds great to me! :-)

I'm no coder though, so I don't know if my opinion matters much.

I am curious; would I be correct in concluding that there is a good bit of feedback data communication that needs to occur with these control surfaces? It seems especially apparent in the FP8's Studio One mode, where it is clearly waiting for something to tell it what to do next. Actually using it in Studio One Pro, the unit is surprisingly capable, able to remap to any plugin parameter on the fly (like Reaper's OSC/MIDI FX mapping ?) with parameter names and values displayed, and also track colorizing as well. To see all that, data obviously has to be sent back from the DAW to the controller in use. Is that something that's easy to identify and customize?

Am I even asking a legitimate question here? lol

[Geoff Waddington]

Originally Posted by fundorin

Now it sounds more logical to me.
I still wish that you'd use JSON for FX mappings. Makes like much easier and allows some extra functionality, like mapping parameter ranges, continuous switches, toggling between predefined values of the certain parameter, etc.

Thanks, yeah the goal is getting it to be super flexible AND super easy, that's why I was resisting the temptation to parameterize everything early on

Perhaps after things have stabilized a bit it would make sense to add JSON file support to the simple native support we have now.

[Geoff Waddington]

Originally Posted by Mr. Green

Sounds great to me! :-)

I'm no coder though, so I don't know if my opinion matters much.

I am curious; would I be correct in concluding that there is a good bit of feedback data communication that needs to occur with these control surfaces? It seems especially apparent in the FP8's Studio One mode, where it is clearly waiting for something to tell it what to do next. Actually using it in Studio One Pro, the unit is surprisingly capable, able to remap to any plugin parameter on the fly (like Reaper's OSC/MIDI FX mapping ?) with parameter names and values displayed, and also track colorizing as well. To see all that, data obviously has to be sent back from the DAW to the controller in use. Is that something that's easy to identify and customize?

Am I even asking a legitimate question here? lol

All opinions matter here !

Yes, look at the ChannelDisplayUpper and ChannelDisplayLower Widgets in MCU.rst

[fundorin]

Originally Posted by Geoff Waddington

Perhaps after things have stabilized a bit it would make sense to add JSON file support to the simple native support we have now.

If you'll change your mind later, I can help you with this, since I've almost finished implementing that feature in my plugin.

[Geoff Waddington]

Gonna have to make an .axt change:

ChannelSelect TrackUniqueSelect
ShiftChannelSelect TrackRangeSelect
ControlChannelSelect TrackSelect

becomes:

ChannelSelect TrackUniqueSelect
Shift_ChannelSelect TrackRangeSelect
Control_ChannelSelect TrackSelect

Shouldn't be too disruptive I hope.

[Mr. Green]

Hey Geoff,

There is a really nice feature when using the Faderport 8 with Studio One that I am wondering (hoping) might be possible here (I can't replicate it with Klinke's driver):

While in Plugin Edit mode, I am able to select any plugin (using my touchscreen) and the FP8 automatically switches it's focus to that plugin - and any that follow. Same goes for the Sends mode; in that mode, any track I select automatically calls up all assigned sends for that track on the faders.

Will it be possible to have the FP8 (or any other controller for that matter) follow plugin and/or track selections the same way in Reaper?

Also, do you think it might be possible to create an option to allow the controller to automatically follow the selected track(s) in Track (Mix/Pan) mode as well?

[Geoff Waddington]

Originally Posted by Mr. Green

Hey Geoff,

There is a really nice feature when using the Faderport 8 with Studio One that I am wondering (hoping) might be possible here (I can't replicate it with Klinke's driver):

While in Plugin Edit mode, I am able to select any plugin (using my touchscreen) and the FP8 automatically switches it's focus to that plugin - and any that follow. Same goes for the Sends mode; in that mode, any track I select automatically calls up all assigned sends for that track on the faders.

Will it be possible to have the FP8 (or any other controller for that matter) follow plugin and/or track selections the same way in Reaper?

Yes, at least something like it

Here, it's set up so that when I select a Channel, the Console 1 EQ, Compressor, etc. control those FX on the Channel.

If the Console 1 Display button is on the appropriate FX windows show.

When you select a different Channel, the FX for that Channel are controlled by the Console 1, and the previous FX windows hide, and the FX windows for the newly selected Channel show.

Not exactly what you described, but similar and useful.

[Mr. Green]

I'll throw one more thing at you. :-)

There are a LOT of controllers out there that lack either "decent" scribble strips or scribble strips entirely. I've often wished someone could make some kind of "virtual" scribble strip that could be docked at the bottom of the screen. Maybe something with a customizable size, font, rows, columns, a few custom buttons. Easily repositioned to accurately align with an actual piece of hardware beneath the monitor.

...and since your driver would have access to that data that would otherwise be sent to the hardware.... ?

Wadda ya think? Am I taking it too far now? :-)

[Geoff Waddington]

Originally Posted by Geoff Waddington

Gonna have to make an .axt change

On second thought...

Belay that order cap'n

Found a way to do it without breaking existing .axt files.

[Geoff Waddington]

FYI update:

CSI is no longer in pieces on the ground and is slowly rising from the ashes, the Transport even works now

The good news is, so far anyway, only the CSI.ini file will change, and it is by far the simplest

[Zirrex]

Hi.
Your ideas are very interesting. I understand that you are developing an alternative to Klinke?

I have a question for you.
I have DAW Remote controller: iCON Platform M+ & Platform D
I have: Windows 8.1 (x64), Windows 10 (x64)

At the moment I have connected via Klinke.

There is one problem.
When you select a track, the iCON does not rewind to that track. ;-(
If I connect via Reaper MCU then rewind works.
Perhaps you know how to solve this problem?

[Gavinchan]

Originally Posted by Geoff Waddington

FYI update:

CSI is no longer in pieces on the ground and is slowly rising from the ashes, the Transport even works now

The good news is, so far anyway, only the CSI.ini file will change, and it is by far the simplest

Very exciting! Will be donating to the cause.

[Geoff Waddington]

Originally Posted by Zirrex

Hi.
Your ideas are very interesting. I understand that you are developing an alternative to Klinke?

I have a question for you.
I have DAW Remote controller: iCON Platform M+ & Platform D
I have: Windows 8.1 (x64), Windows 10 (x64)

At the moment I have connected via Klinke.

There is one problem.
When you select a track, the iCON does not rewind to that track. ;-(
If I connect via Reaper MCU then rewind works.
Perhaps you know how to solve this problem?

Not quite sure what you mean.

Anyway, CSI allows you to custom map your iCON surfaces to Actions, so it may be possible.

[Zirrex]

Originally Posted by Geoff Waddington

Not quite sure what you mean.

Anyway, CSI allows you to custom map your iCON surfaces to Actions, so it may be possible.

I solved the problem. Now everything works. :-)
CSI? What it is and where it is possible to try?

[mort_subite]

Anyone using this with a Behringer Motor49?


Does the CSI intend to replace Klinkes MCU extension, or are they something that can be used in tandem? Im only now learning about both of these extentions/drivers/whathaveyou, and I don't want to install some stuff that might conflict with each other, or confuse my already poorly documented control surface. What protocol is the CSI using? I'm trying to figure out how all this is going to work with the Motor series of controllers having a split layer of functionality, one being the MC protocol, and another straight MIDI, both of which Reaper recognizes, but Im not sure how all of that is going to flow under the control of CSI once I implement it.

Anyway, excellent work, everyone! Until now I've been really underwhelmed with control surface integration in any DAW, let alone my one true love, Reaper, so I'm extremely excited to see how this helps make my controller more usable with Reaper.

Cheers!

[mort_subite]

Originally Posted by Mr. Green

I'll throw one more thing at you. :-)

There are a LOT of controllers out there that lack either "decent" scribble strips or scribble strips entirely. I've often wished someone could make some kind of "virtual" scribble strip that could be docked at the bottom of the screen. Maybe something with a customizable size, font, rows, columns, a few custom buttons. Easily repositioned to accurately align with an actual piece of hardware beneath the monitor.

...and since your driver would have access to that data that would otherwise be sent to the hardware.... ?

Wadda ya think? Am I taking it too far now? :-)

I seriously hope this is a possibility. Seconding the usefulness this would provide.

One of the big things for me is knowing where I am within a fader bank as I move through a large project of more than 8 faders. Ive perused quite a bit of this thread, but dont really have the time to read all 27 pages, so forgive me if this has been discussed before, but feedback letting me know what fader Im about to touch will control what track in Reaper, and vice versa (Knowing what the corresponding hardware fader I'll need to move will be when Im looking at a track in Reaper)... all of that is SO crucial. Im not sure if its something I just need more usage time with, or does everyone have to pause for a minute and kind of mentally check where they're at in their fader bank? At any rate, I feel like this can only be a good thing for everyone involved (ESPECIALLY where submixing in Reapers folder structure is concerned... I feel like there's a lot to be done here, in terms of knowing what faders correspond to what tracks)!

Pretty much anything that could help the user know what hardware faders are corresponding to what tracks they're currently seeing on their screen, or knowing what hardware faders are currently controlling what group of tracks that may not be immediately visible on screen would be an immense help where having a limited number of faders controlling a large group of tracks is concerned.

[mort_subite]

Just a heads up, I sort of heavily edited my second to last post and my dumb ass forgot to kind of "version" it, so if anyone has read it before this post, go back and take a look, as Im asking different questions now (answered some for myself since posting, new questions arose).

[Geoff Waddington]

Originally Posted by mort_subite

Does the CSI intend to replace Klinkes MCU extension, or are they something that can be used in tandem?

Intended to replace, although they can be used in tandem.

Originally Posted by mort_subite

What protocol is the CSI using?

Right now just midi, but OSC is planned.

As far as the midi protocol (e.g. Mackie Control Protocol), it supports any and all, since you can define your own templates.

[mort_subite]

Originally Posted by Geoff Waddington

Intended to replace, although they can be used in tandem.



Right now just midi, but OSC is planned.

As far as the midi protocol (e.g. Mackie Control Protocol), it supports any and all, since you can define your own templates.

Thanks so much for the reply!

So I've successfully installed the plugin, and I've gotten to accessing it, but I can't quite figure out how to get it to work with my motor 49. I may just need to go back over the documentation, but it seemed like I was missing something, as I can't get anything to populate the "zones" field, and the "virtual surface" field won't allow me to add anything new to it (the menu dialog pops up, but nothing happens when I select things).

Is there any kind of more in depth instruction besides the Readme? A video or animated gif would be helpful.

Thanks again!

[Freex]

Originally Posted by mort_subite

Thanks so much for the reply!

So I've successfully installed the plugin, and I've gotten to accessing it, but I can't quite figure out how to get it to work with my motor 49. I may just need to go back over the documentation, but it seemed like I was missing something, as I can't get anything to populate the "zones" field, and the "virtual surface" field won't allow me to add anything new to it (the menu dialog pops up, but nothing happens when I select things).

Is there any kind of more in depth instruction besides the Readme? A video or animated gif would be helpful.

Thanks again!

Have you made a map of you device, and created a .rst file for said map?

Have you created a .axt file for said .rst? Telling it what each widget should do?

[Geoff Waddington]

FYI update:

Things are more or less back to where they were before the latest refactoring, but there is a bit of a performance loss.

Will be tuning that up a bit.

Then, will likely put up a new build.

[Freex]

Originally Posted by Geoff Waddington

FYI update:

Things are more or less back to where they were before the latest refactoring, but there is a bit of a performance loss.

Will be tuning that up a bit.

Then, will likely put up a new build.

looking forward to it.
Keep up the great work.

[matthew john]

Originally Posted by Geoff Waddington

Well i think you've cut to the chase here, yes, it is the OSC pad devices I'm considering, I think we're on the same page, sort of very smart but still glorified blinking light / touch input displays.

Hello Geoff,

my name is Matthew, I'm new to Reaper but not new to the business.
A few years ago I switched from Pro Tools to Cubase. I'm trying to find out if Reaper can be an option for the future.
To make a mix with mouse and keyboard, Reaper has everything Cubase offers. I come to a result in both programs.
I use three Avid Artist Mix and one Avid Transport for my daily work in Cubase.
The Eucon integration in cubase is pretty good.

The decision whether to use Reaper as my DAW in the future will be made dependent on the controller integration.

I have tried the following:

one artist mix with reaper - with the eucon beta plugin for reaper

one icon qcon pro x with reaper - with the mcu-klinke plugin for reaper
(I ordered the qcon for a 30 day trail)


let's start with eucon:

it all works pretty much the same as in cubase - with the help of the Eucon manual I made good progress. I particularly like the ability to set the fineness of the encoder with plug-in parameters. The mapping will take some time with my UAD collection - but I had to do this work with Cubase (Remote Control Editor) as well.

Now my questions:

I can not close plugin windows that I open with the artist mix. In Cubase I choose the "Top Back" button and the previously opened plugin window closes again.

Have I overlooked something or is this not working in Reaper?

What always bothered me about Cubase is that I have to open and close each plugin individually. If the Artist Mix is in the "Input" + "Channel" mode, all loaded plugins on the selected track will be displayed above the encoders. Pressing on an encoder opens the corresponding plugin. But if I want to open the next plugin I have to close the plugin with "top back" and open the desired plugin again with the next encoder. the artist mix does not follow changes (open/close plugins) i make with the mouse.

Is there in a possibility to switch between the individual insert effects of tracks and make the artist mix follow the selections of the mouse?
In the process, the controller should update itself. I open, for example in the first insert slot with the artist mix a plugin. The paramaters for this plugin are now visible on the artist mix. I would like to simply click through the plugin chain of this track with the mouse and the artist mix should follow. If I click on the first insert effect, the artist mix should show the parameters of this effect. I click with the mouse on the 2nd insert effect, the artist mix should show the parameters of this effect. this would be a fantastic worklow improvement for me. if you try to gainstage your insert channel for example.

is this possible in reaper?

I also tried the qcon with the mackie protocol from Klinke and that's exactly what is possible there. if you just have the fx paramater on the controller, the controller always updates itself when i click on another plugin.

but over all I'm happier with the eucon protocol, the feel is just way better. pan settings are possible with absolute value - mackie is skipping some values - not that this would be necessary for life - nobody cares if the guitar is panned to 67 or 68 percent. but the speed of the encoder is simply better with the artist mix - I'm probably too used to the device.

would be cool if you can give me a little feedback to my questions. cause if i can do the same things in reaper with my controllers as in cubase i would look deeper into this daw. if i can do less than in cubase it can be a dealbreaker.

thanks in advance
greetings
Matthew