Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by MixMonkey

My initial thoughts about matrix use was FX control and Sends and I was expecting them to be on different Pages (with everything else on the 2 Pages being identical) On one Page the non-banking surface controlled FX on the selected channel and on the other Page it controlled Sends.

I've started to wonder whether it would be possible to share a non-banking controller (one that has a lot of controls, like, you guessed it, a C4) between Sends and FX control. So, say, the top row would always be sends on the selected channel and the lower 3 rows would be FX control.

Would this constitute more than one Matrix definition on a Page?

Thanks for the discussion, which was followed by my morning walk and some good contemplation

I think there are 2 separate concepts, one on the .rst side, and one on the .axt/.fxt side.

Here's the current thinking:
On the Surface and Page config panels -- Matrix Section -- checkbox and 2 entry fields - NumRows and NumColumns.
Also on the Surface config panel -- top left corner position in Page Matrix.

The above describes mapping of the Physical controllers matrices to the Page Matrix, this is equivalent to the Channel concept and will be in the .rst.

Note there is nothing stopping you from mapping BOTH Channel and Matrix
e.g. The MCU could have normal Channel mapping, but it could also simultaneously have a Matrix mapping, which, it turns out, would be identical to a C4 MatrixCell - DisplayUpper, DisplayLower, Rotary, RotaryPush


MatrixCell
DisplayUpper
DisplayLower
Rotary
RotaryPush
MatrixCellEnd

As far as Sends/FX etc., I think that info belongs in .axt/.fxt files and represents the Logical matrices on this page -- allowing overlap would be a typical solution to your Sends/FX use case.

And yeah, I think you could carve it up even finer.

I rarely have more than 4 sends, so you could set up A1, A2, A3, A4 for Sends.

A4-A8 -- I rarely have more than 4 FX so this could drill down into each FX using the lower 3 rows.

Lots of possibilities...

[Freex]

Originally Posted by Geoff Waddington

Thanks for the discussion, which was followed by my morning walk and some good contemplation

I think there are 2 separate concepts, one on the .rst side, and one on the .axt/.fxt side.

Here's the current thinking:
On the Surface and Page config panels -- Matrix Section -- checkbox and 2 entry fields - NumRows and NumColumns.
Also on the Surface config panel -- top left corner position in Page Matrix.

The above describes mapping of the Physical controllers matrices to the Page Matrix, this is equivalent to the Channel concept and will be in the .rst.

Note there is nothing stopping you from mapping BOTH Channel and Matrix
e.g. The MCU could have normal Channel mapping, but it could also simultaneously have a Matrix mapping, which, it turns out, would be identical to a C4 MatrixCell - DisplayUpper, DisplayLower, Rotary, RotaryPush


MatrixCell
DisplayUpper
DisplayLower
Rotary
RotaryPush
MatrixCellEnd

As far as Sends/FX etc., I think that info belongs in .axt/.fxt files and represents the Logical matrices on this page -- allowing overlap would be a typical solution to your Sends/FX use case.

And yeah, I think you could carve it up even finer.

I rarely have more than 4 sends, so you could set up A1, A2, A3, A4 for Sends.

A4-A8 -- I rarely have more than 4 FX so this could drill down into each FX using the lower 3 rows.

Lots of possibilities...

If I'm understanding you, could we conceivably have on the C4,
For the selected channel

A1 - A4 SENDS(slots 1-4)

A5 - A8 (Push showing the FX in lower 3 rows, Rotary Wet/dry mix level of that FX)

