Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by mschnell

Anyway: no "fader" entry there, at all .

-Michael

Exactly what file are you talking about ?

[Geoff Waddington]

Originally Posted by MixMonkey

MCU Upper display now working, Lower display just shows: .....................

Got it.

How about the XT displays ?

Originally Posted by MixMonkey

Non-mapped widgets no longer crash Reaper, but now there's a new crash scenario: Select a channel that has a plugin, fiddle with a few plugin controls on the C4, select a different channel- Reaper crashes.

Thanks, just tried it here and seems fine, but I was working on some stuff yesterday that might have inadvertently fixed it.

Could you post you the contents of the C4 .fxt map for any plugin that causes this ?

Are you using the new stock C4.rst ?

Originally Posted by MixMonkey

Regarding the parameter names, can I just put all of them in quotes- even the ones without spaces?

Sure.

[MixMonkey]

XT displays same, Upper fine, Lower ...........

Working on a mix at the mo’, so on Windows. Will check C4 stuff tomorrow and report back. Did the build change since yesterday?

Incidentally, I always test using the same plugin- Bx Control from Plugin Alliance. Good combination of switches and rotaries. Plugin Alliance are pretty reliable in terms of automation implantation (in my experience) I try to keep the variables down to a minimum when testing.

[loupis45]

Originally Posted by Geoff Waddington

Hmmm...

What is EuControl 18.3.0 244 ?
I thought they were at 3.8.x.x
Running 3.7.0 134 here

Do you mean Reaper 5.79 ?

Can you please post the contents of the CSI.ini file and the .rst, .axt and .fxt files that you are using.

Sounds like it might just be mapping issues.

Eucontrol 18.3.0.244 is the 3.8 as AVID says on download page
"EUCON 18.3 (formally 3.8) - Windows (64-bit)
Size: 110 MB Revision date: March 19th, 2018"

For Reaper yes. I was add wrong dot! is the 5.79

Here is the contents of files

CSI.ini:
MidiInMonitor On
MidiOutMonitor On
VSTMonitor Off

RealSurface Control 4 2 2 ArtistMCU.rst

Page BluePage No Yes 89 134 255
VirtualSurface 0 Control ArtistMCU MCU

ArtistMCU.axt:
ChannelLeft TrackBank -1
ChannelRight TrackBank 1
BankLeft TrackBank -20
BankRight TrackBank 20
Rewind Rewind
FastForward FastForward
Stop Stop
Play Play
Record Record
F1 NextPage
F7 PinSelectedTracks
F8 UnpinSelectedTracks
Read TrackAutoMode 1
Write TrackAutoMode 3
Trim TrackAutoMode 0
Touch TrackAutoMode 2
Latch TrackAutoMode 4
Group TrackAutoMode 5
Shift+Read GlobalAutoMode 1
Shift+Write GlobalAutoMode 3
Shift+Trim GlobalAutoMode 0
Shift+Touch GlobalAutoMode 2
Shift+Latch GlobalAutoMode 4
Shift+Group GlobalAutoMode 5
Save Reaper 40026
Shift+Save Reaper 40022
Undo Reaper 40029
Shift+Undo Reaper 40030
Marker Reaper 40172
Shift+Marker Reaper 40157
Option+Marker Reaper 40174
Nudge Reaper 40173
Cycle CycleTimeline
Click Reaper 40364
Zoom LatchedZoom
Scrub LatchedScrub

DisplayUpper TrackTouchControlled TrackNameDisplay TrackVolumeDisplay
Fader TrackVolume
FaderTouch TrackTouch
Rotary TrackCycle RotaryPush "TrackPan 0" "TrackPanWidth 1"
Select TrackUniqueSelect
Shift+Select TrackRangeSelect
Control+Select TrackSelect
RecordArm TrackRecordArm
Mute TrackMute
Solo TrackSolo


MCU.axt

