Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old Yesterday, 04:17 AM   #7041
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 4,224
Default

Quote:
Originally Posted by mschnell View Post
IMHO it would be appropriate to start a new forum thread for Beta test discussions.
I'd like to post some comments there...

-Michael
This is the forum thread for Beta test discussions
__________________
CSI - You can donate here: geoffwaddington.ca
Beta software: https://stash.reaper.fm/v/38349/CSI%20beta.zip
EuCon software: https://stash.reaper.fm/v/37947/reaper_csurf_EuCon.zip
Geoff Waddington is offline   Reply With Quote
Old Yesterday, 05:38 AM   #7042
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,496
Default

OK, if you don't like a harsh break between pre-Alpha and Beta ....
-Michael
mschnell is offline   Reply With Quote
Old Yesterday, 06:53 AM   #7043
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 1,093
Default

Quote:
Originally Posted by Geoff Waddington View Post
New build is up.

Hopefully fixes TrackTouch issues with:
MasterTrackNavigator
SelectedTrackNavigator
FocusedFXNavigator
Nearly there Drops into Write when fader is touched, doesn't drop back out again when released.
MixMonkey is offline   Reply With Quote
Old Yesterday, 10:39 AM   #7044
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 4,224
Default

Quote:
Originally Posted by MixMonkey View Post
Nearly there Drops into Write when fader is touched, doesn't drop back out again when released.
Hmmm... seems to work here.

I'm sure you've already checked these things but just in case

Are you getting a release Midi message ?

Are you using Touch automation mode ?

Maybe some other config thing ?
__________________
CSI - You can donate here: geoffwaddington.ca
Beta software: https://stash.reaper.fm/v/38349/CSI%20beta.zip
EuCon software: https://stash.reaper.fm/v/37947/reaper_csurf_EuCon.zip
Geoff Waddington is offline   Reply With Quote
Old Yesterday, 04:25 PM   #7045
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,496
Default "Beta" comments, just regarding the Wiki

Definition of „Message generator“: This term seems to be used for the functionality provided by the hardware device but then “Message Generators allow you to define” does not make immediate sense.

MST file syntax:

Within widgets always lines containing Keyword message message message …

Comments ?

A comprehensive List of all currently allowed keywords (allowing future enhancement by appropriate description)
We seem to have

Press
Faser7Bit
Fader14Bit
Encoder
EbncoderPlain
EncoderRevers
AnyPress

FB_TwoState
FB_ Fader14Bit
FB_ Fader7Bit
FB_ Encoder
FB_VUMeter
FB_GainReductionMeter
FB_QConProXMasterVUMeter
FB_MCUTimeDisplay
FB_MCUVUMeter
FB_MCUDisplayUpper
FB_MCUDisplayLower
FB_MCUXTDisplayUpper
FB_MCUXTDisplayLower
FB_MCUC4DisplayUpper
FB_MCUC4DisplayLower
FB_MFT_RGB

Are there even more already existing or planned ?

Is it officially supported to use the same (Midi) message in multiple (Generator) Widgets ? (See Shift / Shift_R example in the Wiki.) Will this fire all these Widget-actions ?




Is there a way to test the MST file without crating any zone file ? (i.e. some kind of debug window showing the result of the Widget definitions whenever something is sent by the surface device, and allowing to send something to the MST-widgets and watching the result on the surface device.

Wiki: “It's important to understand it's not the surface deciding when to turn the light on or off. It's doing it in response to a message from CSI. We don't want the surface managing the state of the buttons, that responsibility belongs to Reaper/CSI.”
Unfortunately this behavior can’t be avoided with several Surface devices (such as the XTouch Compact that I do own). As we don’t want to have the surface internally remember the state of a “TwoStae” we need to configure it as a “PushButton”. The LED of a button shows the state of the button pressed=On, released = Off. Hence the state toggled by pressing the button needs to be always sent after receiving a release message. I seem to remember that with certain devices it might be necessary to impose some delay before sending the Feedback message to avoid misbehavior.
Similarly the LED Ring of the rotaries are moved when turning the knob. And this can’t be switched off.

Recently we discussed a Widget that converts the turning of a “fader”-type rotary to a pair of “up/down” buttons. (i.e. encoder).

There is no description on Fader14Bit yet. I suppose this generator will cover the MCU-like “pseudo-Midi” messages. But there also is an official “high resolution CC” Midi definition for this kind of messages I don’t know if any surfaces actually do use this.). Moreover there is Midi2 around the corner…

Some devices use Sysex messages instead of standard Midi messages. How is this covered by CSI ?

While it’s obviously great to have Generators and Feedback processors dedicated to certain surfaces, IMHO it would be very appropriate to have a small set of more versatile (and hence less easy to use) “expert” Generators and Feedback processors allow for special purpose applications.