B1 - D8 configured to control each FX in slots 1-4 (view being controlled by the above (A5-A8)

[Geoff Waddington]

Originally Posted by Freex

If I'm understanding you, could we conceivably have on the C4,
For the selected channel

A1 - A4 SENDS(slots 1-4)

A5 - A8 (Push showing the FX in lower 3 rows, Rotary Wet/dry mix level of that FX)

B1 - D8 configured to control each FX in slots 1-4 (view being controlled by the above (A5-A8)

Yes, exactly

We still have to figure out how to state that in a .axt/.fxt file in a reasonable way, but that's the planned flexibility for matrices.

[MixMonkey]

Originally Posted by Geoff Waddington

Note there is nothing stopping you from mapping BOTH Channel and Matrix
e.g. The MCU could have normal Channel mapping, but it could also simultaneously have a Matrix mapping, which, it turns out, would be identical to a C4 MatrixCell - DisplayUpper, DisplayLower, Rotary, RotaryPush

It would be nice if the whole of the MCU channel was available when matrix mapped. In the Sends scenario, that would put send level on the fader; solo, mute and pan buttons would apply to the send, rec, and select could be repurposed- pre/post etc.

This would make setting up headphones mixes really easy. Different layers- different sends. Hopefully this would also be bankable.

[Geoff Waddington]

Originally Posted by MixMonkey

It would be nice if the whole of the MCU channel was available when matrix mapped. In the Sends scenario, that would put send level on the fader; solo, mute and pan buttons would apply to the send, rec, and select could be repurposed- pre/post etc.

This would make setting up headphones mixes really easy. Different layers- different sends. Hopefully this would also be bankable.

Yes, of course, I was just using an obvious example.

You've nailed the whole point of the project really, the ability to integrate various surfaces in different ways, all customized to your workflow.

[MixMonkey]

So would we switch between assignments (normal channel behaviour to send behaviour, say) by changing to a different Page or will it be within a single Page?

I'd be happy setting these up on different pages and switching between them.

[Geoff Waddington]

Originally Posted by MixMonkey

So would we switch between assignments (normal channel behaviour to send behaviour, say) by changing to a different Page or will it be within a single Page?

Totally up to you, depends on how you want to map it.

It likely will make sense for you to use a fairly different mapping strategy than, say, someone with a single Faderport 8.

[Geoff Waddington]

A bit more thinking...

Don't think the Page Matrix is necessary.

Since the .axt/.fxt files are on a per surface basis, the surface matrix is all that matters.

Note that plugin definitions can still span surfaces, there will just be 2 .axt/.fxt files, each with a partial definition.

The Matrix definition for the surface will be similar to the Channel definition, it will be stored in the .rst file.

Things get interesting in the .axt/.fxt files, where a surface could be defined as several logical matrices, think the earlier example of sends/fx on top row and 3 rows of selected FX params -- that could be thought of as 3 separate logical matrices -- Sends -- Plugins -- Plugin Params.

Just thinking' out loud

[MixMonkey]

Originally Posted by Geoff Waddington

Totally up to you, depends on how you want to map it.

So, having thought about it a bit , I could map the sends to faders idea already (I've just made up the handles for illustration) by creating a new MCU.axt, along the lines of:

DisplayUpper TrackNameDisplay
DisplayLower TrackTouchControlled SendPanDisplay SendVolumeDisplay
Fader SendVolume
FaderTouch SendTouch
Rotary SendPan
Select TrackUniqueSelect?
Shift+Select TrackRangeSelect
Control+Select TrackSelect
RecordArm SendPre
Mute SendMute
Solo TrackSolo

..and access it by creating a new page. When I switch to the new page, the faders and other channel controls map to a send, everything else stays the same. Or am I reaching here

Originally Posted by Geoff Waddington

The Matrix definition for the surface will be similar to the Channel definition, it will be stored in the .rst file.

So is a matrix just a channel with all the rows identical? Like the existing C4.rst definition.

Originally Posted by Geoff Waddington

Things get interesting in the .axt/.fxt files, where a surface could be defined as several logical matrices, think the earlier example of sends/fx on top row and 3 rows of selected FX params -- that could be thought of as 3 separate logical matrices -- Sends -- Plugins -- Plugin Params

Wouldn't it just be the same as the surface matrix definition with different parts accessed longhand by different functions:

RotaryA1 Send1Level
.....
RotaryA4 Send4Level

RotaryA5 FX1Mix
.....
RotaryA8 FX4Mix

Toggle+RotaryPushA1 Send1Mute
....
Toggle+RotaryPushA4 Send4Mute

Toggle+RotaryPushA5 SelectFX1
.....
Toggle+RotaryPushA1 SelectFX4

The bit I don't see at the moment is how 'Toggle+RotaryPushA5 SelectFX1' assigns B1-D8 to the FX1 .fxt map....

[Geoff Waddington]

Originally Posted by MixMonkey

So, having thought about it a bit , I could map the sends to faders idea already (I've just made up the handles for illustration) by creating a new MCU.axt, along the lines of:

DisplayUpper TrackNameDisplay
DisplayLower TrackTouchControlled SendPanDisplay SendVolumeDisplay
Fader SendVolume
FaderTouch SendTouch
Rotary SendPan
Select TrackUniqueSelect?
Shift+Select TrackRangeSelect
Control+Select TrackSelect
RecordArm SendPre
Mute SendMute
Solo TrackSolo

..and access it by creating a new page. When I switch to the new page, the faders and other channel controls map to a send, everything else stays the same. Or am I reaching here

Not reaching at all, using the software exactly as intended.

Just need some new actions -- SendVolume, SendPan, SendPre, SendMute, etc.

Originally Posted by MixMonkey

So is a matrix just a channel with all the rows identical? Like the existing C4.rst definition.

Even simpler, if the rows are identical like the C4.

The .rst will describe only one cell, just like it describes only one channel:

MatrixCell
DisplayUpper
DisplayLower
Rotary
RotaryPush
MatrixCellEnd

The matrix dimensions will be described in the CSI.ini file just like the number of channels:

MidiSurface MCU1 8 Bankable 0 0 MCU.rst MCU MCU
MidiMatrixSurface myC4 4 8 NonBankable 3 3 C4.rst C4 C4

Originally Posted by MixMonkey

Wouldn't it just be the same as the surface matrix definition with different parts accessed longhand by different functions:

RotaryA1 Send1Level
.....
RotaryA4 Send4Level

RotaryA5 FX1Mix
.....
RotaryA8 FX4Mix

Toggle+RotaryPushA1 Send1Mute
....
Toggle+RotaryPushA4 Send4Mute

Toggle+RotaryPushA5 SelectFX1
.....
Toggle+RotaryPushA1 SelectFX4

The bit I don't see at the moment is how 'Toggle+RotaryPushA5 SelectFX1' assigns B1-D8 to the FX1 .fxt map....

Sure, this is one possible solution, and yes, we would need a SelectFX action

That is likely not sufficient though.

Folks will likely want to navigate FX slots on the C4, similar to channel/bank navigation on the MCU/XT.

That's the part that's taking up my brain time right now, how to do slot navigation in a reasonable way.

[Freex]

Originally Posted by Geoff Waddington

Not reaching at all, using the software exactly as intended.

Just need some new actions -- SendVolume, SendPan, SendPre, SendMute, etc.



Even simpler, if the rows are identical like the C4.

The .rst will describe only one cell, just like it describes only one channel:

MatrixCell
DisplayUpper
DisplayLower
Rotary
RotaryPush
MatrixCellEnd

The matrix dimensions will be described in the CSI.ini file just like the number of channels:

MidiSurface MCU1 8 Bankable 0 0 MCU.rst MCU MCU
MidiMatrixSurface myC4 4 8 NonBankable 3 3 C4.rst C4 C4



Sure, this is one possible solution, and yes, we would need a SelectFX action

That is likely not sufficient though.

Folks will likely want to navigate FX slots on the C4, similar to channel/bank navigation on the MCU/XT.

That's the part that's taking up my brain time right now, how to do slot navigation in a reasonable way.

Would the SWS/S&M command suffice?

SWS/S&M: Select next FX (cycling) for selected tracks _S&M_SELFXNEXT
SWS/S&M: Select previous FX (cycling) for selected tracks _S&M_SELFXPREV

the it would just be getting the feedback from reaper that things had changed.

I'm honestly just guesting....

[mschnell]

Originally Posted by Freex

Would the SWS/S&M command suffice?

SWS is a Reaper extension. Hence CSI could (supposedly better) implement that functionality itself.

-Michael

[Freex]

Originally Posted by mschnell

SWS is a Reaper extension. Hence CSI could (supposedly better) implement that functionality itself.

-Michael

I was only thinking, if the wheel's already there, why reinvent it?

[mschnell]

not re-invent, just re-implement

-Michael

[Geoff Waddington]

Originally Posted by Freex

Would the SWS/S&M command suffice?

SWS/S&M: Select next FX (cycling) for selected tracks _S&M_SELFXNEXT
SWS/S&M: Select previous FX (cycling) for selected tracks _S&M_SELFXPREV

the it would just be getting the feedback from reaper that things had changed.

I'm honestly just guesting....

Yeah, not really what we need here, as FX 1, 2, 3, and 4 may be mapped on the C4 and we might want to go to the next 4 -- FX 5, 6, 7, and 8.

I'm leaning towards a simple scheme whereby the Surface Matrix is defined in the .rst and CSI.ini files and then we just build an FX matrix for each track.

Then it's just a matter of navigating the Surface matrix over the FX matrix, consistent with the Channel behaviour.

[Geoff Waddington]

Originally Posted by mschnell

not re-invent, just re-implement

-Michael

Haha, good one

I finally found the X Touch Compact native midi map and it looks like you should use 0x01 instead of 0x7f for the lit push button on state.

Could you try that and see what happens.

[Freex]

Originally Posted by Geoff Waddington

Yeah, not really what we need here, as FX 1, 2, 3, and 4 may be mapped on the C4 and we might want to go to the next 4 -- FX 5, 6, 7, and 8.

I'm leaning towards a simple scheme whereby the Surface Matrix is defined in the .rst and CSI.ini files and then we just build an FX matrix for each track.

Then it's just a matter of navigating the Surface matrix over the FX matrix, consistent with the Channel behaviour.

I understand what you're saying, for the scenario posted, but you had said about using the Slot Buttons to navigate the FX, I just thought this would be a quick way for getting that function.

Yes if, as in the scenario, we had 4 fx buttons to display the first 4 fx we'd need a way of banking to the next 4 slots.

[Freex]

Originally Posted by mschnell

not re-invent, just re-implement

-Michael

Yes I was suggesting we re-implement to action, to speed things up.

Is there really a valid case to reinvent the same action, just because?

Obviously in as Jeff stated, in the scenario, there is a different set of problems, not just simple FX slot navigation, (up and down), but almost a banking function.

[Geoff Waddington]

Originally Posted by Freex

Yes I was suggesting we re-implement to action, to speed things up.

Is there really a valid case to reinvent the same action, just because?

Actually, SWS is open source, so sometimes it's easier to just incorporate the SWS source code directly in the CSI project.

[MixMonkey]

Originally Posted by Geoff Waddington

Not reaching at all, using the software exactly as intended

Good Glad I'm starting to get my head round it.

Originally Posted by Geoff Waddington

Sure, this is one possible solution, and yes, we would need a SelectFX action

Actually I see now why defining logical matrices would be necessary. In the Sends-FX-FXParameter example, you need to be able to step through or switch to other layers in each matrix to access more controls, either more sends (yikes!), more FX slots and definitely more FX parameters. If the three logical matrices that inhabit the surface matrix aren't separately defined, you can't do this.

[Freex]

Originally Posted by Geoff Waddington

Actually, SWS is open source, so sometimes it's easier to just incorporate the SWS source code directly in the CSI project.

Hey Geoff, you're the boss here, so if it's easier for you that's your call.

I only suggested them as I know that those functions work as expected on the C4, just alas no feed back for the C4 to jump into action. Or it could be just me lol. It's most likely just me. pmsl.

With the above scenario, it's 4 fx, 4 sends,
I presume that each FX button would need some extra code to ask for feedback,

What if you had more than 4 sends or more than 4 fx,

Would there be away, of lets say,
having the sends populate the top row of the C4, only when the send on the MCU is pressed (whether that be press&hold or toggle on/off
and the same for inputs and outputs, if single button/function,
but let say you choose 2 or more at once, so Inputs, outputs and sends, or any combination.

Then would it be more suitable to have the 3 populate 3 rows (8 each)

Or the top row, and maybe use the track L& trackR buttons to cycle thru them,

Another thought for the track L&R buttons on the C4 could be if you have an FX map that is bigger than 3 or 4 rows (depending on the above) where they could be used to scroll FX within the page and having the slot Up&down buttons to move to a new FX.

Hope that makes some sense.

[mschnell]

Originally Posted by Geoff Waddington

I finally found the X Touch Compact native midi map and it looks like you should use 0x01 instead of 0x7f for the lit push button on state.

Where did you find that information ?

In fact there is no "X Touch Compact native midi map", as using the editor software, you can define the Note no and Midi channel for each button, and I never saw any Velocity value "1" to be sent out by the Compact nor to be relevant relevant on the normal Midi channel in receive, nor that the light is supposed to react on different midi messages than those that the button sends.

How should this prevent the Compact from killing the light on button release ?

Should I test with the current version of CSI (which never send the current state on button release ?

With which rst - keyword should I use for a test ?

In fact you can remote-contrl the button Leds by Note on/off on the "Global" midi channel to set them to on, off or blinking. But as the Compact sends on the normal channel, CSI would need to use another channel for sending than for receiving, and AFAIK, there is no rst keyword that can do this. (In fact on the long run this would be nice, as you can set the LEDs to blink, but in the pre-Alpha phase I would not go after that, but stick to the list I posted a while ago.)

BTW.:
Regarding the LED remote control on the Global Midi channel, my Compact docs say Velocity 0->off, 1->on, 2->blink. I found that to be erroneous. In fact it's 0->off, 2->on, 3->blink. Don't ask me, why.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

Where did you find that information ?

In fact there is no "X Touch Compact native midi map", as using the editor software, you can define the Note no and Midi channel for each button, and I never saw any Velocity value "1" to be sent out by the Compact nor to be relevant relevant on the normal Midi channel in receive, nor that the light is supposed to react on different midi messages than those that the button sends.

How should this prevent the Compact from killing the light on button release ?

Should I test with the current version of CSI (which never send the current state on button release ?

With which rst - keyword should I use for a test ?

In fact you can remote-contrl the button Leds by Note on/off on the "Global" midi channel to set them to on, off or blinking. But as the Compact sends on the normal channel, CSI would need to use another channel for sending than for receiving, and AFAIK, there is no rst keyword that can do this. (In fact on the long run this would be nice, as you can set the LEDs to blink, but in the pre-Alpha phase I would not go after that, but stick to the list I posted a while ago.)

BTW.:
Regarding the LED remote control on the Global Midi channel, my Compact docs say Velocity 0->off, 1->on, 2->blink. I found that to be erroneous. In fact it's 0->off, 2->on, 3->blink. Don't ask me, why.

-Michael

Ahh, OK, I got the info out of the Quick Start Guide around the end, but it seems you have already discovered that those docs are wrong

[Geoff Waddington]

Originally Posted by Freex

With the above scenario, it's 4 fx, 4 sends,
I presume that each FX button would need some extra code to ask for feedback,

What if you had more than 4 sends or more than 4 fx,

Would there be away, of lets say,
having the sends populate the top row of the C4, only when the send on the MCU is pressed (whether that be press&hold or toggle on/off
and the same for inputs and outputs, if single button/function,
but let say you choose 2 or more at once, so Inputs, outputs and sends, or any combination.

Then would it be more suitable to have the 3 populate 3 rows (8 each)

Or the top row, and maybe use the track L& trackR buttons to cycle thru them,

Another thought for the track L&R buttons on the C4 could be if you have an FX map that is bigger than 3 or 4 rows (depending on the above) where they could be used to scroll FX within the page and having the slot Up&down buttons to move to a new FX.

Hope that makes some sense.

Yeah, that's why it's bending my brain thinking about this, there are so many options, unlike Channels, which have a fairly universal definition.

[Freex]

Originally Posted by Geoff Waddington

Yeah, that's why it's bending my brain thinking about this, there are so many options, unlike Channels, which have a fairly universal definition.

I'd be happy with,press button display

So if I press Input I see inputs spanning across the C4,

If I press output I see all outputs,

If I press FX I'd see FX and navigate by using slot buttons.

Sends is the only one I think maybe could vary, but maybe just 8 channels with 4 sends and maybe shift+sends could show them 4 channels with 8 sends.

Just thinking out loud.

[MixMonkey]

The trouble with mapping multiple 'channels' of sends to the C4 comes when you have more than 8 faders to play with. (eg MCU+XT+XT)

If you only have the one MCU (ie 8 faders) it's straightforward- the C4 banks with the MCU (on a new Page) showing 4 sends for each channel.

If you have more than 8 faders (eg MCU+XT+XT) , which surface does the C4 display sends for? Sure, we could set things up so we can switch the C4 from surface to surface but this strikes me as over complicated (it would drive me nuts) or you could bank in 8s instead of 24s so you could move the channels in question onto the surface that the C4 was following. Again, madness will follow shortly after.

The two ways I see as being easiest to understand and use are:

i) If you want to see ONE send on multiple channels, I think my fader switch Page described earlier is the way to go. Of course, there's nothing to stop you mapping the one send to the channel rotary and leaving it at that (and all other channel controls stay the same) We will need a way to step through the sends. This method ensures that the sends and the channels are always aligned. If you have 24 faders, you see 24 sends.

ii) If you want to see MULTIPLE sends on one channel, use one column on the C4 and have it display the sends for the selected channel. We still need a way to step through the sends, only this time in jumps of 4. At a push you add columns for more sends, but I'd rather think up/down for sends.

I did consider a third way, for displaying multiple sends for one channel across the MCU (faders or rotaries) but discarded the idea again because (in a fast moving mix enviroment) it would also drive me nuts This may work for other people who don't have C4 but have a tighter grip on their sanity than I do

[_Stevie_]

I'm configuring a Steinberg CMC-FD and took over some parts of the MCU (most of it is compatible, since the FD uses Mackie assignments).



The unit has 4 faders. In the MCU config it says:

Channel
Fader        Fader14BitFB -60.0 12.0 e0 7f 7f e0 00 00
DisplayUpper MCUDisplayUpper
FaderTouch   PressRelease 90 68 7f  90 68 00
Solo 	     PressFB 	  90 08 7f  90 08 00
Mute 	     PressFB 	  90 10 7f  90 10 00
ChannelEnd

The faders strangely all work, eventhough, only the first one seems configured (e0)? Is that normal, since CSI expects e1, e2, e3 as the next faders?
And: is it possible to hardwire the faders to specific channels?

[Freex]

Originally Posted by MixMonkey

The trouble with mapping multiple 'channels' of sends to the C4 comes when you have more than 8 faders to play with. (eg MCU+XT+XT)

If you only have the one MCU (ie 8 faders) it's straightforward- the C4 banks with the MCU (on a new Page) showing 4 sends for each channel.

If you have more than 8 faders (eg MCU+XT+XT) , which surface does the C4 display sends for? Sure, we could set things up so we can switch the C4 from surface to surface but this strikes me as over complicated (it would drive me nuts) or you could bank in 8s instead of 24s so you could move the channels in question onto the surface that the C4 was following. Again, madness will follow shortly after.

The two ways I see as being easiest to understand and use are:

i) If you want to see ONE send on multiple channels, I think my fader switch Page described earlier is the way to go. Of course, there's nothing to stop you mapping the one send to the channel rotary and leaving it at that (and all other channel controls stay the same) We will need a way to step through the sends. This method ensures that the sends and the channels are always aligned. If you have 24 faders, you see 24 sends.

ii) If you want to see MULTIPLE sends on one channel, use one column on the C4 and have it display the sends for the selected channel. We still need a way to step through the sends, only this time in jumps of 4. At a push you add columns for more sends, but I'd rather think up/down for sends.

I did consider a third way, for displaying multiple sends for one channel across the MCU (faders or rotaries) but discarded the idea again because (in a fast moving mix enviroment) it would also drive me nuts This may work for other people who don't have C4 but have a tighter grip on their sanity than I do

What if you had each vertical on the C4 display 4 sends for that channel, so on the C4 you'd see 8 channels at once, I wonder if it would be poosible to use the slot up/down to "see" then next 4 sends (5-8)



Or 1 send per knob per channel, so you see 32 channels (whether that's based on A1 showing your selected channel) showing send 1, then by pressing (a button slot up/down) you get send 2, and cycle that way thru the sends,

Or 2 sends per channels, so you see 16 channels.
A1=send 1 channel 1__A2=S1ch2
B1=s2ch1_____________B2=s2ch2
C1=s1ch9_____________c2=s1ch10
D1=s2ch9_____________d2=s2ch10

Personally I like the notion of 8 channels 4 sends, then slot down for next 4,etc, then use the track l/r to move channels like banking, but in 8s
So if you had 16 faders on your mcu&xt, you could have your bank set to 16, but still have the track l/r set to 8. So the slotup/down and the Track l/r become almost your navigation arrows on the C4.

Just throwin ideas at the wall, see if any stick.

[mschnell]

Originally Posted by Geoff Waddington

I finally found the X Touch Compact native midi map and it looks like you should use 0x01 instead of 0x7f for the lit push button on state.

In fact there would be an (IMHO good) way to allow for supporting weired button implementations by surface devices including the "automatic LED", the "Global Channel" and the "Blink" features of the XTouch Compact, and including the possibility to turn a Surface Rotary in a pair of up/down buttons.

This of course contradicts your thrive to hide the underlying complexity from the would-be rst-file creators, but this IMHO does not do any harm, as the "easy" keywords you already do provide would of course still be in place.

so I suggest an rst keyword "PressGeneric" that takes six parameters:
- message to be received to define the "pressed" state
- message to be received to define the "released" state (for buttons that are used in a "shift" function together with other control elements)
- message to be received to trigger the sending of the current state of the software control element
- message to be received to trigger the sending of the current state of the software control element (just another one for the same functionality)
- message to send to the surface to set the LED to signal state "on"
- message to send to the surface to set the LED to signal state "off"

For relaxing the Ḿidi traffic and the file edit, unused messages could be denoted by a "-" instead of the three hex values (can be omitted if no hex values are to follow).

(If the triggered functionality is not "stateful", either of "on" or "off" state will be sent, if a send-trigger and these messages are defined.)

e.g.
simple (e.g. toggle) ("Press") button without feedback :
PressGeneric 9d 20 7f

"shift" ("PressRelease") button without Feedback
PressGeneric 9d 20 7f 8d 20 00

"toggle" ("PressFB") (does not work with XTouch Compact):
PressGeneric 9d 20 7f - 8d 20 7f - 9d 20 7f 8d 20 00

"shift" ("PressReleaseFB") (also works for XTouch Compact):
PressGeneric 9d 20 7f 9d 20 7f 8d 20 00 9d 20 7f 8d 20 00

usual "toggel" ("PressFB") button e.g. for an XTouch Compact:
PressGeneric 9d 20 7f - 8d 20 00 - 9d 20 7f 8d 20 00

convert surface Rotary to a pair of up/down buttons:
BankLeft PressGeneric bd 19 3F - bd 19 3F - bd 19 40 bd 19 40
BankRight PressGeneric bd 19 41 - bd 19 41 - bd 19 40 bd 19 40

blinking "toggel" button e.g. for an XTouch Compact, using the Global channel:
PressGeneric 9d 20 7f - - 8d 20 00 9f 20 03 9f 20 00

(Please ignore
To make things even more complex: if the CSI software supports three-state-toggle buttons, a seventh parameter could support this by making use of the blink feature, going through "on" "blink" and "off":
3StateControl PressGeneric 9d 20 7f - - 8d 20 00 9f 20 03 9f 20 02 9f 20 00
)

-Michael

[Geoff Waddington]

Originally Posted by Freex

I'd be happy with,press button display

So if I press Input I see inputs spanning across the C4,

If I press output I see all outputs,

If I press FX I'd see FX and navigate by using slot buttons.

Sends is the only one I think maybe could vary, but maybe just 8 channels with 4 sends and maybe shift+sends could show them 4 channels with 8 sends.

Just thinking out loud.

Thanks for justifying the project's existence, see next post

[Geoff Waddington]

Originally Posted by MixMonkey

The trouble with mapping multiple 'channels' of sends to the C4 comes when you have more than 8 faders to play with. (eg MCU+XT+XT)

If you only have the one MCU (ie 8 faders) it's straightforward- the C4 banks with the MCU (on a new Page) showing 4 sends for each channel.

If you have more than 8 faders (eg MCU+XT+XT) , which surface does the C4 display sends for? Sure, we could set things up so we can switch the C4 from surface to surface but this strikes me as over complicated (it would drive me nuts) or you could bank in 8s instead of 24s so you could move the channels in question onto the surface that the C4 was following. Again, madness will follow shortly after.

The two ways I see as being easiest to understand and use are:

i) If you want to see ONE send on multiple channels, I think my fader switch Page described earlier is the way to go. Of course, there's nothing to stop you mapping the one send to the channel rotary and leaving it at that (and all other channel controls stay the same) We will need a way to step through the sends. This method ensures that the sends and the channels are always aligned. If you have 24 faders, you see 24 sends.

ii) If you want to see MULTIPLE sends on one channel, use one column on the C4 and have it display the sends for the selected channel. We still need a way to step through the sends, only this time in jumps of 4. At a push you add columns for more sends, but I'd rather think up/down for sends.

I did consider a third way, for displaying multiple sends for one channel across the MCU (faders or rotaries) but discarded the idea again because (in a fast moving mix enviroment) it would also drive me nuts This may work for other people who don't have C4 but have a tighter grip on their sanity than I do

See previous post, and add your use cases above -- voila !! -- we have the reason for this project

Not only does workflow dictate preferred setups, but context matters as usual, in this case context = hardware / OSC surfaces.

Different (heterogeneous mix of) surfaces + different workflow = reason for CSI

[Geoff Waddington]

Originally Posted by _Stevie_

I'm configuring a Steinberg CMC-FD and took over some parts of the MCU (most of it is compatible, since the FD uses Mackie assignments).



The unit has 4 faders. In the MCU config it says:

Channel
Fader        Fader14BitFB -60.0 12.0 e0 7f 7f e0 00 00
DisplayUpper MCUDisplayUpper
FaderTouch   PressRelease 90 68 7f  90 68 00
Solo 	     PressFB 	  90 08 7f  90 08 00
Mute 	     PressFB 	  90 10 7f  90 10 00
ChannelEnd

The faders strangely all work, eventhough, only the first one seems configured (e0)? Is that normal, since CSI expects e1, e2, e3 as the next faders?
And: is it possible to hardwire the faders to specific channels?

The
Channel
...
ChannelEnd

notation is just a convenience that auto-generates the messages, so, yes, you can leave out the Channel definition and have 8 Fader, 8 Mute, etc. definitions.

As far as hardwiring, if you mean hardwiring a Channel, see above,

if you mean hardwiring a Track, then you need to map buttons on the CMC to the Pin/Unpin actions, see the F7-F8 mappings in the MCU.axt file.

If you map 2 buttons as per above, you can the Pin/Unpin selected Tracks.

[Geoff Waddington]

Originally Posted by Freex

What if you had each vertical on the C4 display 4 sends for that channel, so on the C4 you'd see 8 channels at once, I wonder if it would be poosible to use the slot up/down to "see" then next 4 sends (5-8)



Or 1 send per knob per channel, so you see 32 channels (whether that's based on A1 showing your selected channel) showing send 1, then by pressing (a button slot up/down) you get send 2, and cycle that way thru the sends,

Or 2 sends per channels, so you see 16 channels.
A1=send 1 channel 1__A2=S1ch2
B1=s2ch1_____________B2=s2ch2
C1=s1ch9_____________c2=s1ch10
D1=s2ch9_____________d2=s2ch10

Personally I like the notion of 8 channels 4 sends, then slot down for next 4,etc, then use the track l/r to move channels like banking, but in 8s
So if you had 16 faders on your mcu&xt, you could have your bank set to 16, but still have the track l/r set to 8. So the slotup/down and the Track l/r become almost your navigation arrows on the C4.

Just throwin ideas at the wall, see if any stick.

Thanks for adding more use cases, we will hopefully support a large number of them.

[Geoff Waddington]

Originally Posted by mschnell

In fact there would be an (IMHO good) way to allow for supporting weired button implementations by surface devices including the "automatic LED", the "Global Channel" and the "Blink" features of the XTouch Compact, and including the possibility to turn a Surface Rotary in a pair of up/down buttons.

This of course contradicts your thrive to hide the underlying complexity from the would-be rst-file creators, but this IMHO does not do any harm, as the "easy" keywords you already do provide would of course still be in place.

so I suggest an rst keyword "PressGeneric" that takes six parameters:
- message to be received to define the "pressed" state
- message to be received to define the "released" state (for buttons that are used in a "shift" function together with other control elements)
- message to be received to trigger the sending of the current state of the software control element
- message to be received to trigger the sending of the current state of the software control element (just another one for the same functionality)
- message to send to the surface to set the LED to signal state "on"
- message to send to the surface to set the LED to signal state "off"

For relaxing the Ḿidi traffic and the file edit, unused messages could be denoted by a "-" instead of the three hex values (can be omitted if no hex values are to follow).

(If the triggered functionality is not "stateful", either of "on" or "off" state will be sent, if a send-trigger and these messages are defined.)

e.g.
simple (e.g. toggle) ("Press") button without feedback :
PressGeneric 9d 20 7f

"shift" ("PressRelease") button without Feedback
PressGeneric 9d 20 7f 8d 20 00

"toggle" ("PressFB") (does not work with XTouch Compact):
PressGeneric 9d 20 7f - 8d 20 7f - 9d 20 7f 8d 20 00

"shift" ("PressReleaseFB") (also works for XTouch Compact):
PressGeneric 9d 20 7f 9d 20 7f 8d 20 00 9d 20 7f 8d 20 00

usual "toggel" ("PressFB") button e.g. for an XTouch Compact:
PressGeneric 9d 20 7f - 8d 20 00 - 9d 20 7f 8d 20 00

convert surface Rotary to a pair of up/down buttons:
BankLeft PressGeneric bd 19 3F - bd 19 3F - bd 19 40 bd 19 40
BankRight PressGeneric bd 19 41 - bd 19 41 - bd 19 40 bd 19 40

blinking "toggel" button e.g. for an XTouch Compact, using the Global channel:
PressGeneric 9d 20 7f - - 8d 20 00 9f 20 03 9f 20 00

(Please ignore
To make things even more complex: if the CSI software supports three-state-toggle buttons, a seventh parameter could support this by making use of the blink feature, going through "on" "blink" and "off":
3StateControl PressGeneric 9d 20 7f - - 8d 20 00 9f 20 03 9f 20 02 9f 20 00
)

-Michael

[mschnell]

Originally Posted by Geoff Waddington

Flexibility vs complexity

OK, but
1) this consideration does not help if some lack of features rules out usability in some instances considered important.

2) my suggestion above does not increase complexity for the users a bit, as those who don't need it can just ignore it. And regarding the internal complexity of the program I (being a programmer myself) don't think that it adds much complexity, as (as shown above) the existing "Press..." keywords all are siblings of this concept, and the infrastructure obviously already provides all necessary pieces.

I do understand and happily accept that this has rather low priority for you right now, as most primary application will be tied to MCU-like protocols. But something like "PressGeneric" would allow for integrating a lot of devices in a decent way.

-Michael

[_Stevie_]

Originally Posted by Geoff Waddington

The
Channel
...
ChannelEnd

notation is just a convenience that auto-generates the messages, so, yes, you can leave out the Channel definition and have 8 Fader, 8 Mute, etc. definitions.

As far as hardwiring, if you mean hardwiring a Channel, see above,

Awesome, so CSI even has artificial intelligence and generates the next channels automatically!
This really kicks ass Geoff. I started configuring the CMC yesterday and I'm almost done. The device is finally usable in Reaper. Thanks so much!

if you mean hardwiring a Track, then you need to map buttons on the CMC to the Pin/Unpin actions, see the F7-F8 mappings in the MCU.axt file.

If you map 2 buttons as per above, you can the Pin/Unpin selected Tracks.

Got it, will check it out, thanks!

Is it possible to send a sysex string on initalization? Let me explain: the LEDs of the CMC devices are usually turned off, however, there's a "dimmed" mode which can be activated by a sysex string. Can we send this kind of init message, when CSI is loaded?

[Geoff Waddington]

Originally Posted by mschnell

OK, but
1) this consideration does not help if some lack of features rules out usability in some instances considered important.

2) my suggestion above does not increase complexity for the users a bit, as those who don't need it can just ignore it. And regarding the internal complexity of the program I (being a programmer myself) don't think that it adds much complexity, as (as shown above) the existing "Press..." keywords all are siblings of this concept, and the infrastructure obviously already provides all necessary pieces.

I do understand and happily accept that this has rather low priority for you right now, as most primary application will be tied to MCU-like protocols. But something like "PressGeneric" would allow for integrating a lot of devices in a decent way.

-Michael

I agree with you, I'm just trying to find a way to make this as simple as possible, but no simpler

[Geoff Waddington]

Originally Posted by _Stevie_

Is it possible to send a sysex string on initalization? Let me explain: the LEDs of the CMC devices are usually turned off, however, there's a "dimmed" mode which can be activated by a sysex string. Can we send this kind of init message, when CSI is loaded?

Great feature request !

I'll think about how to include it.

[_Stevie_]

Woop, awesome! Thanks Geoff!

[_Stevie_]

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

1. ability to trigger scripts and SWS actions
2. key repetition, especially useful for rewind and fast forward commands