ChannelLeft TrackBank -1
ChannelRight TrackBank 1
BankLeft TrackBank -8
BankRight TrackBank 8
TimeDisplay TimeDisplay
Rewind Rewind
FastForward FastForward
Stop Stop
Play Play
Record Record
F1 NextPage
F7 PinSelectedTracks
F8 UnpinSelectedTracks
Read TrackAutoMode 1
Write TrackAutoMode 3
Trim TrackAutoMode 0
Touch TrackAutoMode 2
Latch TrackAutoMode 4
Group TrackAutoMode 5
Shift+Read GlobalAutoMode 1
Shift+Write GlobalAutoMode 3
Shift+Trim GlobalAutoMode 0
Shift+Touch GlobalAutoMode 2
Shift+Latch GlobalAutoMode 4
Shift+Group GlobalAutoMode 5
Save Reaper 40026
Shift+Save Reaper 40022
Undo Reaper 40029
Shift+Undo Reaper 40030
Marker Reaper 40172
Shift+Marker Reaper 40157
Option+Marker Reaper 40174
Nudge Reaper 40173
Cycle CycleTimeline
Click Reaper 40364
Zoom LatchedZoom
Scrub LatchedScrub

VUMeter TrackOutputMeter 0
VUMeter TrackOutputMeter 1
DisplayUpper TrackNameDisplay
DisplayLower TrackTouchControlled TrackPanDisplay TrackVolumeDisplay
Fader TrackVolume
FaderTouch TrackTouch
Rotary TrackCycle ChannelRotaryPush "TrackPan 0" "TrackPanWidth 1"
Select TrackUniqueSelect
Shift+Select TrackRangeSelect
Control+Select TrackSelect
RecordArm TrackRecordArm
Mute TrackMute
Solo TrackSolo


Thanks Geoff

[Geoff Waddington]

Originally Posted by loupis45

Eucontrol 18.3.0.244 is the 3.8 as AVID says on download page
"EUCON 18.3 (formally 3.8) - Windows (64-bit)
Size: 110 MB Revision date: March 19th, 2018"

I would try 3.7.0 134, my Avid Artist Control works fine here in a Mac environment.

Originally Posted by loupis45

Here is the contents of files

CSI.ini:
MidiInMonitor On
MidiOutMonitor On
VSTMonitor Off

RealSurface Control 4 2 2 ArtistMCU.rst

Page BluePage No Yes 89 134 255
VirtualSurface 0 Control ArtistMCU MCU

Change to: VirtualSurface 1 Control ArtistMCU MCU

[Geoff Waddington]

Originally Posted by MixMonkey

XT displays same, Upper fine, Lower ...........

Did things somehow get into channel meter mode, where lower is horizontal meter ?

Originally Posted by MixMonkey

Incidentally, I always test using the same plugin- Bx Control from Plugin Alliance. Good combination of switches and rotaries. Plugin Alliance are pretty reliable in terms of automation implantation (in my experience) I try to keep the variables down to a minimum when testing.

Could you please post .fxt contents for this -- thanks

[loupis45]

Originally Posted by Geoff Waddington

I would try 3.7.0 134, my Avid Artist Control works fine here in a Mac environment.



Change to: VirtualSurface 1 Control ArtistMCU MCU

Thanks. Works ok now. I see midi messages from my controller
If i press choose colour page, still hangs reaper
Also motorized faders from Euphonix MC Control, they do not respond
I have try the EuControl 3.7 but same things

[mschnell]

Originally Posted by Geoff Waddington

Rotaries like yours are Fader7Bit/Fader7BitFB
Rotaries like the MCU are Encoder/EncoderFB

Let's not use the word Rotary in this context, let's be explicit and say either Fader7Bit or Encoder.

Very much agreed !
In fact the "physical rotaries" of the XTouch behave exactly as the faders (only the fader touch is a note-on/off by default, while the Rotary Push is a CC 00/7f)

Originally Posted by Geoff Waddington

As far as your use case, it's probably way easier and better to implement an Action that simply stores the last value sent from a Fader7Bit and sends Reaper +1 if the current value is greater and -1 if it is less.