For Zone files:
“Action Reference” seems to provide a comprehensive list of all currently allowable actions. Are all of them intended to already be functional ?

It would be good to have a debug mode that does not actually execute these actions but just shows them in a log on the screen.

Do all such actions automatically provide the appropriate feedback to the Widget (or multiple widgets) they are associated with ?

Wiki -> Home-> Examples that come with the alpha download does not seem to work correctly


-Michael
mschnell is offline   Reply With Quote
Old Yesterday, 09:59 PM   #7046
KroniK907
Human being with feelings
 
Join Date: Mar 2017
Posts: 7
Default

Is there a way to have variables in the MST MIDI hex data?

I know that at least in the case of my mixer, the first bit is the MIDI channel number. Since we set up the midi channel info when setting up a surface, is there a way that could have a channel_in and channel_out variable so that re-writing an mst is not necessary if for some reason you need to change midi channels for your surface?

obviously channel_in and channel_out are long variable names and could be shortened.

Another thought I had was to have variable support in general in the mst file. To make mst files more readable it would be nice to be able to set different hex values to named variables. For a board with a bunch of faders, you will end up needing to copy and paste a ton of stuff and only change a single bit to identify the fader channel.

If instead there were variable support, you could make setup for new surfaces much simpler by only needing to change the values of some standard variables rather than writing out a whole mst file.

I'm imagining something like this:

Code:
//EDIT THESE VALUES 
MCHP = B0  //MIDI Channel Primary
MCHS = B1  //MIDI Channel Secondary

FS = 00   //Fader Strip ID 1
FM = 20   //Fader Mute 1

FMV = 7F   //Fader Max Value
FZV = 00   //Fader Zero Value
NO = 7F    //Note On
NF = 00    //Note Off


Widget CH1_Fader
  Fader7Bit $MCHP $FS $FMV
  FB_Fader7Bit $MCHP $FS $FZV
WidgetEnd

Widget CH2_Fader
  Fader7Bit $MCHP $FS+1 $FMV
  FB_Fader7Bit $MCHP $FS+1 $FZV
WidgetEnd

Widget CH1_Mute
  press $MCHP $FM $NO
  FB_TwoState $MCHP $FM $NO  $MCHP $FM $NF
WidgetEnd

Widget CH2_Mute
  press $MCHP $FM+1 $NO
  FB_TwoState $MCHP $FM+1 $NO  $MCHP $FM+1 $NF
WidgetEnd
If hex math and variables were available to use, it would be way easier to set up an mst for a new surface, and make things much more human readable for easy troubleshooting.

Even better when considering items that repeat with a single value change, it would be cool to simply make a single widget template and then have some syntax where you identify the variable that changes with each widget, and how your widget name changes, and how many widgets you want. Then the plugin extrapolates from there on boot up. Would be very useful for repeating widgets.

Maybe something like:
Code:
WidgetTemplate Faders
  Data
    Fader7Bit B0 $H 7F
    FB_Fader7Bit B0 $H 00
  Settings
    NumWidgets 16
    Name Fader_Ch$I
    IncrementBy 1
    StartVal_H 00
    StartVal_I 1
WidgetTemplateEnd
$H would be some standardized syntax that represents the hex value that will change with each widget.
$I is similar to $H but is an integer rather than hex and would be used to increment widget name values.
NumWidgets describes how many widgets this template will generate
Name describes the widget name and must include $I somewhere which will ensure incrementing widget names
IncrementBy is used to describe the increment value of $H not $I as $I would be incremented by 1 regardless.
StartVal_H is the hex value for $H for the first widget.
StartVal_I is the integer value for $I for the first widget.

I think this would cover just about any use case where you have like 16 faders or 32 knobs or some other similar scenario where you need to make a bunch of widgets where only the faderID or KnobID etc. is changing for each widget.

Last edited by KroniK907; Yesterday at 11:07 PM.
KroniK907 is offline   Reply With Quote
Old Yesterday, 11:56 PM   #7047
KroniK907
Human being with feelings
 
Join Date: Mar 2017
Posts: 7
Default

Can you add a new NRPN message generator and Feedback Processor?

To unlock all of the buttons and knobs on my mixer, 90% of the 'widgets' use what Allen & Heath call NRPN messages which is a series of 4 bytes.



This format does not seem to be currently supported. Please let me know if one of the existing message generators and feedback processors supports this format.

Full MIDI protocol manual here. NRPN message section starts on page 4.
KroniK907 is offline   Reply With Quote
Old Today, 03:49 AM   #7048
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 4,224
Default

Quote:
Originally Posted by KroniK907 View Post
Is there a way to have variables in the MST MIDI hex data?

I know that at least in the case of my mixer, the first bit is the MIDI channel number. Since we set up the midi channel info when setting up a surface, is there a way that could have a channel_in and channel_out variable so that re-writing an mst is not necessary if for some reason you need to change midi channels for your surface?

