Control Surface Integration (CSI) Technical Feature Discussion

[MixMonkey]

Originally Posted by Geoff Waddington

Great... sort of

That exposes a design flaw.

Suppose, instead of using the push top as a toggle you wanted to use it as a cycler, as in the pan pots switching from pan to width on the MCU and extender.

That means part of the midi Widget definition belongs in the .rst and part belongs in the .axt/.fxt so that the push top switches can behave differently on different pages.

It's always a cycler in the .rst. A cycler with 2 steps is a toggle, number of steps defined in the .axt/.fxt.

I'm guessing that's easier to say than do

Will give some thought to cell definition.

[Geoff Waddington]

Originally Posted by MixMonkey

It's always a cycler in the .rst. A cycler with 2 steps is a toggle, number of steps defined in the .axt/.fxt.

I'm guessing that's easier to say than do

Well...

Currently a Button always outputs a 1, meaning go to next cycle, Play, Stop, Record, etc.

A ToggleButton outputs a 1 or a 0, depending on what it sent previously.

What we want to do is move that different behaviour to the .axt/.fxt.

So...

What should happen...

The Button ALWAYS outputs a 1.

The .axt/.fxt then interprets the 1 as either a push or a toggle, or anything else it pleases.

That way we haven't tied the push/toggle to the button.

That decision will now be in the .fxt/.axt, allowing us to define different behaviours for the same button on different pages.

The way it is now the rotaries on the MCU/XT are defined as Buttons and the rotaries on the C4 are defined as ToggleButtons in the .rst.

That means you are stuck with that behaviour, no matter which page you are on.

[MixMonkey]

In all honesty, I can live without buttons that cycle on the C4 because there are plenty of rotaries to assign. If I only had the MCU I might feel differently.

Why do the C4 buttons have to output two different messages to toggle a 2 state parameter? I’m sure there’s a good reason in the CSI protocol, but in the standard Reaper ‘FX learn’ scenario a single message button will toggle a switch.

[MixMonkey]

Here’s an idea for matrix definition, pretty much mirrors C4.rst. Rows are letters, Columns are numbers, so an 8x8 matrix (like the C4) is defined as D8 (A1,A2.....D7,D8)

A 1x8 matrix (1 row, 8 columns) would be A8.
An 8x1 matrix (8 rows, 1 column) would be D1.
A 3x4 matrix (3 rows, 4 columns) would be C4.

A C4 widget would be: Rotary, RotaryPush, DisplayUpper, DisplayLower. I haven’t included the extra C4 buttons in the matrix.

Any good?

[Tiggerdyret]

1. I think the pipe dream would be to be able to setup the control surface to recognize and switch to a specified preset and have motorized faders reflect the all the parameter settings, whenever a plugin is clicked on... Or maybe whenever a plugin window is active. I'd love to control Omnisphere with a MCU, faderport 8 or Icon M+, have it feel like a analogue synthesizer and have the tactile response.
2. We could make a data-base of plugin presets for different controllers and share them with the community.
3. If we could have an integrated window pop up and show what faders, knobs and buttons controls what parameters for the active plugin automatically, we wouldn't have to memorize 20 different plugin setups.

[mschnell]

Originally Posted by Tiggerdyret

I'd love to control Omnisphere with a MCU, faderport 8 or Icon M+, have it feel like a analogue synthesizer and have the tactile response.

I do have this with the Behringer X-Touch Compact and plugins such as VB3.

But for Live playing I think CSI is not the ideal option. I did a set of JSFXes for this.

-Michael

[MixMonkey]

Geoff, why does a C4 rotary push behave differently to an MCU rotary push (ie pan)? They both send the same message.

[Geoff Waddington]

Originally Posted by MixMonkey

Here’s an idea for matrix definition, pretty much mirrors C4.rst. Rows are letters, Columns are numbers, so an 8x8 matrix (like the C4) is defined as D8 (A1,A2.....D7,D8)