This seems viable, but it would limit the range of the +/- action to 127 steps. OTOH the LED indicator would show the state, which might be desirable. An additional problem might be to sync the target of the +/- action with the "Fader" position.

Originally Posted by Geoff Waddington

That way, if you have more than one Action assigned to the Fader7Bit you won't be messing all those other Actions up by monkeying around with the Fader7Bit control surface value.

I don't see this problem, but some problems might arise when actually using it the way I suggested....

-Michael

[mschnell]

Originally Posted by Geoff Waddington

Exactly what file are you talking about ?

C4.rst. I suppose this is the one you recommended to look for a 7 bit implementation for the channel faders.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

C4.rst. I suppose this is the one you recommended to look for a 7 bit implementation for the channel faders.

-Michael

Ahh, now I see, have a look at Console1.rst for 7 bit faders.

[mschnell]

Originally Posted by Geoff Waddington

have a look at Console1.rst for 7 bit faders.

OK, thats easy. Of course it works.

But as said it would make sense to limit the slider range especially for 7 bit controllers. I do understand this is intended to be done in another file (supposedly *.axt -> "Fader TrackVolume ....").

Standing by until an update regarding the weired XControl buttons is available ...
-Michael

[Geoff Waddington]

I'll put up a build tomorrow that hopefully fixes most, if not all of the issues from the latest round of changes.

However...

Been thinking the last couple of days about a simplifying change that also adds flexibility.

How about we forget about all this Real Surface / Virtual Surface stuff and just have Pages which contain Surfaces.

Surfaces can be Midi, OSC, etc.

Effectively this means combining the Real Surface / Virtual Surface dialogs in the config panel.

It increases complexity slightly -- you have to state the midi I/O, number of faders, and .rst file for each page, even though they are often (usually) the same.

However, the win is twofold:

Simpler interface, both in terms of concept, and also actual configuration.

Flexibility -- with per page .rst files it will now be possible to do things like having an encoder be an up/down switch on one page and a rotary on another page.

Unless I hear some valid reason not to do this, I will go ahead, I think it's a better solution overall.

As always comments/suggestions more than welcomed !

[mschnell]

While I usually prefer a more complex structure over more complex "elements" of the user interface, I am very reluctant to strictly reply "No", as I am not sure that I did fully grasp the current concept, due to me not being experienced at all with this stuff.

-Michael

[CDS]

is the control surface integration thread going to include Linux?

[Geoff Waddington]

Originally Posted by CDS

is the control surface integration thread going to include Linux?

Not planned right now, you can just use the Windows version under WINE.

[Skijumptoes]

Originally Posted by Geoff Waddington

How about we forget about all this Real Surface / Virtual Surface stuff and just have Pages which contain Surfaces.

Surfaces can be Midi, OSC, etc.

Effectively this means combining the Real Surface / Virtual Surface dialogs in the config panel.

I was thinking similar last week, i think this is a really good way to move forwards. Personally for me it's more logical, and less complex, at least in terms of being straightforward with the functionality of each hardware control per page.

[Geoff Waddington]

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

@Michael, can you please check PressFB and see if it now works as expected with the X Touch Compact ?

Various other tweaks, etc., mostly internal.

[mschnell]

No. Worse than before.

Now no output at all after releasing the button. Resulting in the same behavior as before with e.g. Solo, but with the play / stop combination that showed a sensible patten before, now the last pressed button always gets dim on release.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

No. Worse than before.

Now no output at all after releasing the button. Resulting in the same behavior as before with e.g. Solo, but with the play / stop combination that showed a sensible patten before, now the last pressed button always gets dim on release.

-Michael

OK, I guess for now go back to using PressReleaseFB.

[mschnell]

Originally Posted by Geoff Waddington

OK, I guess for now go back to using PressReleaseFB.

Which of course is good for "select" but unusable for "solo" and friends, as it can't handle toggle toggle controls, resetting them on button release.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