You don't set up the midi channel info when setting up a surface, you set up a port.

It's easy to confuse this stuff especially if you are used to the Midi protocol.

Control surface language is NOT Midi.

For instance you may think this means 3 messages each to a different Midi channel.

e0 34 45
e2 45 45
e7 00 00


Nope it means set Faders 1, 3, and 8 to the sent value, nothing to do with channels.


Quote:
Originally Posted by KroniK907 View Post
Another thought I had was to have variable support in general in the mst file. To make mst files more readable it would be nice to be able to set different hex values to named variables. For a board with a bunch of faders, you will end up needing to copy and paste a ton of stuff and only change a single bit to identify the fader channel.

If instead there were variable support, you could make setup for new surfaces much simpler by only needing to change the values of some standard variables rather than writing out a whole mst file.

I'm imagining something like this:

Code:
//EDIT THESE VALUES 
MCHP = B0  //MIDI Channel Primary
MCHS = B1  //MIDI Channel Secondary

FS = 00   //Fader Strip ID 1
FM = 20   //Fader Mute 1

FMV = 7F   //Fader Max Value
FZV = 00   //Fader Zero Value
NO = 7F    //Note On
NF = 00    //Note Off


Widget CH1_Fader
  Fader7Bit $MCHP $FS $FMV
  FB_Fader7Bit $MCHP $FS $FZV
WidgetEnd

Widget CH2_Fader
  Fader7Bit $MCHP $FS+1 $FMV
  FB_Fader7Bit $MCHP $FS+1 $FZV
WidgetEnd

Widget CH1_Mute
  press $MCHP $FM $NO
  FB_TwoState $MCHP $FM $NO  $MCHP $FM $NF
WidgetEnd

Widget CH2_Mute
  press $MCHP $FM+1 $NO
  FB_TwoState $MCHP $FM+1 $NO  $MCHP $FM+1 $NF
WidgetEnd
If hex math and variables were available to use, it would be way easier to set up an mst for a new surface, and make things much more human readable for easy troubleshooting.

Even better when considering items that repeat with a single value change, it would be cool to simply make a single widget template and then have some syntax where you identify the variable that changes with each widget, and how your widget name changes, and how many widgets you want. Then the plugin extrapolates from there on boot up. Would be very useful for repeating widgets.

Maybe something like:
Code:
WidgetTemplate Faders
  Data
    Fader7Bit B0 $H 7F
    FB_Fader7Bit B0 $H 00
  Settings
    NumWidgets 16
    Name Fader_Ch$I
    IncrementBy 1
    StartVal_H 00
    StartVal_I 1
WidgetTemplateEnd
$H would be some standardized syntax that represents the hex value that will change with each widget.
$I is similar to $H but is an integer rather than hex and would be used to increment widget name values.
NumWidgets describes how many widgets this template will generate
Name describes the widget name and must include $I somewhere which will ensure incrementing widget names
IncrementBy is used to describe the increment value of $H not $I as $I would be incremented by 1 regardless.
StartVal_H is the hex value for $H for the first widget.
StartVal_I is the integer value for $I for the first widget.

I think this would cover just about any use case where you have like 16 faders or 32 knobs or some other similar scenario where you need to make a bunch of widgets where only the faderID or KnobID etc. is changing for each widget.
We already do something very similar in .zon files using the "|" character.

We decided to make it difficult to change the .mst precisely because we want to discourage it, and point folks toward the .zon file approach insttead, it's usually the best way.
__________________
CSI - You can donate here: geoffwaddington.ca
Beta software: https://stash.reaper.fm/v/38349/CSI%20beta.zip
EuCon software: https://stash.reaper.fm/v/37947/reaper_csurf_EuCon.zip
Geoff Waddington is offline   Reply With Quote
Old Today, 03:56 AM   #7049
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 4,224
Default

Quote:
Originally Posted by KroniK907 View Post
Can you add a new NRPN message generator and Feedback Processor?

To unlock all of the buttons and knobs on my mixer, 90% of the 'widgets' use what Allen & Heath call NRPN messages which is a series of 4 bytes.



This format does not seem to be currently supported. Please let me know if one of the existing message generators and feedback processors supports this format.

Full MIDI protocol manual here. NRPN message section starts on page 4.
Just had a quick look, unfortunately won't be doing this one and it has nothing to do with NRPN.

There is a section just before the NRPN section where they indicate that the transport uses SysEx, Reaper does not support reading SysEx, so it's a non starter, and actually a very poor design choice on AH's part IMHO

Do they have an OSC variant ? -- CSI also speaks OSC.
__________________
CSI - You can donate here: geoffwaddington.ca
Beta software: https://stash.reaper.fm/v/38349/CSI%20beta.zip
EuCon software: https://stash.reaper.fm/v/37947/reaper_csurf_EuCon.zip
Geoff Waddington is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:31 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.