A 1x8 matrix (1 row, 8 columns) would be A8.
An 8x1 matrix (8 rows, 1 column) would be D1.
A 3x4 matrix (3 rows, 4 columns) would be C4.

A C4 widget would be: Rotary, RotaryPush, DisplayUpper, DisplayLower. I haven’t included the extra C4 buttons in the matrix.

Any good?

Yeah, pretty much as I'm envisioning it, an .axt file something like this:

Matrix

Row

Cell
DisplayUpperA1
DisplayLowerA1
RotaryPushA1
RotaryA1
CellEnd

Cell
DisplayUpperA2
DisplayLowerA2
RotaryPushA2
RotaryA2
CellEnd

...

Cell
DisplayUpperA8
DisplayLowerA8
RotaryPushA8
RotaryA8
CellEnd

RowEnd

Row
Cell
DisplayUpperB1
DisplayLowerB1
RotaryPushB1
RotaryB1
CellEnd

Cell
DisplayUpperB2
DisplayLowerB2
RotaryPushB2
RotaryB2
CellEnd

...

Cell
DisplayUpperB8
DisplayLowerB8
RotaryPushB8
RotaryB8
CellEnd

RowEnd

MatrixEnd

[Tiggerdyret]

Originally Posted by mschnell

I do have this with the Behringer X-Touch Compact and plugins such as VB3.

But for Live playing I think CSI is not the ideal option. I did a set of JSFXes for this.

-Michael

How did you set it up? Do the faders correspond to the values in the plugin like they do with the volume faders? Can you switch between different instances of the plugin and adjust the parameters separately for more than one instance of the same synth in a project?

[Geoff Waddington]

Originally Posted by MixMonkey

Geoff, why does a C4 rotary push behave differently to an MCU rotary push (ie pan)? They both send the same message.

Because the stupid programmer doesn't know what he is doing and designed the buttons incorrectly

So yes, they do send the same message, this should be interpreted by the .axt entry to mean toggle, push, etc.

[MixMonkey]

Originally Posted by Geoff Waddington

Because the stupid programmer doesn't know what he is doing and designed the buttons incorrectly

So yes, they do send the same message, this should be interpreted by the .axt entry to mean toggle, push, etc.

Aah, I see Hope it won’t be too disruptive to code. Look on the bright side, you’ll get all that flexibility across pages you were after

[mschnell]

Originally Posted by Tiggerdyret

How did you set it up? Do the faders correspond to the values in the plugin like they do with the volume faders? Can you switch between different instances of the plugin and adjust the parameters separately for more than one instance of the same synth in a project?

In fact I use the Buttons of the Surface to select two of 64 patches (32 for each of my two keyboards) .
The patches consisting of VSTis and VSTs live in multiple tracks, so a track is unmuted and (if appropriate) it's fed with presets for the plugins and/or parameters and/or program change messages (e.g. for Kontakt).

For each patch, 17 parameters are managed that get pre-programed values on startup and are assigned to Faders and knobs, so they can be tweaked in realtime. They keep the tweaked values (per patch) when changing the patch and are restored (to the VSTs and to the surface) when changing back.

In theory, each of the 17 parameters can have a different meaning with each patch. But of course that is not very intuitive.