Which of course is good for "select" but unusable for "solo" and friends, as it can't handle toggle toggle controls, resetting them on button release.

-Michael

Agree, but next up, is the redesign of the Real Surface/Virtual Surface interface as per a few posts back.

I think we're going to have to add special Controls for the X Touch Compact.

[MixMonkey]

New build working well here

No crashes with selecting a different track after plugin fiddling as before. No crashes at all actually. Plugin rotaries and pushes working well.

Lower display restored by deleting: "VUMeter TrackOutputMeter 0" and "VUMeter TrackOutputMeter 1" from the MCU/MCUXT .axt file. Now have pan (or fader position when touched) back. Flashing the 'Signal' light still preferable to using the MCU display for meters.

The nifty Pan/StereoWidth toggle on ChannelRotaryPush seems to have got broken with the button defs redesign.

Regarding combining the real and virtual surfaces, I don't see a problem here.

Presumably, if you wanted a rotary to be an up/down switch on one Page and a rotary on another, you would need two .rst files (for the same surface) to carry the two definitions on different Pages, but most of the time the Pages would use a single .rst and even when they differed, most of the .rst would be the same.

Nice work Geoff (particulary like the way the surfaces zero themselves when you quit Reaper!)

[Geoff Waddington]

Originally Posted by MixMonkey

New build working well here

No crashes with selecting a different track after plugin fiddling as before. No crashes at all actually. Plugin rotaries and pushes working well.

Great !

Originally Posted by MixMonkey

Lower display restored by deleting: "VUMeter TrackOutputMeter 0" and "VUMeter TrackOutputMeter 1" from the MCU/MCUXT .axt file. Now have pan (or fader position when touched) back. Flashing the 'Signal' light still preferable to using the MCU display for meters.

Yeah, VUMeter TrackOutputMeter is my attempt at showing the signal lights WITHOUT putting the lower displays into Channel Meter Mode, looks like the first attempt failed

Originally Posted by MixMonkey

The nifty Pan/StereoWidth toggle on ChannelRotaryPush seems to have got broken with the button defs redesign.

Yup, found a typo in MCU.axt, change:

Rotary TrackCycle ChannelRotaryPush "TrackPan 0" "TrackPanWidth 1"

to:

Rotary TrackCycle RotaryPush "TrackPan 0" "TrackPanWidth 1"

Originally Posted by MixMonkey

Regarding combining the real and virtual surfaces, I don't see a problem here.

Presumably, if you wanted a rotary to be an up/down switch on one Page and a rotary on another, you would need two .rst files (for the same surface) to carry the two definitions on different Pages, but most of the time the Pages would use a single .rst and even when they differed, most of the .rst would be the same.

Yup, my thinking exactly, pretty cheap way to get way more flexibility, and it simplifies the UI concepts nicely too !

Originally Posted by MixMonkey

Nice work Geoff (particulary like the way the surfaces zero themselves when you quit Reaper!)

Thanks.

[mschnell]

Originally Posted by Geoff Waddington

I think we're going to have to add special Controls for the X Touch Compact.

Yep we do need a keyword that (re-)sends the current (would-be) state on release to switch the light correctly.

OTOH, while this might seem unusual with MC's and intelligent software in mind, I don't think it's restricted to XControls, that the light directly follows the messages sent by the button. This is useful for controlling certain devices that don't give a feedback to the surface.

IMHO, as well keywords something like

"PressFBonRelease 9d 10 7f 8d 10 00" (re-sending the state when receiving the second message) for buttons with internally couplet lights as

"PressFBFake bd 10 3f bd 10 40" (sending the second message when receiving the first) to do fake-button pairs from a physical rotary

make a lot of sense.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

Yep we do need a keyword that (re-)sends the current (would-be) state on release to switch the light correctly.

Agree.

Originally Posted by mschnell

OTOH, while this might seem unusual with MC's and intelligent software in mind, I don't think it's restricted to XControls, that the light directly follows the messages sent by the button. This is useful for controlling certain devices that don't give a feedback to the surface.

