Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by Navelpluisje

Did check them, but they all use properties.

OK, let's take a use case driven approach.

Can you please describe a use case, or set of use cases for a given display ?

Then we can start the discussion of how to best implement them. using Widgets and Zones.

[Navelpluisje]

Originally Posted by Geoff Waddington

OK, let's take a use case driven approach.

Can you please describe a use case, or set of use cases for a given display ?

Then we can start the discussion of how to best implement them. using Widgets and Zones.

Was able to reduce the issue a bit. Just checked all the places where I use the ScribbleLine with a modifier and in none of those cases I do change the alignment of the text or set the invert flag. So that one is pretty well covered.

The only little thing I run into is the Valuebar. This is as the VU meter a separate Widget. Use case here is:

• In default Track mode I show the pan value in the ValueBar as the FaderPort does not have the amount of encoders as we all had hoped for
• Holding shift makes the Faders the pan 'buttons' (I know ) and make the Valuebar display the Volume.

But while typing and reconsidering things again (What's the effort and what do we gain) I can stick with one value for the display type per widget.

Thanx for letting me really think about this. Also gave me a better idea about how Actions, actioncontext and widgets are related to eachother.

Although I think it is pretty hard to implement well, I hope we can stil keep the door ajar for this option.

[JP_]

Originally Posted by Geoff Waddington

CSI values are represented internally using the range 0.0 - 1.0.


20Hz = 0.0
20,000Hz = 1.0

-30db = 0.0
+30db = 1.0

and so on.

The 0 - 127 is converted to the same range 0.0 - 1.0.

No need to do anything on your end, it is all handled internally.

Wow, that’s easy then hahaha! Nice one Geoff!

*edit*

Ok, I’ve swapped instances of “encoder” to “fader7bit” and we are in business! It does mean rewriting all of the plugins though as functionality suits the vertical rotaries a lot better on certain stuff.

Hm, now it’s a case of “do I prefer more precision” or “do I want two layers of a desk but lose precision”. More isn’t always better… Thanks for all the help monkey, that’s phenomenal work, and blind too!

The way it skips turns due to the 127 steps is infuriating hahaha it makes the device feel what it is (cheap), whereas when the encoders are in play the precision in proq3 is awesome, it feels like a more premium device etc.

I think it’s worth coding out a standard one if it’s this close, I might try moving away from proq3 and using channel strip eqs only like back in the day on real desks!

[lubvic]

Hi all,
i'm updating to new version 2.0 because of color scribble support for xtouch, very great work, it really improve my workflow, based on colored tracks!!!
I'd like to know, is there a way to arbitrary set displays to a wanted color, for example, when changing to SEND zone, FX zones or else...?
Thanks!

[Geoff Waddington]

Originally Posted by lubvic

Hi all,
i'm updating to new version 2.0 because of color scribble support for xtouch, very great work, it really improve my workflow, based on colored tracks!!!
I'd like to know, is there a way to arbitrary set displays to a wanted color, for example, when changing to SEND zone, FX zones or else...?
Thanks!

Not at the moment, but it's on the future upgrades list.

I have an X-Touch myself, and think it would be great to be able to set a single color for each of Sends/Receives/FXMenu, it would provide great visual feedback as to which mode you are in.

[Geoff Waddington]

Originally Posted by JP_

Wow, that’s easy then hahaha! Nice one Geoff!

*edit*

Ok, I’ve swapped instances of “encoder” to “fader7bit” and we are in business! It does mean rewriting all of the plugins though as functionality suits the vertical rotaries a lot better on certain stuff.

Hm, now it’s a case of “do I prefer more precision” or “do I want two layers of a desk but lose precision”. More isn’t always better… Thanks for all the help monkey, that’s phenomenal work, and blind too!

The way it skips turns due to the 127 steps is infuriating hahaha it makes the device feel what it is (cheap), whereas when the encoders are in play the precision in proq3 is awesome, it feels like a more premium device etc.

I think it’s worth coding out a standard one if it’s this close, I might try moving away from proq3 and using channel strip eqs only like back in the day on real desks!

Great stuff !

And now you have a very real understanding of the difference between encoders and 7 bit faders, and why we love encoders so much around these parts

[JP_]

Originally Posted by Geoff Waddington

Great stuff !

And now you have a very real understanding of the difference between encoders and 7 bit faders, and why we love encoders so much around these parts

Yeah! Thanks Geoff! I've done some testing and I'm not prepared to sacrifice precision for more buttons. On my MCU presets for bx 4000E+G I have it mapped so that one turn of my encoder is the same as one tick on the software knob. It feels very 1:1 in that way.

The 7BitFader setup makes it so I have to turn 2-4 clicks every 1 software tick, so it's really "off" in comparison.

I really appreciate the help from everyone though I will be sticking to the MCU mode.

Out of interest, is there anything out there like the x-touch but with higher quality bits/all encoders etc?

Or even a controller that looks like a similar setup to an SSL with the knobs in the same place etc?

*edit*
Found this:
https://www.gak.co.uk/en/ssl-uc-1-ch...E&gclsrc=aw.ds

https://rocksolidaudio.co.uk/

[MixMonkey]

Originally Posted by JP_

Yeah! Thanks Geoff! I've done some testing and I'm not prepared to sacrifice precision for more buttons. On my MCU presets for bx 4000E+G I have it mapped so that one turn of my encoder is the same as one tick on the software knob. It feels very 1:1 in that way.

The 7BitFader setup makes it so I have to turn 2-4 clicks every 1 software tick, so it's really "off" in comparison.

I really appreciate the help from everyone though I will be sticking to the MCU mode.

Out of interest, is there anything out there like the x-touch but with higher quality bits/all encoders etc?

Or even a controller that looks like a similar setup to an SSL with the knobs in the same place etc?

*edit*
Found this:
https://www.gak.co.uk/en/ssl-uc-1-ch...E&gclsrc=aw.ds

https://rocksolidaudio.co.uk/

Sorry, that was my bad. I really shouldn't do these things so late at night I changed all the control values but forgot to search+replace Encoder for Fader7Bit. Doh!

Anyway, it sounds like you're sticking with Encoders anyway (wise choice imo).

[MixMonkey]

Originally Posted by JP_

Out of interest, is there anything out there like the x-touch but with higher quality bits/all encoders etc?

Or even a controller that looks like a similar setup to an SSL with the knobs in the same place etc?

*edit*
Found this:
https://www.gak.co.uk/en/ssl-uc-1-ch...E&gclsrc=aw.ds

https://rocksolidaudio.co.uk/

Are you looking to solely control plugins? or do you want the faders/track mixing thing as well?

[AtmanActive]

Originally Posted by lubvic

I'd like to know, is there a way to arbitrary set displays to a wanted color, for example, when changing to SEND zone, FX zones or else...?
Thanks!

I did it like this in TouchOSC, can't guarantee that the same approach can be translated to your device:

Zone "Track"
    ButtonLED| TrackUniqueSelect { "Track" }
...
Zone "TrackSend"
    ButtonLED| FixedRGBColorDisplay { 0 55 155 }
...
Zone "TrackReceive"
    ButtonLED| FixedRGBColorDisplay { 0 155 55 }
...

[jacksoonbrowne]

Originally Posted by AtmanActive

I just discovered this, maybe it could be helpful:

https://www.kasperkamperman.com/blog...c-datamonitor/


http://hypebeast.github.io/OSCShark/

Thanks @AtmanActive,
I did a quick peek at the sites and they will be super helpful for me getting quickly up to speed on TouchOsc.


I will be digging into them tonight

Cheers,
Roy

[jacksoonbrowne]

Originally Posted by jacksoonbrowne

Thanks @AtmanActive,
I did a quick peek at the sites and they will be super helpful for me getting quickly up to speed on TouchOsc.

I will be digging into them tonight

Cheers,
Roy

I looked at the sites you suggested might help me:

https://www.kasperkamperman.com/blog...c-datamonitor/
http://hypebeast.github.io/OSCShark/

They essentially show how to capture and display network OSC messages.
I already do that with WireShark using OSC specific packet filters.
If anyone is interested in using wireshark to watch OSC messaging please PM me. Caveat being you need to have a basic understanding of wireshark first.

Here is a sample of my wireshark OSC filter capture in action:

Source       Destination   SrcPort DstPort Proto Length OSC_address  OSC_type OSC_args
192.168.1.50 192.168.10.3  8000    9000    OSC   62     /ButtonA72   ,f       1
192.168.10.3 192.168.1.50  9000    8000    OSC   62     /Fader3/z    ,f       1
192.168.10.3 192.168.1.50  9000    8000    OSC   62     /Fader3/z    ,f       0
192.168.10.3 192.168.1.50  9000    8000    OSC   62     /Fader10/z   ,f       1

Using "MM_iPad_Mixer.tosc" with an iPhone X requires a microscope to view the iPhone screen. So I ordered an iPad 12" from Amazon, will be here tomorrow .

That said, I still need to learn the TouchOSC editor better in order to make changes to the "OSC address and params" as well as delving into the "MM_iPad_Mixer" CSI support files.

[mschnell]

Originally Posted by Geoff Waddington

And now you have a very real understanding of the difference between encoders and 7 bit faders, and why we love encoders so much around these parts

I suppose In theory CSI could use (Compact - ) 7 bit "fader" rotaries as encoders:

- with every step up or down increase or decrease the virtual Value (0..1) by some predefined amount (say 1/512).
- send the virtual Value encoded as 0..127 to the device.

With that the LEDs show the correct state of the virtual Value and there is headroom for accepting another turning step by the user.

Supposedly some kind of acceleration needs to be handles but I understand CSI does this with encoders, anyway.

IMHO this would be very viable to be implemented - unless you did not already do that

BTW.: in theory for a test somebody (I) could do a Midi preprocessor doing this (as a Reaper JSFX or by means of OSCIIBot) converting a "7 bit Fader" in a ??-Bit thingy. But on the long run this of course is not viable solution.

Thanks for listening,
-Michael

[mschnell]

Originally Posted by mschnell

BTW.: in theory for a test somebody (I) could do a Midi preprocessor doing this (as a Reaper JSFX or by means of OSCIIBot) converting a "7 bit Fader" in a ??-Bit thingy. But on the long run this of course is not viable solution

Question:

- Does CSI provide a way of using EEL to do Midi processing of incoming (and outgoing) messages ?

- does CSI provide a backdoor that allows for a JSFX to do such processing ? JSFX Midi messages are generated on a track but easily can be roted to the Reaper Control Path by the famous "MidiToReaControlPath" Vst. Supposedly CSI does not just pick it's Midi input from the Control Path, but maybe there is a way to route messages onto the CSI input stream (and intercept the output stream).

- does CSI in a "standard Midi" configuration accept certain Messages types to provide more that 7 bits (HighRes CC, Pitchbend, Note on with Note and velocity, SysEx, MCU "Fader" Messages, Midi v2, ...) ?

-Michael

[AtmanActive]

Originally Posted by jacksoonbrowne

Using "MM_iPad_Mixer.tosc" with an iPhone X requires a microscope to view the iPhone screen. So I ordered an iPad 12" from Amazon, will be here tomorrow .

I would also recommend buying a license for TouchOSC desktop version, either windows or mac or linux, whatever is your flavor. I believe you can get a discount on desktop license once you have a mobile version (check about screen in TouchOSC mobile). Editing on desktop is way more comfortable, plus TouchOSC has a genious live-shared-network-editing mode, found on it's WiFi icon, which enables you to edit on desktop but see changes on a mobile device in real-time. If only C++ development was like this...

[JP_]

Originally Posted by MixMonkey

Are you looking to solely control plugins? or do you want the faders/track mixing thing as well?

I think you did an amazing job mate! It’s allowed me to make a choice between the two and feel confident as to why, that really means a lot!

As for the mixer I think that rock ssl (2nd link) is pretty much bang on, it means I can use the xtouch For mixing 8 tracks at a time and controlling the vast majority of my plugins, but then get that analog feel by using the ssl style board to learn etc.

[Geoff Waddington]

Originally Posted by mschnell

I suppose In theory CSI could use (Compact - ) 7 bit "fader" rotaries as encoders:

- with every step up or down increase or decrease the virtual Value (0..1) by some predefined amount (say 1/512).
- send the virtual Value encoded as 0..127 to the device.

With that the LEDs show the correct state of the virtual Value and there is headroom for accepting another turning step by the user.

Supposedly some kind of acceleration needs to be handles but I understand CSI does this with encoders, anyway.

IMHO this would be very viable to be implemented - unless you did not already do that

BTW.: in theory for a test somebody (I) could do a Midi preprocessor doing this (as a Reaper JSFX or by means of OSCIIBot) converting a "7 bit Fader" in a ??-Bit thingy. But on the long run this of course is not viable solution.

Thanks for listening,
-Michael

Maybe, but there are many potential problems.

For instance, on a Console One, setting the LED ring values also sets the rotary value, this would totally mess up the encoder concept.

Given this and other considerations, not likely something we will look at in the near future.

[Geoff Waddington]

Originally Posted by mschnell

Question:

- Does CSI provide a way of using EEL to do Midi processing of incoming (and outgoing) messages ?

- does CSI provide a backdoor that allows for a JSFX to do such processing ? JSFX Midi messages are generated on a track but easily can be roted to the Reaper Control Path by the famous "MidiToReaControlPath" Vst. Supposedly CSI does not just pick it's Midi input from the Control Path, but maybe there is a way to route messages onto the CSI input stream (and intercept the output stream).

- does CSI in a "standard Midi" configuration accept certain Messages types to provide more that 7 bits (HighRes CC, Pitchbend, Note on with Note and velocity, SysEx, MCU "Fader" Messages, Midi v2, ...) ?

-Michael

Seems like you are talking about the normal midi stream, yes ?

If so, don't forget you must disable midi for control surfaces.

If not, CSI accepts anything except SysEx as input, for example, e0 (pitch bend) is the standard way 14 bit Faders operate.

[Puck]

Originally Posted by jacksoonbrowne

That said, I still need to learn the TouchOSC editor better in order to make changes to the "OSC address and params" as well as delving into the "MM_iPad_Mixer" CSI support files.

I’m sure it will make sense to you pretty quickly as a programmer.

AtmanActive had a great suggestion of using the desktop editor. It’s similar to Reaper in terms of licensing. It’s fully functional with a nag screen. I’m sure you will support them if you can but I’m just pointing out that they don’t take away features or functionality.

To make adjustments to any of the messaging:

1. Select a control and that control’s info will populate in the panel on the right. Messaging is near the bottom of that panel above scripting.

2. Add an OSC address with the “+” button if there isn’t one there. You can have as many addresses as you like.

3. I believe the address defaults to a mixture of partials and constants. The latter just being “/“ to follow the OSC address spec and the former defaults to (self.parent.name) and (parent.name)
- for constants you can click on them and then type in the field below
- for partials, there is a huge list of partials that you could use for the address
- for both constants and partials you can click on them and delete them or you can add as many of either as you want with the “+” button

- parent.name is the name of the group the control is in. Select a few controls, right click and group them, and now the name of that group will be in any of that groups children OSC messaging so long as they have the parent.name partial in the address. You can see the project structure pretty clearly in the document tree (also in the right panel)

[mschnell]

Originally Posted by Geoff Waddington

For instance, on a Console One, setting the LED ring values also sets the rotary value, this would totally mess up the encoder concept.

I don't understand. What is the "rotary value" vs LED display ? I understand the rotary in the (Compact-) device just stores a single value 0..127 and displays same in the LED ring. When turning a step, this value is increased or decreased, shown on the LEDs (which might result in not changing the display), and sent out via the appropriate Midi CC message.

But this is just what I suppose will enable using is like an encoder (see above).
I could easily do a test by a JSFX, outputting e.g. pitchbend messages. But I suppose I cant include this in the CSI workflow in any decent way.

-Michael

[mschnell]

Originally Posted by Geoff Waddington

Seems like you are talking about the normal midi stream, yes ?
If so, don't forget you must disable midi for control surfaces.
If not, CSI accepts anything except SysEx as input, for example, e0 (pitch bend) is the standard way 14 bit Faders operate.

Yep.

I would use normal Midi with the Compact and route it via OSCIIBot to CSI. Or route it into Reaper -> via a JSFX -> out of Reaper and -> back into Reaper for CSI via LoopMidi.

That should be able to work, but of course only for a test, as external Tools can't be proposed to end users.

(I seem to remember that eel processing in CSI once had been planned, but this seems to have been dropped.)

(Just a thought: In fact IMHO even more versatile would be a Midi device (or a pair of those) that CSI might (optionally) install in Reaper that intercepts the input and output midi streams. Or even simpler just optionally provide a single Midi device that is used for input and output instead of the dedicated Control Surface I/O).

-Michael

[Geoff Waddington]

Originally Posted by mschnell

I suppose In theory CSI could use (Compact - ) 7 bit "fader" rotaries as encoders:

- with every step up or down increase or decrease the virtual Value (0..1) by some predefined amount (say 1/512).
- send the virtual Value encoded as 0..127 to the device.

With that the LEDs show the correct state of the virtual Value and there is headroom for accepting another turning step by the user.

Almost, the virtual value is a floating point number the varies from 0.0 - 1.0.

That is mapped to the 0 - 127 range of the 7 bit fader.

So CSI already does this in feedback processors, if that is what you are asking.

If you are saying use a previous value of the encoder to determine the direction, this will fail.

When you set the value for the LED rings the device will also set the 7 bit fader internal value (0-127).

The next time you turn the fader it will not send what you think, it will send a value based on what CSI just set the LEDS to in its feedback operation, because the LED rings and the fader are coupled.

When you test the new fader value against the previous value you have stored as an encoder value you will not be testing the delta value, which you need for an encoder strategy, you will be testing your previously stored value against the new 0-127 absolute value from the encoder (which was set by CSI sending feedback to the LED rings), which gets you right back to a 7 bit fader.

If you are lucky and the LED rings and the 7 bit fader values are not coupled like they are in the Console One, this strategy might work, but it's a long shot, a lot of manufacturers couple them, unfortunately.

[Geoff Waddington]

Originally Posted by mschnell

Yep.

I would use normal Midi with the Compact and route it via OSCIIBot to CSI. Or route it into Reaper -> via a JSFX -> out of Reaper and -> back into Reaper for CSI via LoopMidi.

That should be able to work, but of course only for a test, as external Tools can't be proposed to end users.

(I seem to remember that eel processing in CSI once had been planned, but this seems to have been dropped.)

(Just a thought: In fact IMHO even more versatile would be a Midi device (or a pair of those) that CSI might (optionally) install in Reaper that intercepts the input and output midi streams. Or even simpler just optionally provide a single Midi device that is used for input and output instead of the dedicated Control Surface I/O).

-Michael

I have no idea what you are trying to accomplish here.

Please give an example of a use case.

[mschnell]

Originally Posted by Geoff Waddington

The next time you turn the fader it will not send what you think, it will send a value based on what CSI just set the LEDS to in its feedback operation, because the LED rings and the fader are coupled.

That is exactly what I hope for.

I definitely need to to a test as described above:

I'll do a JSFX that gets the input from the rotary (i.e. CC message value 0..127)

- it has a saved virtual value initially set to 0.5
- the first time it gets a CC, it saves this value internally
- if it gets a new value it compares it to the saved one. If greater: increasing, If smaller: decreasing.
- if increasing (decreasing obviously appropriate):
- increase the stored virtual value by a predefined amount (up to max 1.0)
- send out appropriate pitchbend value (*16384 and round appropriately) via CSI
- calculate the corresponding CC value (*128 and round appropriately) and save it
- send this value to the device (which displays the corresponding LED ring and uses this value for the next step the user might do).

Now CSI can work with a 14 Bit value.

This even could work with a 7 Bit Motor fader but supposedly would feel rather funny.

-Michael

[Geoff Waddington]

Originally Posted by mschnell

That is exactly what I hope for.

I definitely need to to a test as described above.

-Michael

Well, that's just existing 7 bit fader behaviour.

Once again, I am struggling to understand what you are trying to accomplish that cannot already be done, please give a concrete example.

[JP_]

Hey Geoff, just woken up here. Thank you so much for all your help yesterday, Monkey and Funky as well! I never thought of calling you all a helpful trio called Giant Geoff and the Funky Monkeys but here it is hahaha

I can't believe that I haven't noticed this issue before, but I was just mastering a track and found that the X-Touch won't link to any plugins at all, it stays on the tracks in the background (Volume, Pan, etc).

It doesn't do this on regular tracks though! Any idea how I can fix this?

Thanks mate!

[mschnell]

Originally Posted by Geoff Waddington

Well, that's just existing 7 bit fader behaviour.

OOOPs that would be great !
But I supposed that using the CSI "7 bit fader" results in a resolution of only 7 bit (128 steps) in the 0.0 .. 1.0 value.
I did not suppose that CSI actively modifies (not repeats) the remote value of a rotary with any step.

I seem to understand that JP thinks the same.

Moreover I don't suppose that this will work decently with 7 bit motor faders.

Originally Posted by Geoff Waddington

Once again, I am struggling to understand what you are trying to accomplish that cannot already be done, please give a concrete example.

The example is simply using a device with a "standard 7 bit CC" rotary (with LED ring) and allowing for greater resolution by simulating that the rotary is an encoder.

-Michael

[MixMonkey]

Originally Posted by jacksoonbrowne

I looked at the sites you suggested might help me:

https://www.kasperkamperman.com/blog...c-datamonitor/
http://hypebeast.github.io/OSCShark/

They essentially show how to capture and display network OSC messages.
I already do that with WireShark using OSC specific packet filters.
If anyone is interested in using wireshark to watch OSC messaging please PM me. Caveat being you need to have a basic understanding of wireshark first.

TouchOSC comes with an application called Protokol that monitors and displays OSC messages.

[Puck]

Originally Posted by MixMonkey

TouchOSC comes with an application called Protokol that monitors and displays OSC messages.

It’s true.

There is actually a separate application called Protokol but there is also a version baked into TouchOSC. Ctrl+Shift+L to open the log.

You can monitor any message (midi, OSC, local) and this is also where any scripting errors or debug printing will show up.

[Geoff Waddington]

Originally Posted by JP_

Hey Geoff, just woken up here. Thank you so much for all your help yesterday, Monkey and Funky as well! I never thought of calling you all a helpful trio called Giant Geoff and the Funky Monkeys but here it is hahaha

I can't believe that I haven't noticed this issue before, but I was just mastering a track and found that the X-Touch won't link to any plugins at all, it stays on the tracks in the background (Volume, Pan, etc).

It doesn't do this on regular tracks though! Any idea how I can fix this?

Thanks mate!

I don't understand what you mean by "mastering a Track" and "stays on the Tracks in the background", please elaborate.

[Geoff Waddington]

Originally Posted by mschnell

That is exactly what I hope for.

I definitely need to to a test as described above:

I'll do a JSFX that gets the input from the rotary (i.e. CC message value 0..127)

- it has a saved virtual value initially set to 0.5
- the first time it gets a CC, it saves this value internally
- if it gets a new value it compares it to the saved one. If greater: increasing, If smaller: decreasing.
- if increasing (decreasing obviously appropriate):
- increase the stored virtual value by a predefined amount (up to max 1.0)
- send out appropriate pitchbend value (*16384 and round appropriately) via CSI
- calculate the corresponding CC value (*128 and round appropriately) and save it
- send this value to the device (which displays the corresponding LED ring and uses this value for the next step the user might do).

Now CSI can work with a 14 Bit value.

This even could work with a 7 Bit Motor fader but supposedly would feel rather funny.

-Michael

First of all, it's not a cc message, Midi control surfaces hijack the midi protocol, please alway show examples in hex code.

I just realized this might work, because the rotaries don't have end stops on these units.

What messages do they send when you have reached 127 and go past there ?

If they continue to send 127, it just might work.

If they stop sending after 127, you are out of luck.

[Funkybot]

My guess is "Master Track FX" are not mapping. Which I think we know about.

The workaround would be to remove the FX from the master and create a pre-master fader bus. Or bounce down and do the mastering in a new project on a standard track.

[MixMonkey]

Originally Posted by Funkybot

My guess is "Master Track FX" are not mapping. Which I think we know about.

That would be my guess too.

The workaround would be to remove the FX from the master and create a pre-master fader bus.

This is better from a CPU load perspective too.

[JP_]

Originally Posted by Geoff Waddington

I don't understand what you mean by "mastering a Track" and "stays on the Tracks in the background", please elaborate.

I have a song that I'm mastering, when I try to use the XTouch to control plugins on Reaper's Master Track, it doesn't work and the XTouch behaves like nothing is on screen (it continues to control track volumes and panning etc).

Funky wrote that this is a known issue and I should make a 2-bus as a work around.

[MixMonkey]

Originally Posted by Geoff Waddington

First of all, it's not a cc message, Midi control surfaces hijack the midi protocol, please alway show examples in hex code.

I just realized this might work, because the rotaries don't have end stops on these units.

What messages do they send when you have reached 127 and go past there ?

If they continue to send 127, it just might work.

If they stop sending after 127, you are out of luck.

If the Compact works the same as the Mini, it will carry on sending out $00 at fully anticlockwise for every tick and $7F at fully clockwise.

[JP_]

Originally Posted by MixMonkey

That would be my guess too.


This is better from a CPU load perspective too.

I've heard it's better to make a 2-bus as well, but in testing, I've noticed little difference.

[MixMonkey]

Originally Posted by JP_

I've heard it's better to make a 2-bus as well, but in testing, I've noticed little difference.

It really depends what you load your master bus up with. My understanding was that the master bus runs in a single thread, but never underestimate Justin and Schwa's ability to change thing up

[AtmanActive]

Originally Posted by MixMonkey

It really depends what you load your master bus up with. My understanding was that the master bus runs in a single thread, but never underestimate Justin and Schwa's ability to change thing up

Confirmed, single thread.

In case someone has a long and bulky FX chain and puts it on the Master track, then, Reaper's RT (RealTime) CPU will go up while total windows CPU will look like it is idling. If you put that same FX chain on a folder track that holds all other tracks under it (your own Master), then, Reaper's RT CPU will look like idle but windows CPU will go up dramatically. It all depends what audio drivers one is using.
The most performant Reaper's output is "Dummy Audio" but then one needs to use some network way of streaming audio out of Reaper and that won't pass with less than 40ms latency.

[mschnell]

Originally Posted by Geoff Waddington

First of all, it's not a cc message, Midi control surfaces hijack the midi protocol, please alway show examples in hex code.
I just realized this might work, because the rotaries don't have end stops on these units.
What messages do they send when you have reached 127 and go past there ?
If they continue to send 127, it just might work.If they stop sending after 127, you are out of luck.

The "Compact" in Standard (non MCU) mode does send and receive Midi CCs by default. But it can be programmed to do lot of tricks.


I did do the testing JSFX.

It communicates with the Compact via Midi (here a single rotary using a dedicated Midi CC # and channel).

This is done on Midi Bus 1 (to allow appropriate Routing in Reaper).

Hence you need to connect the Input of a track to hold the JSFX to the Midi device "X-TOUCH Compact" and route the output of that track to that device as well.

On Bus 2 the JSFX outputs (14 Bit) pitchbend messages with a resolution (Step) selectable by a slider.



here it is:

desc:encoder

slider1:0<0,16,1{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}>in Channel (Bus 1)
slider2:1<0,127,1{0 Bank Sel M,1 Mod Wheel M,2 Breath M,3,4 Foot P M,5 Porta M,6 Data Entry M,7 Vol M,8 Balance M,9,10 Pan M,11 Expression M,12 Ctrl 1 M,13 Ctrl 2 M,14,15,16 GP Slider 1,17 GP Slider 2,18 GP Slider 3,19 GP Slider 4,20,21,22,23,24,25,26,27,28,29,30,31,32 Bank Sel L,33 Mod Wheel L,34 Breath L,35,36 Foot P L,37 Porta L,38 Data Entry L,39 Vol L,40 Balance L,41,42 Pan L,43 Expression L,44 Ctrl 1 L,45 Ctrl 2 L,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64 Hold P sw,65 Porta sw,66 Sustenuto sw,67 Soft P sw,68 Legato P sw,69 Hold 2 P sw,70 S.Variation,71 S.Timbre,72 S.Release,73 S.Attack,74 S.Brightness,75 S.Ctrl 6,76 S.Ctrl 7,77 S.Ctrl 8,78 S.Ctrl 9,79 S.Ctrl 10,80 GP B.1 sw,81 GP B.2 sw,82 GP B.3 sw,83 GP B.4 sw,84,85,86,87,88,89,90,91 Effects Lv,92 Trem Lv,93 Chorus Lv,94 Celeste Lv,95 Phaser Lv,96 Data B. Inc,97 Data B. Dec,98 NRP L,99 NRP M,100 RP L,101 RP M,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127}>in CC
slider3:0<0,16,1{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}>out Channel (Bus 2)
slider4:0.001953125<0.000244140625, 0.0078125, 0.000244140625>Step

in_pin:none
out_pin:none

@init
  ext_midi_bus = 1;
  virtualValue = 0.5;
  ccValue = -1;
  ccLast = -1;
  outLast = -1;

@slider
inBus = 0;
outBus = 1;
inChannel = 0xB0 + slider1;
outChannel = 0xE0 + slider3;
inCC = slider2;
step = slider4;
step2 = step / 2;

@block
   midi_bus = inBus;
   while (midirecv(offset, msg1, msg2, msg3)) (
     inChannel == msg1 ? (
       msg2 == inCC ? (              // Is it the MSB CC?
         ccValue < 0 ? (
           ccValue = msg3;
          ) : ( 
           ccValue < msg3 ? (  // increase
             d = step;
            ) : ccValue > msg3 ? ( // decrease
             d = -step;
            ) : ( 
             d = 0;  // == don't do amnythging
           );
         );
         virtualValue += d; 
         virtualValue < 0 ? (
           virtualValue = 0;
          ) : ( virtualValue > 1 ? 
           virtualValue = 1;
         );  
         ccValue = virtualValue * 128;
         ccValue += 0.5;
         ccValue < 0 ? (
           ccValue = 0;
          ) : ccValue > 127 ? (
           ccValue = 127;
         );  
         ccValue |= 0;
         ccLast != ccValue ? (
           midisend(offset, msg1, msg2, ccvalue);
           ccLast = ccValue;
         );  
         outValue = virtualValue * 16384;
         outValue += 0.5;
         outValue < 0 ? (
           outValue = 0;
          ) : outValue > 16383 ? (
           outValue = 16383;
         );  
         outValue |= 0;
         outLast != outValue ? (
           midi_bus = outBus;
           msg3 = (outValue / 128) | 0;
           msg2 = outValue  - (msg3 * 128);
           midisend(offset, outChannel, msg2, msg3);
           outLast = outValue;
           midi_Bus = inBus;
         );  
       );          
     );
   );

Result:
- The virtual value and thus the Pitchbend message can be controlled with high resolution by turning the rotary
- the LED ring shows the state of the virtual value with the resolution possible by the LED ring (25 different displays when using the mode that displays a value not "Fan" or "Pan")
- The LEDs flicker slightly funny when turning the rotary
- it does not work with a Motor Fader.

-Michael

[JP_]

Originally Posted by mschnell

The "Compact" in Standard (non MCU) mode does send and receive Midi CCs by default. But it can be programmed to do lot of tricks.


I did do the testing JSFX.

It communicates with the Compact via Midi (here a single rotary using a dedicated Midi CC # and channel).

This is done on Midi Bus 1 (to allow appropriate Routing in Reaper).

Hence you need to connect the Input of a track to hold the JSFX to the Midi device "X-TOUCH Compact" and route the output of that track to that device as well.

On Bus 2 the JSFX outputs (14 Bit) pitchbend messages with a resolution (Step) selectable by a slider.



here it is:

desc:encoder

slider1:0<0,16,1{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}>in Channel (Bus 1)
slider2:1<0,127,1{0 Bank Sel M,1 Mod Wheel M,2 Breath M,3,4 Foot P M,5 Porta M,6 Data Entry M,7 Vol M,8 Balance M,9,10 Pan M,11 Expression M,12 Ctrl 1 M,13 Ctrl 2 M,14,15,16 GP Slider 1,17 GP Slider 2,18 GP Slider 3,19 GP Slider 4,20,21,22,23,24,25,26,27,28,29,30,31,32 Bank Sel L,33 Mod Wheel L,34 Breath L,35,36 Foot P L,37 Porta L,38 Data Entry L,39 Vol L,40 Balance L,41,42 Pan L,43 Expression L,44 Ctrl 1 L,45 Ctrl 2 L,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64 Hold P sw,65 Porta sw,66 Sustenuto sw,67 Soft P sw,68 Legato P sw,69 Hold 2 P sw,70 S.Variation,71 S.Timbre,72 S.Release,73 S.Attack,74 S.Brightness,75 S.Ctrl 6,76 S.Ctrl 7,77 S.Ctrl 8,78 S.Ctrl 9,79 S.Ctrl 10,80 GP B.1 sw,81 GP B.2 sw,82 GP B.3 sw,83 GP B.4 sw,84,85,86,87,88,89,90,91 Effects Lv,92 Trem Lv,93 Chorus Lv,94 Celeste Lv,95 Phaser Lv,96 Data B. Inc,97 Data B. Dec,98 NRP L,99 NRP M,100 RP L,101 RP M,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127}>in CC
slider3:0<0,16,1{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}>out Channel (Bus 2)
slider4:0.001953125<0.000244140625, 0.0078125, 0.000244140625>Step

in_pin:none
out_pin:none

@init
  ext_midi_bus = 1;
  virtualValue = 0.5;
  ccValue = -1;
  ccLast = -1;
  outLast = -1;

@slider
inBus = 0;
outBus = 1;
inChannel = 0xB0 + slider1;
outChannel = 0xE0 + slider3;
inCC = slider2;
step = slider4;
step2 = step / 2;

@block
   midi_bus = inBus;
   while (midirecv(offset, msg1, msg2, msg3)) (
     inChannel == msg1 ? (
       msg2 == inCC ? (              // Is it the MSB CC?
         ccValue < 0 ? (
           ccValue = msg3;
          ) : ( 
           ccValue < msg3 ? (  // increase
             d = step;
            ) : ccValue > msg3 ? ( // decrease
             d = -step;
            ) : ( 
             d = 0;  // == don't do amnythging
           );
         );
         virtualValue += d; 
         virtualValue < 0 ? (
           virtualValue = 0;
          ) : ( virtualValue > 1 ? 
           virtualValue = 1;
         );  
         ccValue = virtualValue * 128;
         ccValue += 0.5;
         ccValue < 0 ? (
           ccValue = 0;
          ) : ccValue > 127 ? (
           ccValue = 127;
         );  
         ccValue |= 0;
         ccLast != ccValue ? (
           midisend(offset, msg1, msg2, ccvalue);
           ccLast = ccValue;
         );  
         outValue = virtualValue * 16384;
         outValue += 0.5;
         outValue < 0 ? (
           outValue = 0;
          ) : outValue > 16383 ? (
           outValue = 16383;
         );  
         outValue |= 0;
         outLast != outValue ? (
           midi_bus = outBus;
           msg3 = (outValue / 128) | 0;
           msg2 = outValue  - (msg3 * 128);
           midisend(offset, outChannel, msg2, msg3);
           outLast = outValue;
           midi_Bus = inBus;
         );  
       );          
     );
   );

Result:
- The virtual value and thus the Pitchbend message can be controlled with high resolution by turning the rotary
- the LED ring shows the state of the virtual value with the resolution possible by the LED ring (25 different displays when using the mode that displays a value not "Fan" or "Pan")
- The LEDs flicker slightly funny when turning the rotary
- it does not work with a Motor Fader.

-Michael

So long story short, if Geoff thinks this'll work and puts it into CS,I it would be possible to use standard mode with rotaries able to match the MCU mode right? Which would make it worth moving stuff over to standard mode preset wise.

Time will tell!