Of course for the B3, the nine faders are assigned to the drawbars. With the X-Touch Compact there even are the standard descriptions (16", 5 1/3", 8", ...) printed for the faders.

The system is great for Live usage, but setting up new patches and assigning sensible parameters is a lot of work.

-Michael

[Geoff Waddington]

Originally Posted by MixMonkey

Aah, I see Hope it won’t be too disruptive to code. Look on the bright side, you’ll get all that flexibility across pages you were after

Yeah, but the flexibility comes at a cost -- to you and the others that map.

We'll now need grammar like:

Play Push Play

instead of

Play Play

in an .axt or:

RotaryPushA1 Toggle Bypass

in an .fxt.

Was trying to keep things as simple as possible.

Unfortunately this is the new simple as possible...

[MixMonkey]

Originally Posted by Geoff Waddington

Yeah, but the flexibility comes at a cost -- to you and the others that map.

We'll now need grammar like:

Play Push Play

instead of

Play Play

in an .axt or:

RotaryPushA1 Toggle Bypass

in an .fxt.

Was trying to keep things as simple as possible.

Unfortunately this is the new simple as possible...

This seems fine to me- let's face it, from the mapper's end it's still pretty simple, we're just defining how the switch behaves in a particular context from within the .axt/fxt file.

If you move the switch behaviours from the .rst to the .axt/fxt files, will this mean that you don't have to create new button types (like ToggleButton for the C4) for other surfaces as yet unknown?

I can't help feeling that it might be better to maybe change the button code so that all buttons and rotary pushes are 'cycle' types and merely step through the available states in any given context.

If there is only one state (like PLAY) it is a 'Push'. If there are two states, the button becomes a 'Toggle'. If there are three or more it becomes a 'Cycle', by default, defined by the available states.

Of course, I know nothing of your code, so the above may be utter nonsense

[Geoff Waddington]

Originally Posted by MixMonkey

This seems fine to me- let's face it, from the mapper's end it's still pretty simple, we're just defining how the switch behaves in a particular context from within the .axt/fxt file.

If you move the switch behaviours from the .rst to the .axt/fxt files, will this mean that you don't have to create new button types (like ToggleButton for the C4) for other surfaces as yet unknown?

Correct.

Originally Posted by MixMonkey

I can't help feeling that it might be better to maybe change the button code so that all buttons and rotary pushes are 'cycle' types and merely step through the available states in any given context.

If there is only one state (like PLAY) it is a 'Push'. If there are two states, the button becomes a 'Toggle'. If there are three or more it becomes a 'Cycle', by default, defined by the available states.

Of course, I know nothing of your code, so the above may be utter nonsense

Oh, if only it were that easy

Some buttons only output a 1.

Some buttons output a 1 on press and a 0 on release.

Some buttons output a 1 or 0 depending on conditions.

Some buttons have "shortcut switch lighting" a huge no-no.
The DAW should be the only thing telling the lights what to do.

etc., etc.

Some have combinations of the above.

In a way this is good, it is forcing the separation of all of this from the more logical description you provided.

Maybe different types of switches, ones that can take feedback, ones that only support press, etc.

A switch could be a combination of those types.

Thanks, this has really got me thinking about this.

Geez, and I thought generic faders/rotaries/encoders was going to be the tough part

That's the great thing about pre alpha, it's wide open, just another way of saying "requirements gathering".

But, as illustrated here, having early real-world testing/feedback is so invaluable, thanks everyone !!

[Tiggerdyret]

Originally Posted by mschnell

In fact I use the Buttons of the Surface to select two of 128 patches (64 for each of my two keyboards) .
The patches consisting of VSTis and VSTs live in multiple tracks, so a track is unmuted and (if appropriate) it's fed with presets for the plugins and/or parameters and/or program change messages (e.g. for Kontakt).

For each patch, 17 parameters are managed that get pre-programed values on startup and are assigned to Faders and knobs, so they can be tweaked in realtime. They keep the tweaked values (per patch) when changing the patch and are restored (to the VSTs and to the surface) when changing back.

In theory, each of the 17 parameters can have a different meaning with each patch. But of course that is not very intuitive.

Of course for the B3, the nine faders are assigned to the drawbars. With the X-Touch Compact there even are the standard descriptions (16", 5 1/3", 8", ...) printed for the faders.

The system is great for Live usage, but setting up new patches and assigning sensible parameters is a lot of work.

-Michael

Thanks for clarifying. Do you have a link to any resources describing how to set this up?

[Geoff Waddington]

Here's a very preliminary draft of the new concept, separating the actual Widget behaviour from the logical behaviour.

I'm sure there are a ton more Widgets to think of(Joystick, Strip, etc.) but here's the very early thinking on this for Widget types.

Comments/suggestions (especially on how to make the list shorter) more than welcomed:

FB = supports feedback

Press
outputs message on Press only
1 midi message
no feedback necessary/doesn't need Update from host

PressFB
outputs message on Press only — 1 or 0 depending on the current state
2 midi messages
feedback necessary/needs Update from host

PressRelease
outputs message on Press and on Release
2 midi messages
no feedback necessary/doesn't need Update from host

PressReleaseFB
outputs message on Press and on Release
2 midi messages
feedback necessary/needs Update from host

Fader14Bit
outputs a 2 byte 14 bit value
typically normalized, then sent to host
no feedback necessary/doesn't need Update from host

Fader14BitFB
outputs a 2 byte 14 bit value
typically normalized, then sent to host
feedback necessary/needs Update from host

Fader7Bit
outputs a 1 byte 7 bit value
typically normalized, then sent to host
no feedback necessary/doesn't need Update from host

Fader7BitFB
outputs a 1 byte 7 bit value
typically normalized, then sent to host
feedback necessary/needs Update from host

Encoder
outputs a 1 byte less/more value
sent raw to host
no feedback necessary/doesn't need Update from host

EncoderFB
outputs a 1 byte less/more value
typically normalized, then sent to host
feedback necessary/needs Update from host

SysExFB - e.g. displayUpper
uses SysEx
feedback necessary/needs Update from host

MidiFB - e.g. generic meter
1 midi message
feedback necessary/needs Update from host

MCUVUMeterFB
1 midi message
very specialized
feedback necessary/needs Update from host

MCUTimeDisplayFB
multiple midi messages
very specialized
feedback necessary/needs Update from host

[mschnell]

Originally Posted by Tiggerdyret

Thanks for clarifying. Do you have a link to any resources describing how to set this up?

Here is some preliminary documentation: -> http://schnellphoto.de/X%20Touch%20Patch.pdf

-Michael

[MixMonkey]

Originally Posted by Geoff Waddington

Oh, if only it were that easy

I had a feeling that might be the case, sorry

Your matrix layout looks fine to me, nothing to add there.

Once the matrix is defined, do we map to it in the normal way in the .fxt?

Will we be able to create multiple 'layers' of the matrix that can be navigated to access more parameters than will fit on the top (first) 'layer'? Presumably this would be defined in the .fxt, in much the same way as WaddC4 lays out the number of C4 rows in the C4FXParams.ini file- although I always set the number of rows to multiples of 4 for every fx, it's easier to navigate up and down the plug in slots that way.

[MixMonkey]

Originally Posted by Geoff Waddington

Here's a very preliminary draft of the new concept, separating the actual Widget behaviour from the logical behaviour.

I'm sure there are a ton more Widgets to think of(Joystick, Strip, etc.) but here's the very early thinking on this for Widget types.

I can't immediately think of any non 'esoteric' controls that aren't covered by this list. To be clear, 'feedback' is what makes the button or encoder ring light up, right?

As far as making the list shorter, the only way I can see to do that would be to make all buttons recognised as 'press', interpret all press messages as a '1', ignore all release messages and have two classes, FB and non FB. Thus you would have a 'universal' interpretation of any button (any button that sends a MIDI message that is) I suspect this much harder than it sounds and kind of what was mentioned before.

The difficult part of this is undoubtably the 'special class' widgets- like displays. I think (for your sanity, if nothing else) you might be better off only supporting displays that are MCU emulation capable. It doesn't seem easy for an end user to extract display info in the same way as they can button, fader or encoder messages, because nothing is sent from the surface, only received.

Originally Posted by Geoff Waddington

PressFB
outputs message on Press only — 1 or 0 depending on the current state
2 midi messages
feedback necessary/needs Update from host

Out of curiosity, which surface has these buttons?

[Geoff Waddington]

Originally Posted by MixMonkey

I had a feeling that might be the case, sorry

Your matrix layout looks fine to me, nothing to add there.

Once the matrix is defined, do we map to it in the normal way in the .fxt?

That WAS an .axt/.fxt file, just left out the Actions for simplicity.

There is no need to define a matrix in the .rst.

We do that with channels just to make the files more compact, a few pages back we showed a way to use the channel concept to ease the C4 definition burden.

This concept is AFTER the .rst definition.

Originally Posted by MixMonkey

Will we be able to create multiple 'layers' of the matrix that can be navigated to access more parameters than will fit on the top (first) 'layer'? Presumably this would be defined in the .fxt, in much the same way as WaddC4 lays out the number of C4 rows in the C4FXParams.ini file- although I always set the number of rows to multiples of 4 for every fx, it's easier to navigate up and down the plug in slots that way.

Yes, should have included a keyword "Layer" to separate sections.

[Geoff Waddington]

Originally Posted by MixMonkey

I can't immediately think of any non 'esoteric' controls that aren't covered by this list. To be clear, 'feedback' is what makes the button or encoder ring light up, right?

Yes, or the scribble strip display track names, etc.

Originally Posted by MixMonkey

As far as making the list shorter, the only way I can see to do that would be to make all buttons recognised as 'press', interpret all press messages as a '1', ignore all release messages and have two classes, FB and non FB. Thus you would have a 'universal' interpretation of any button (any button that sends a MIDI message that is) I suspect this much harder than it sounds and kind of what was mentioned before.

Yeah, sometimes you need release messages, Shift key comes to mind as a good example, you only want the "Shifted" behaviour until you release the Shift key.

Originally Posted by MixMonkey

The difficult part of this is undoubtably the 'special class' widgets- like displays. I think (for your sanity, if nothing else) you might be better off only supporting displays that are MCU emulation capable. It doesn't seem easy for an end user to extract display info in the same way as they can button, fader or encoder messages, because nothing is sent from the surface, only received.

Yeah, those are the trickiest and, unfortunately seem to be the ones with the most variation.

Originally Posted by MixMonkey

Out of curiosity, which surface has these buttons?

Console 1.

If you have no software running, pressing a button causes the accompanying light to illuminate, pressing again causes it to go out.

If you have software (with or without feedback) the Console1 buttons still only output a Press.

The value of the Press depends on the value of the light, if you set the light through software feedback, you are setting the state the next press will be based on -- it will send the opposite of the light state.

[MixMonkey]

Originally Posted by Geoff Waddington

Yeah, sometimes you need release messages, Shift key comes to mind as a good example, you only want the "Shifted" behaviour until you release the Shift key.

Aah, of course, I hadn't thought of that.

Originally Posted by Geoff Waddington

Yeah, those are the trickiest and, unfortunately seem to be the ones with the most variation.

If they adhere to the MCU protocol, is it straightforward? Is the C4 difficult? (he asked, utterly selfishly)

It would be great, in the probably distant future, to have the matrix represented on screen in a manner similar to NoFish's BCF2000 display, thus giving all controllers without displays (which greatly outnumber those with) the ability to show controlled parameters across many layers of a matrix. Yeah, I know, dream on

Originally Posted by Geoff Waddington

The value of the Press depends on the value of the light, if you set the light through software feedback, you are setting the state the next press will be based on -- it will send the opposite of the light state.

That is unbelievably tricky, what on earth possessed them to do it like that?

[Geoff Waddington]

Originally Posted by MixMonkey

If they adhere to the MCU protocol, is the C4 difficult? (he asked, utterly selfishly)

Nope, was working on the logic today.

Originally Posted by MixMonkey

It would be great, in the probably distant future, to have the matrix represented on screen in a manner similar to NoFish's BCR2000 display, thus giving all controllers without displays (which greatly outnumber those with) the ability to show controlled parameters across many layers of a matrix. Yeah, I know, dream on

Well...

That's where OSC integration is going to come in handy.

In addition to screen solutions like the BCR2000 display, we can utilize phones/pads for display purposes.

One neat trick -- we can leverage the fact that most of these devices have a pinch/zoom feature that could allow fairly accurate line-up with the physical surface.

Just lay out your iPad above the physical surface, and use the zoom to get everything happy scale/size wise

[MixMonkey]

Originally Posted by Geoff Waddington

Nope, was working on the logic today.

WooHoo Can't wait!! The rest of the setup seems to be working well and is so much more responsive when banking than the old WaddC4. Add C4 displays and matrices and I can pretty much use it for work- then the fun really starts

Originally Posted by Geoff Waddington

That's where OSC integration is going to come in handy.

That's awesome, I don't really know anything about OSC, except it already exists as a protocol. If it can be used to provide displays for controllers that lack them, CSI is going to be very, very popular

Originally Posted by Geoff Waddington

Just lay out your iPad above the physical surface, and use the zoom to get everything happy scale/size wise

So everyone will be able to build their own Reaper Dock (sorry Avid)

If the OSC display pans out, secondhand BCR2000s are going up in value!

[Geoff Waddington]

FYI update:

The new style Widgets are coming along nicely.

One added benefit is that the non-feedback versions are now optimized so that no update calculations are performed, as they are completely unnecessary since there is no feedback.

This helps performance since no useless work is done.

[MixMonkey]

Great! More flexibility and an efficiency boost- win-win

[Tiggerdyret]

Hi,
How can I get my hands on the alpha control? I am receiving a Novation Nocturn this week and I would love to test what is possible to do with it in Reaper, since the hardware looks amazing, but the software is pretty none functional for Reaper. What I specifically want to do is setup the buttons on the unit itself to change to a specific midi channel for different layouts to control more parameters than the 9 knobs allow.

[ivansc]

Originally Posted by Geoff Waddington

One neat trick -- we can leverage the fact that most of these devices have a pinch/zoom feature that could allow fairly accurate line-up with the physical surface.

Just lay out your iPad above the physical surface, and use the zoom to get everything happy scale/size wise

Great stuff as usual, Geoff. This has been one of my pet moans about most all of the other control surface interfacing software.

[Snooprah]

Hello, guys!

Can i use this plugin for BCR2000?
I can't understand how to use it, how i can map the parameters and midi from/to BCR. Guide in archive says nothing about it.

I know that the plugin is in pre-alpha state.

So, i'm just asking for opinions here.
Thanks.

[blumpy]

I have an X-Touch running Klinke's MCU but there's one feature I can't seem to find.

Is there a way to have the mixer jump to the selected track?

Currently, if I have a session with 100 tracks, if I select track 99 in the arrange window or mixer the x-touch needs to be manually moved via fader bank buttons to track 99 to be able to have controller access to that channel.

Thanks!

[nofish]

Originally Posted by blumpy

I have an X-Touch running Klinke's MCU but there's one feature I can't seem to find.

Is there a way to have the mixer jump to the selected track?

Currently, if I have a session with 100 tracks, if I select track 99 in the arrange window or mixer the x-touch needs to be manually moved via fader bank buttons to track 99 to be able to have controller access to that channel.

Thanks!

This question would have been better fitted in one of the Klinke MCU threads than here imo, anyway you need to enable "Follow Reaper":
https://forum.cockos.com/showthread.php?t=81818&page=21

[Tiggerdyret]

Originally Posted by mschnell

Here is some preliminary documentation: -> http://schnellphoto.de/X%20Touch%20Patch.pdf

-Michael

Thanks, I'll take a look

[mschnell]

Just came across this. Is this relevant here, too ? -> https://forum.cockos.com/showthread.php?t=208375

-Michael

[Geoff Waddington]

Originally Posted by mschnell

Just came across this. Is this relevant here, too ? -> https://forum.cockos.com/showthread.php?t=208375

-Michael

Thanks, bookmarked and placed on the to-do list.

[UNdark]

Hi Geoff, thanks for the work on the mcu - I am not able to use it to the full, as my button outputs from the mcu are on channel 1, consequently effecting other info on midi channel 1... is there a way of sending midi from the mcu on another channel? I have found the auto map on the sl25 not logical in it's arrangement of display and have programmed all my plugs now to be used by it and can keep each template on a different midi channel to keep it out of the way of other midi info. I did try your setup and liked it a lot, though my faders keep re setting when i press stop, so when i play again and move a fader, it picks up at a different level - if i bank left or right first, this is rectified. What i did like, was setting the buss and audio buttons to home in on parts of my display window - but.. only from channel 1 which effects my midi record channel, when i'm working on a midi channel. Maybe i'm utilising this the wrong way? I'd like to allocate the mcu to midi channel 11 or 12. Is this at all possible?
Many thanks for the work in helping os x users get nearer the windows users advantages of this great program, thank Yo Wadd!!

Mike

[Geoff Waddington]

Originally Posted by UNdark

Hi Geoff, thanks for the work on the mcu - I am not able to use it to the full, as my button outputs from the mcu are on channel 1, consequently effecting other info on midi channel 1... is there a way of sending midi from the mcu on another channel? I have found the auto map on the sl25 not logical in it's arrangement of display and have programmed all my plugs now to be used by it and can keep each template on a different midi channel to keep it out of the way of other midi info. I did try your setup and liked it a lot, though my faders keep re setting when i press stop, so when i play again and move a fader, it picks up at a different level - if i bank left or right first, this is rectified. What i did like, was setting the buss and audio buttons to home in on parts of my display window - but.. only from channel 1 which effects my midi record channel, when i'm working on a midi channel. Maybe i'm utilising this the wrong way? I'd like to allocate the mcu to midi channel 11 or 12. Is this at all possible?
Many thanks for the work in helping os x users get nearer the windows users advantages of this great program, thank Yo Wadd!!

Mike

First of all, no matter which software you use (stock, Klinke, my old MCUC4, or CSI), make sure to go to Reaper preferences->Audio->MIDI devices and DISABLE your control surfaces. They will still work fine as control surfaces but won't bleed into your regular midi parts.

[Geoff Waddington]

Here's an excerpt from the "new look" .rst:

Shift 90 46
Option 90 47
Control 90 48
Alt 90 49

Rewind 90 5b
FastForward 90 5c
Stop 90 5d
Play 90 5e
Record 90 5f

Channel
VUMeter MCUVUMeter
DisplayUpper MCUDisplayUpper
DisplayLower MCUDisplayLower
FaderTouch 90 68
RotaryPush 90 20
Rotary b0 10
Fader e0 -72.0 12.0
RecordArm 90 00
Solo 90 08
Mute 90 10
Select 90 18
ChannelEnd

No magic didn't happen

Things are just shifted around.

The notion of Fader, button, encoder, etc., will now be in the .axt file, so that we can have the same control behave differently on different pages.

Comments/suggestions welcomed as always...

[MixMonkey]

Looking good

So no longer any need for 00 7F at the end of every message or the prefix 'Channel' for messages between 'Channel' and 'ChannelEnd'?

How's the .axt coming along?

[Geoff Waddington]

Originally Posted by MixMonkey

Looking good

So no longer any need for 00 7F at the end of every message or the prefix 'Channel' for messages between 'Channel' and 'ChannelEnd'?

How's the .axt coming along?

Coming along well -- the new design to handle the widget type in the .axt is more or less defined, but the software still has to be written.