It can also be disastrous.

If you used this with Console 1 on a rotary, you would end up with a rotary that would behave erratically, since sending the value also SETS the fader value.

So everyone will now just have to be careful and use the correct Widget type.

Was trying to avoid that...

Originally Posted by mschnell

IMHO, as well keywords something like

"PressFBonRelease 9d 10 7f 8d 10 00" (re-sending the state when receiving the second message) for buttons with internally couplet lights as

Let's call it PressFBR.

Originally Posted by mschnell

"PressFBFake bd 10 3f bd 10 40" (sending the second message when receiving the first) to do fake-button pairs from a physical rotary

make a lot of sense.

-Michael

Still like doing this one via software.

[mschnell]

Originally Posted by Geoff Waddington

So everyone will now just have to be careful and use the correct Widget type.

I doubt that this can be avoided, and IMHO it's not a problem, but an obvious consequence of the goal to be able to support a wide range of devices.

Regarding the behavior of the surfaces, the same "keyword" in fact might be used to different purposes (or be completely unusable) with different surfaces.

Most "users" will rely on configurations prepared for their devices by "experts", anyway, And the "experts" should be able to know what they do.

-Michael

[mschnell]

Originally Posted by Geoff Waddington

Still like doing this one via software.

This might really be a good idea, but supposedly more work for you.

And as said, as a "physical" rotary of the type used in the X-Touch moves its internal value when turning, it can't be a decent incremental encoder, because it simply stops sending anything when running over the min or max values.

Maybe the "fake feed back" even might come handy for completely other purposes.

BTW.: On the X-Touch, the way the LEDs of the physical rotaries work can be configured using certain (normal) Midi messages. It might be nice to be able to send such a block of predefined midi messages when starting and/or when swapping to different pages (such a controls for FXes).

-Michael

[Geoff Waddington]

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

Brand new simplified config panel !

The color picker is kind of funky, you select a page then press the Color button.
This gets around the Windows hang issue for now, I'll try for a better fix later.

Since Surfaces are now wholly within Pages, you can have a different definition (.rst file) on each Page for the same physical Surface.

Even updated the ReadMe

[MixMonkey]

Great Quick work!

Can I still use the existing .rst, .axt and .fxt files?

I noticed "DisplayUpperA C4DisplayUpper" has appeared in the C4.rst. Does this mean C4 display of FX params is possible?

[Geoff Waddington]

Originally Posted by MixMonkey

Great Quick work!

Can I still use the existing .rst, .axt and .fxt files?

Yes.

Originally Posted by MixMonkey

I noticed "DisplayUpperA C4DisplayUpper" has appeared in the C4.rst. Does this mean C4 display of FX params is possible?

Yes, perfect segue into the next task, matrix definition...

I'm leaning towards introducing a new keyword, "Row".

The C4.rst would look like this:

Channel

Row
DisplayUpper C4DisplayUpper
DisplayLower C4DisplayLower
RotaryPush Press 90 20 7f
Rotary EncoderFB b0 00 7f b0 00 00
RowEnd

Row
DisplayUpper C4DisplayUpper
DisplayLower C4DisplayLower
RotaryPush Press 90 28 7f
Rotary EncoderFB b0 08 7f b0 08 00
RowEnd

Row
DisplayUpper C4DisplayUpper
DisplayLower C4DisplayLower
RotaryPush Press 90 30 7f
Rotary EncoderFB b0 10 7f b0 10 00
RowEnd

Row
DisplayUpper C4DisplayUpper
DisplayLower C4DisplayLower
RotaryPush Press 90 38 7f
Rotary EncoderFB b0 18 7f b0 18 00
RowEnd

ChannelEnd

OK, that's the .rst, now we need an equivalent .axt matrix representation...

[MixMonkey]

So 4 rows (horizontal) to go with the 8 'channels' (vertical) as defined in the .ini (the new 'MIDI Surface' config box)?

I guess there's no reason each row has to be the same (as it is on the C4) just as long as it repeats across the defined number of 'channels' (vertically)?

[Geoff Waddington]

Originally Posted by MixMonkey

So 4 rows (horizontal) to go with the 8 'channels' (vertical) as defined in the .ini (the new 'MIDI Surface' config box)?

I guess there's no reason each row has to be the same (as it is on the C4) just as long as it repeats across the defined number of 'channels' (vertically)?

Hmmm...

I think of it this way for the C4:

8 channels (columns) arranged horizontally -- channels are beside each other
4 rows arranged vertically -- rows are above/below each other

As far as row definition, I think it's best to define the rows in the .rst as per a couple of posts back, there will never be a large number of rows, that implies a humongous controller -- I guess an argument could be made for OSC software apps -- but for now let's just use the notation Row ... RowEnd for each row.

It also works well with the midi message definition shortcut provided by the channel syntax.

As far as .axt/.fxt maybe:

Cell 1 4
DisplayUpper DisplayName
DisplayLower DisplayValue
Rotary FXCycle RotaryPush Freq Q
CellEnd

This defines a Cycled control at row 1, column 4, much like the Pan/Width control.
However, this one controls either Freq or Q, presumably on an EQ plugin.

Cell 1 5
DisplayUpper DisplayName
DisplayLower DisplayValue
Rotary Threshold
CellEnd

This defines a control at row 1, column 5, that controls Threshold.
The RotaryPush is unused.

Seems straightforward, see any holes folks ?

[MixMonkey]

Originally Posted by Geoff Waddington

Hmmm...

I think of it this way for the C4:

8 channels (columns) arranged horizontally -- channels are beside each other
4 rows arranged vertically -- rows are above/below each other

I think we're describing the same thing

---------Ch1--Ch2.......Ch7--Ch8
Row A . A1---A2.........A7---A8
Row B . B1---B2.........B7---B8
Row C . C1---C2........C7---C8
Row D . D1---D2........D7---D8

Originally Posted by Geoff Waddington

Seems straightforward, see any holes folks ?

No holes, but in the existing C4.rst, rows are A,B,C,D. In the .axt/.fxt example they're now numbers. Maybe use one or the other in both for clarity. I'd prefer rows to be letters and columns numbers.

As mentioned before, we'll need a 'Layer' definition before all the Cell definitions to allow FXetc to span more than one surface worth of controls.

It's probably a bit early for this, but regarding the displays (or at least Upper) we'll need to be able to alias the actual parameter name (the one internal in the VST) to something readable (usually shorter) on the limited space of the display. I'd prefer if this could be entered manually, maybe something like the WaddC4 system:

Cell 1 5
DisplayUpper DisplayName | Thresh
DisplayLower DisplayValue
Rotary Threshold
CellEnd

Cell 1 4
DisplayUpper DisplayName | Frq | BW |
DisplayLower DisplayValue
Rotary FXCycle RotaryPush Freq Q
CellEnd

If no alias entry is made, the internal VST parameter name is used.

Since i'm in future mode at the moment, the place to address controller acceleration is probably:

Cell 1 5
DisplayUpper DisplayName | Thresh
DisplayLower DisplayValue
Rotary | 64 |Threshold
CellEnd

Where 64 is the acceleration factor, maybe 0-no acceleration and 127-max acceleration and negative numbers producing deceleration (to counteract a surface's built in acceleration if needed)

[Geoff Waddington]

Originally Posted by MixMonkey

I think we're describing the same thing

---------Ch1--Ch2.......Ch7--Ch8
Row A . A1---A2.........A7---A8
Row B . B1---B2.........B7---B8
Row C . C1---C2........C7---C8
Row D . D1---D2........D7---D8




No holes, but in the existing C4.rst, rows are A,B,C,D. In the .axt/.fxt example they're now numbers. Maybe use one or the other in both for clarity. I'd prefer rows to be letters and columns numbers.

Agree letters for rows and numbers for columns is best, let's go with that.

Originally Posted by MixMonkey

As mentioned before, we'll need a 'Layer' definition before all the Cell definitions to allow FXetc to span more than one surface worth of controls.

Yeah, something like a matrix version of Channels, except that now each channel can have neighbours not just left/right, but up/down as well.

Should probably allow for holes as well (sparse matrix).

Originally Posted by MixMonkey

It's probably a bit early for this, but regarding the displays (or at least Upper) we'll need to be able to alias the actual parameter name (the one internal in the VST) to something readable (usually shorter) on the limited space of the display. I'd prefer if this could be entered manually, maybe something like the WaddC4 system:

Cell 1 5
DisplayUpper DisplayName | Thresh
DisplayLower DisplayValue
Rotary Threshold
CellEnd

Cell 1 4
DisplayUpper DisplayName | Frq | BW |
DisplayLower DisplayValue
Rotary FXCycle RotaryPush Freq Q
CellEnd

If no alias entry is made, the internal VST parameter name is used.

Great point !

Let's use our already established quote mechanism for the syntax a la:

DisplayUpper "DisplayName |Thresh |"

DisplayUpper "DisplayName | Frq | BW |"

I like keeping the old vertical bars -- makes padding, etc. easier

Originally Posted by MixMonkey

Since i'm in future mode at the moment, the place to address controller acceleration is probably:

Cell 1 5
DisplayUpper DisplayName | Thresh
DisplayLower DisplayValue
Rotary | 64 | Threshold
CellEnd

Where 64 is the acceleration factor, maybe 0-no acceleration and 127-max acceleration and negative numbers producing deceleration (to counteract a surface's built in acceleration if needed)

Once again, great point !

Once again let's use quotes:

"Rotary 64" Threshold

[MixMonkey]

Just installed the latest build- all working well

Deleted my old CSI.ini but kept my old .rst,.axt and .fxt files and rebuilt from scratch in the new edit dialogue. Took 2mins. Much easier to understand than the old method, methinks.

Made that change to MCU.axt and MCUXT.axt you suggested and the Pan/Width toggle is now back

[Freex]

I really need to get the studio back up and running and get using...
I'm reading MixMonkeys comments and every one makes me more excited to use my MCU/XT but mostly I'm super stocked to be able to use the C4, REALLY USE the C4, for the first time.
Great work Geoff, and equally great testing and feed back MixMonkey.
(obviously there are others doing great work testing on other surfaces...but I don't care about them...it's all about me, me, me and my gear. lol)
Honestly super thread and super progress,

Thanks.

[MixMonkey]

Originally Posted by Freex

I'm reading MixMonkeys comments and every one makes me more excited to use my MCU/XT but mostly I'm super stocked to be able to use the C4, REALLY USE the C4, for the first time.

Geoff's made some incredible headway in the last couple of weeks, handling a complete redesign of the button system and simplifying the setup dialogue. I hope he sleeps

The next big step is to get the matrix up and running so that non-banking controllers of different sizes can be mapped to FX (you can map in a basic way at the moment, but without display feedback and only on one 'layer')

The creation of the matrix will allow you to define 'rows' and 'channels(columns)' for your non-banking controller and map the 'cells' contained within (rotaries, pushes, displays etc) to plugin parameters.

Tantalisingly, the C4.rst now has entries for 'C4DisplayUpper' and 'C4DisplayLower' so C4 nirvana may not be too far away! Better get that gear set back up and get back on the CSI train Always better to have many people testing and reporting back!

[Geoff Waddington]

We need a way to describe the overall matrix that holds all the surface matrices.

By definition, this is at a page level.

This opens the door to the idea of having more than one matrix definition per page.

After thinking about this, it seems those matrices are like layers/sub pages, don't know whether that's too much complexity for not enough extra usability.

Can anyone think of a use case for more than one matrix definition per page ?

[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?

[mschnell]

Originally Posted by Geoff Waddington

Can anyone think of a use case for more than one matrix definition per page ?

If I new what "matrix" is supposed to mean here, I could think about that issue...

-Michael