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

Reply
 
Thread Tools Display Modes
Old 01-13-2019, 12:20 PM   #2321
poetnprophet
Human being with feelings
 
poetnprophet's Avatar
 
Join Date: Jan 2018
Posts: 1,455
Default

Quote:
Originally Posted by Travesty View Post
I think I understand, so I could create a zone which was just the pads on Maschine, then use a modifier to change just how that zone behaves?
Ok that makes some sense, pretty cool and hell yes!
__________________
https://www.kdubbproductions.com/
https://www.youtube.com/channel/UCpC...2dGA3qUWBKrXQQ
i7 8700k,4.9Ghz,Win10,Reaper 6,Motu 828es, Cranborne ADAT500
poetnprophet is offline   Reply With Quote
Old 01-13-2019, 08:03 PM   #2322
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by Travesty View Post
I think I understand, so I could create a zone which was just the pads on Maschine, then use a modifier to change just how that zone behaves?
Exactly, or even things like:

Each row is a zone
Each column is a zone
Each quadrant (2x2 buttons on a Maschine) is a zone
etc.

This, along with Layers on the axt/fxt side, seems to make much more sense than the discussion about a matrix approach we had a while back.

Seems like navigation doesn't really make sense in a huge row column way, but rather in a "clusters" of surface controls/actions way.

Perhaps a better word for Layer is Overlay, that conveys the sense that these are temporary overrides of the normal functionality (e.g. fxt overlay), dunno...
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-14-2019, 03:56 AM   #2323
Travesty
Human being with feelings
 
Travesty's Avatar
 
Join Date: Nov 2014
Posts: 567
Default

Yeah, I think overlay works,
Travesty is offline   Reply With Quote
Old 01-14-2019, 06:21 AM   #2324
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Thumbs up

Quote:
Originally Posted by Geoff Waddington View Post
Exactly, or even things like:

Each row is a zone
Each column is a zone
Each quadrant (2x2 buttons on a Maschine) is a zone
etc.

This, along with Layers on the axt/fxt side, seems to make much more sense than the discussion about a matrix approach we had a while back.

Seems like navigation doesn't really make sense in a huge row column way, but rather in a "clusters" of surface controls/actions way.

Perhaps a better word for Layer is Overlay, that conveys the sense that these are temporary overrides of the normal functionality (e.g. fxt overlay), dunno...
Yes, the Zone and Overlay concepts sound very clean and useful to me. *thumbsup*

By the way: the current FX overlay / mapping method still does not work well for me, it gets often confused what FX to map to the surface requiring mouse clicks to get it right.
Also, I have found no way yet to unmap the overlay from the surface so that the original page mapping becomes active again. Am I missing something obvious?

Last edited by dixo; 01-14-2019 at 06:43 AM.
dixo is offline   Reply With Quote
Old 01-14-2019, 06:39 AM   #2325
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default BCR2000

Hi Geoff,

I have been experimenting with my BCR2000 to use it as an FX controller in CSI.
I created a preset on the BCR where every button sends an "on" midi message when pressed, and an "off" message when released, identical to the behavior of my QCon surface, or the MCU.
However, the BCR2000 shows the same odd behavior as already seen for the X-Touch: the BCR always turns off the LED in the button when released. So, it requires CSI to resend the actual state the LED should be showing when it receives the 'release' message for the button.
From this thread I read that there are variations of the Button widget, ending in 'FB' and 'FBR'. According to the X-Touch posts, the '..FBR' should be the correct one, but it seems it is not sending the correct state message: when I have output monitoring on in CSI I can verify that a message is sent, but not with the correct state of the controlled parameter (e.g. 'Play').
I saw that you have been working on this with mschnell in the past (for the X-Touch) but the discussion seems to have ended unresolved.
Is there anything I can do to help debugging this?

Last edited by dixo; 01-14-2019 at 06:49 AM.
dixo is offline   Reply With Quote
Old 01-14-2019, 03:27 PM   #2326
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
Yes, the Zone and Overlay concepts sound very clean and useful to me. *thumbsup*

By the way: the current FX overlay / mapping method still does not work well for me, it gets often confused what FX to map to the surface requiring mouse clicks to get it right.
Also, I have found no way yet to unmap the overlay from the surface so that the original page mapping becomes active again. Am I missing something obvious?
Nope, tne fx overlay was just roughed in to keep us going while we were discussing matrix, so it's still very weak.

The inclusion of generalized overlays will allow proper coding of fx overlays.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-14-2019, 03:34 PM   #2327
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
Hi Geoff,

I have been experimenting with my BCR2000 to use it as an FX controller in CSI.
I created a preset on the BCR where every button sends an "on" midi message when pressed, and an "off" message when released, identical to the behavior of my QCon surface, or the MCU.
However, the BCR2000 shows the same odd behavior as already seen for the X-Touch: the BCR always turns off the LED in the button when released. So, it requires CSI to resend the actual state the LED should be showing when it receives the 'release' message for the button.
From this thread I read that there are variations of the Button widget, ending in 'FB' and 'FBR'. According to the X-Touch posts, the '..FBR' should be the correct one, but it seems it is not sending the correct state message: when I have output monitoring on in CSI I can verify that a message is sent, but not with the correct state of the controlled parameter (e.g. 'Play').
I saw that you have been working on this with mschnell in the past (for the X-Touch) but the discussion seems to have ended unresolved.
Is there anything I can do to help debugging this?
What's really wrong here with the X-Touch Compact, BCR2000, and the Console 1 by the way, is the way they set the lights.

These surfaces commit the cardinal sin of setting the lights from the buttons -- they should be completely separate operations in a proper design.

Only the DAW should set the button lights, encoder positions, etc.

Is there a way to set your BCR preset so that it does not set the lights, etc.?
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-14-2019, 10:53 PM   #2328
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
Is there a way to set your BCR preset so that it does not set the lights, etc.?
With these devices (including the XTpouch in native mode, and supposedly most/many non MC protocol devices of any brand) there is no way to have them stop to set the lights themselves when turning knobs or when pressing a button. But of course sending back the value after it has been set by the device does not change anything. We need to live with that.

OTOH: Motor faders do work the same. They "visually" already are in the position the device sends, and sending that position to the device does not matter. So the button behavior is actually consistent.

In fact in MC protocol the DAW needs to regularly re-send the fader position, otherwise the fader will go back to zero. (not really consistent )

-Michael
mschnell is offline   Reply With Quote
Old 01-15-2019, 04:14 AM   #2329
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by mschnell View Post
In fact in MC protocol the DAW needs to regularly re-send the fader position, otherwise the fader will go back to zero. (not really consistent )

-Michael
Hmmm... I don't see that behaviour here.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-15-2019, 05:51 AM   #2330
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post
What's really wrong here with the X-Touch Compact, BCR2000, and the Console 1 by the way, is the way they set the lights.

These surfaces commit the cardinal sin of setting the lights from the buttons -- they should be completely separate operations in a proper design.

Only the DAW should set the button lights, encoder positions, etc.

Is there a way to set your BCR preset so that it does not set the lights, etc.?
I don't think there is any way to disable the internal feedback of the button state to the LED on the BCR2000.

From a DAW control surface point of view I agree that the 'internal feedback' of the BCR and the likes is wrong. But I think that at least the BCR was originally more intended as a generic controller for 'classic' MIDI hardware like synths, in a one-way setup. In that case - no feedback from the controlled device - the internal feedback of the BCR makes perfect sense.
In fact, this feedback also happens for the LED rings around the knobs, but so far I have not found any conflicts with CSI for these. But it would conflict if you want the LED ring to show something different than what the BCR sets (can't think of any practical scenario at the moment).

In any case, it would be really great if CSI can adapt to the quirks of some of the surfaces that are around and it seems you have already implemented the solution: an '..FBR' button widget that sends the LED state (= state of the Reaper parameter currently mapped to the button widget) when receiving the 'button release' message. It just looks like the wrong state is transmitted.

If CSI would periodically transmit/refresh the state of all LED widgets it would also fix the problem. That is probably a matter of what implementation you prefer, and scalability.

Last edited by dixo; 01-15-2019 at 05:56 AM.
dixo is offline   Reply With Quote
Old 01-15-2019, 06:40 AM   #2331
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
I don't think there is any way to disable the internal feedback of the button state to the LED on the BCR2000.

From a DAW control surface point of view I agree that the 'internal feedback' of the BCR and the likes is wrong. But I think that at least the BCR was originally more intended as a generic controller for 'classic' MIDI hardware like synths, in a one-way setup. In that case - no feedback from the controlled device - the internal feedback of the BCR makes perfect sense.
In fact, this feedback also happens for the LED rings around the knobs, but so far I have not found any conflicts with CSI for these. But it would conflict if you want the LED ring to show something different than what the BCR sets (can't think of any practical scenario at the moment).

In any case, it would be really great if CSI can adapt to the quirks of some of the surfaces that are around and it seems you have already implemented the solution: an '..FBR' button widget that sends the LED state (= state of the Reaper parameter currently mapped to the button widget) when receiving the 'button release' message. It just looks like the wrong state is transmitted.

If CSI would periodically transmit/refresh the state of all LED widgets it would also fix the problem. That is probably a matter of what implementation you prefer, and scalability.
Yeah, I like elegant solutions, but every so often you have to bow to the practical, brute force approach

Maybe the solution is, as you suggest, a "ping" from Reaper every so often.

As usual, these work arounds come at a cost.

Here, the cost is the answer to the question, "How often should Reaper ping ?"

Hmmm.... well... CSI is all about customization and tuning to your personal environment.

Ok, Ok, let go my arm, I'm beat.

There will be a new entry field in the CSI config (and of course a new entry in CSI.ini.) CSI controller refresh rate, in seconds, probably defaults to something like 0.5 seconds.

The FBR flavours of widget will be removed.

I think this is justified, because we are seeing real world results with real world gear -- once again thanks for testing folks.

What do you think ?
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-15-2019, 07:11 AM   #2332
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by mschnell View Post
With these devices (including the XTpouch in native mode, and supposedly most/many non MC protocol devices of any brand) there is no way to have them stop to set the lights themselves when turning knobs or when pressing a button. But of course sending back the value after it has been set by the device does not change anything. We need to live with that.
Edit:

You need to consider to send the state after receiving the button release rather than the button press message !

Doing the actual functionality on release might or might not be advantageous. This would allow for detecting short and long presses (I do this with my implementation in EEL), and it also would allow for detecting multiple simultaneously pressed button independent from the sequence.

-Michael
mschnell is offline   Reply With Quote
Old 01-15-2019, 07:13 AM   #2333
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
Hmmm... I don't see that behaviour here.
AFAI Remember: when I set my X-Touch to MC mode (which I did for testing purpose) the faders return to zero when no data is received for some time.

-Michael

Last edited by mschnell; 01-15-2019 at 07:20 AM.
mschnell is offline   Reply With Quote
Old 01-15-2019, 07:14 AM   #2334
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by dixo View Post
I don't think there is any way to disable the internal feedback of the button state to the LED on the BCR2000.
I do know that this is not possible with the XTouch in native mode.

-Michael
mschnell is offline   Reply With Quote
Old 01-15-2019, 07:16 AM   #2335
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yeah, I like elegant solutions, but every so often you have to bow to the practical, brute force approach
??? Simply (additionally) send the state when receiving a button release message.

To me this does not seem too non-elegant

(non-elegant: theoretically this could be performed by an additional OSCIIBot program . )

-Michael
mschnell is offline   Reply With Quote
Old 01-15-2019, 07:30 AM   #2336
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post

The FBR flavours of widget will be removed.

I think this is justified, because we are seeing real world results with real world gear -- once again thanks for testing folks.

What do you think ?
My preference would be to have the correct LED state sent back when CSI receives a button release (i.e. the FBR flavour). That seems most elegant, keeps the amount of sent traffic to what is absolutely required and keep the delay between releasing the button and updating the LED to the correct state as low as possible. On top of that, you already seem to have implemented that solution but it just doesn't work properly yet.
So, with some debugging and some corrections this may be the best way to handle this type of buttons.

Having the periodic update option may be a good thing for some as of yet undiscovered hardware with strange behaviour, as some type of last resort. But it should be possible to disable for cases where a better option is available.
dixo is offline   Reply With Quote
Old 01-15-2019, 11:04 AM   #2337
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by mschnell View Post
??? Simply (additionally) send the state when receiving a button release message.

To me this does not seem too non-elegant

(non-elegant: theoretically this could be performed by an additional OSCIIBot program . )

-Michael
Quote:
Originally Posted by dixo View Post
My preference would be to have the correct LED state sent back when CSI receives a button release (i.e. the FBR flavour). That seems most elegant, keeps the amount of sent traffic to what is absolutely required and keep the delay between releasing the button and updating the LED to the correct state as low as possible. On top of that, you already seem to have implemented that solution but it just doesn't work properly yet.
So, with some debugging and some corrections this may be the best way to handle this type of buttons.

Having the periodic update option may be a good thing for some as of yet undiscovered hardware with strange behaviour, as some type of last resort. But it should be possible to disable for cases where a better option is available.
Yes, agree on all points you both make if we constrain the solution to your use cases.

However, you may notice I also referenced the Console 1 in my first post on this topic.

Here is the Console 1 behaviour with the UAD Pultec low frequency control mapped to 2 Console 1 controls.

Notice how everything is fine when adjusting with the mouse, but when a Console 1 control is used, we get suboptimal behaviour, because of the internal feedback.

https://youtu.be/YbWzWva-bII

So here we have somewhat related issues that can be solved by a periodic update mechanism.

I think I'll implement it at a per widget level, but for now users will set it on a per surface/per page basis.

What do you think ?
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-15-2019, 02:30 PM   #2338
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

While I agree with you that providing a simple self-contained keyword describing a certain kind of "button" is great for those user that do have devices that provide exactly this functionality, I still vote for additionally having a "basic" (or fully definable) button keyword that handles all thinkable cases, and can be used by "experts" (to define configuration files, that nonetheless can be used by "anybody").

I already described this several weeks ago, but maybe the recent discussions might add some after thoughts to that.

It should be definable ho press and release are recognized, and what to do at press and at release-time of the button (what to send what CSI action should be fired).

As I described in that message, with this it would even be possible to create a pair of buttons from a rotary (e.g. to scroll the channels).

-Michael
mschnell is offline   Reply With Quote
Old 01-15-2019, 02:53 PM   #2339
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by mschnell View Post
While I agree with you that providing a simple self-contained keyword describing a certain kind of "button" is great for those user that do have devices that provide exactly this functionality, I still vote for additionally having a "basic" (or fully definable) button keyword that handles all thinkable cases, and can be used by "experts" (to define configuration files, that nonetheless can be used by "anybody").

I already described this several weeks ago, but maybe the recent discussions might add some after thoughts to that.

It should be definable ho press and release are recognized, and what to do at press and at release-time of the button (what to send what CSI action should be fired).

As I described in that message, with this it would even be possible to create a pair of buttons from a rotary (e.g. to scroll the channels).

-Michael

Suppose you had a definition like this:

SomeButton PressRelease 90 46 7f 90 46 00

Would this do what you want ?

SomeButtonPress Press 90 46 7f
SomeButtonRelease Press 90 46 00

and in an .axt file

SomeButtonPress SomeAction
SomeButtonRelease AnotherAction
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-15-2019, 10:54 PM   #2340
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Allowing for a dedicate (functionally -> .axt) release action for buttons seems like a good idea do cover in certain cases. It would open up possibilities like "do something {e.g. play} while pressed, "long press" special action, "DoubleClick", "simultaneous pressing multiple buttons", ... to be provided by the CSI infrastructure.

This of course would not effect the handling of the light in a button.

For the issue in question, the "SomeButton PressReleaseXXX" definition would need enough parameters to care for the special cases. At least:
- Define message we receive when pressed
- Define message we receive when released
- Define message we send to the device after receiving a "pressed" message (which might be modified by the state CSI stores after this action).
- Define message we send to the device after receiving a "released" message (which might be modified by the state CSI stores after this action).

Thanks for listening,
-Michael
mschnell is offline   Reply With Quote
Old 01-16-2019, 03:59 AM   #2341
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

First of all, thanks for all the good discussion and testing, to you and everyone else participating.

Quote:
Originally Posted by mschnell View Post
Allowing for a dedicate (functionally -> .axt) release action for buttons seems like a good idea do cover in certain cases. It would open up possibilities like "do something {e.g. play} while pressed, "long press" special action, "DoubleClick", "simultaneous pressing multiple buttons", ... to be provided by the CSI infrastructure.

This of course would not effect the handling of the light in a button.

For the issue in question, the "SomeButton PressReleaseXXX" definition would need enough parameters to care for the special cases. At least:
Let's re-use our previous example:

SomeButton PressRelease 90 46 7f 90 46 00

We are going to remove this definition and it will be replaced by the ones below.


Quote:
- Define message we receive when pressed
You can already do this:

SomeButtonPress Press 90 46 7f in the .rst file -- give a name to the button press
SomeButtonPress SomeAction in the .axt file -- tie button press to an action

Quote:
- Define message we receive when released
You can already do this:

SomeButtonRelease Press 90 46 00 in the .rst file -- give a name to the button release
SomeButtonRelease AnotherAction in the .axt file -- tie button release to another action


Quote:
- Define message we send to the device after receiving a "pressed" message (which might be modified by the state CSI stores after this action).
Generally we don't want to store surface state where we can avoid it, please describe a use case.

Quote:
- Define message we send to the device after receiving a "released" message (which might be modified by the state CSI stores after this action).
See above.

Quote:
Thanks for listening,
-Michael
Thanks for contributing !
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 04:51 AM   #2342
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yes, agree on all points you both make if we constrain the solution to your use cases.

However, you may notice I also referenced the Console 1 in my first post on this topic.

Here is the Console 1 behaviour with the UAD Pultec low frequency control mapped to 2 Console 1 controls.

Notice how everything is fine when adjusting with the mouse, but when a Console 1 control is used, we get suboptimal behaviour, because of the internal feedback.

https://youtu.be/YbWzWva-bII

So here we have somewhat related issues that can be solved by a periodic update mechanism.

I think I'll implement it at a per widget level, but for now users will set it on a per surface/per page basis.

What do you think ?
I don't mean to get a solution just for my use case, but it seems to me that the internal feedback is a common and somehow logical addition to the range of widget variations (e.g. rotaries, faders, buttons):
- Widget without feedback
- Widget with feedback
- Widget with internal feedback

These seem to be the main types of behaviour we have seen so far on all surfaces that people have tested with.

For instance, I think the behaviour of the Console 1 knobs is not different from how the BCR2000 behaves for its knobs (although I have not tried the scenario shown in the video).

Although a periodic update will ensure that the LEDs will (eventually) show the correct state, it has the drawback that there is a trade-off between response time and MIDI traffic: you don't want to wait too long for the LED state to be updated (i.e. update frequently) but you don't want to send too much unnecessary MIDI traffic (i.e. update infrequently).

So, to me it seems a smarter implementation will be beneficial, only updating state when necessary, and only for the widgets that need it:
1) The parameter mapped to the LED has changed (e.g. mouse action on screen, or through another surface, etc). This may be sufficient for 'properly' implemented surfaces like the QCon or MCU.
2) The control associated with the LED (e.g. the button or rotary) was operated (pressed, released, rotated). This is what the BCR/X-Touch and Console 1 require (in addition to 1).

On top of that a periodic update would be very useful to cater for edge cases or MIDI transmission errors (I see these for instance on my LCD displays now and then) but it can be at a fairly low rate, and thus saves bandwidth on the MIDI connection.

If you are going to implement a periodic refresh then indeed per widget control would be nice. But in the meantime, at page level seems more natural/flexible to me than per surface, although a page may contain a mix of surfaces with different needs for periodic update.

Last edited by dixo; 01-16-2019 at 05:19 AM.
dixo is offline   Reply With Quote
Old 01-16-2019, 06:20 AM   #2343
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Once again, thanks for all the good discussion and testing, to you and everyone else participating.

Quote:
Originally Posted by dixo View Post
I don't mean to get a solution just for my use case, but it seems to me that the internal feedback is a common and somehow logical addition to the range of widget variations (e.g. rotaries, faders, buttons):
- Widget without feedback
- Widget with feedback
- Widget with internal feedback

These seem to be the main types of behaviour we have seen so far on all surfaces that people have tested with.

For instance, I think the behaviour of the Console 1 knobs is not different from how the BCR2000 behaves for its knobs (although I have not tried the scenario shown in the video).
Agree, but there are some other common ones too, like the faders returning to zero after some time with no "heartbeat" from Reaper.


Quote:
Although a periodic update will ensure that the LEDs will (eventually) show the correct state, it has the drawback that there is a trade-off between response time and MIDI traffic: you don't want to wait too long for the LED state to be updated (i.e. update frequently) but you don't want to send too much unnecessary MIDI traffic (i.e. update infrequently).
Yes, this is a very important consideration, let's do some very rough, ballpark math.

I have a reasonably sized CSI setup:
2 Avid Artist Mix units -- similar to MCU extenders
1 Avid Artist Control -- similar to MCU
1 Console 1

Altogether there are about 300 widgets in this setup.

So, 300 widgets X 3 bytes/widget = 900, let's add 100 for SysEx.

So total = 1000 bytes / update.

That translates to about 10,000 baud -- 2 start/stop bits and an 8 bit payload.

Add to that the fact the the surfaces each use their own individual midi I/O, if the load is spread approximately evenly that's about 2500 baud per Midi I/O.

Even ancient old 5 pin DIN Midi is 31,500 baud, and who uses 5 pin DINs anymore ?

USB Midi is a lot faster


Quote:
So, to me it seems a smarter implementation will be beneficial, only updating state when necessary, and only for the widgets that need it:
1) The parameter mapped to the LED has changed (e.g. mouse action on screen, or through another surface, etc). This may be sufficient for 'properly' implemented surfaces like the QCon or MCU.
2) The control associated with the LED (e.g. the button or rotary) was operated (pressed, released, rotated). This is what the BCR/X-Touch and Console 1 require (in addition to 1).
In theory, yes, but I've seen some weird cases where the internal updating seems to happen AFTER the resend from Reaper, perhaps some internal firmware priority algo, the periodic, brute force method also solves any internal timing related things like this.

Quote:
On top of that a periodic update would be very useful to cater for edge cases or MIDI transmission errors (I see these for instance on my LCD displays now and then) but it can be at a fairly low rate, and thus saves bandwidth on the MIDI connection.

If you are going to implement a periodic refresh then indeed per widget control would be nice. But in the meantime, at page level seems more natural/flexible to me than per surface, although a page may contain a mix of surfaces with different needs for periodic update.
Yeah, I originally thought page level, but as you say, the variation amongst surfaces pushes the design towards at least surface level user tuning.

Thanks again for the discussion, your thinking is spot on !
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 07:52 AM   #2344
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Thanks for your reply Geoff. Yes, it is quite a challenge to handle all this different hardware behaviour with a small and universal set of rules.

I guess you are right, I may be overly concerned with the bandwidth impact of an update cycle.

If the periodic update works well it will be a very nice way to handle a lot of weird behaviour of some hardware that is out there.

Can't wait to test it and see how it works out!

Thanks again for all your work!
dixo is offline   Reply With Quote
Old 01-16-2019, 08:23 AM   #2345
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
Generally we don't want to store surface state where we can avoid it, please describe a use case.
I did not mean a state of the surface, but the internal state of CSI. e.g. toggling Mute or whatever needs to hold the state of being muted or unmuted, and on the next button press use the previous state to calculate the new one.

Regarding the Surface, this state needs to be sent to it (e.g. after the release message arrived) to handle the light.

This already does (kind of) work, but needs a single "button..." definition for as well the "press" as the "release" incoming message. This (currently) prevents CGI from internally doing different actions for press and for release.

-Michael
mschnell is offline   Reply With Quote
Old 01-16-2019, 10:45 AM   #2346
poetnprophet
Human being with feelings
 
poetnprophet's Avatar
 
Join Date: Jan 2018
Posts: 1,455
Default

Quote:
Originally Posted by Geoff Waddington View Post

Even ancient old 5 pin DIN Midi is 31,500 baud, and who uses 5 pin DINs anymore ?
well, I have the old C4 that can only connect via 5-pin midi
__________________
https://www.kdubbproductions.com/
https://www.youtube.com/channel/UCpC...2dGA3qUWBKrXQQ
i7 8700k,4.9Ghz,Win10,Reaper 6,Motu 828es, Cranborne ADAT500
poetnprophet is offline   Reply With Quote
Old 01-16-2019, 11:22 AM   #2347
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
Thanks for your reply Geoff. Yes, it is quite a challenge to handle all this different hardware behaviour with a small and universal set of rules.
Yeah, when I took this on over 2 years ago I knew it was going to be a challenge, and I'd already been programming software for control surfaces for 10 years -- first was the Faderport software in 2006

Quote:
Originally Posted by dixo View Post
I guess you are right, I may be overly concerned with the bandwidth impact of an update cycle.
You are right to be concerned -- but doing the rough math shows us using less than 10% of the available bandwidth at 31,500 baud, and most modern interfaces are a lot faster.

Quote:
Originally Posted by dixo View Post
If the periodic update works well it will be a very nice way to handle a lot of weird behaviour of some hardware that is out there.

Can't wait to test it and see how it works out!

Thanks again for all your work!
Thanks, yeah, will be interesting to see what happens.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 11:38 AM   #2348
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by mschnell View Post
I did not mean a state of the surface, but the internal state of CSI. e.g. toggling Mute or whatever needs to hold the state of being muted or unmuted, and on the next button press use the previous state to calculate the new one.
Actually CSI doesn't work that way, there is no holding of state in that sense.

When you press Mute you execute an action, no notion of the button state is held.

If there is feedback the action simply asks Reaper for the current state of the Mute, and then sends that to the button.

CSI doesn't hold state, nor should it, too easy to get out of synch.


Quote:
Originally Posted by mschnell View Post
This already does (kind of) work, but needs a single "button..." definition for as well the "press" as the "release" incoming message. This (currently) prevents CGI from internally doing different actions for press and for release.

-Michael
I still don't understand you I guess.

The following is an example of a button where press and release do completely different actions.

// Here we define the press and release as two separate buttons even though it's actually only a single button with press and release
SomeButtonPress Press 90 46 7f in the .rst file -- give a name to the button press
SomeButtonRelease Press 90 46 00 in the .rst file -- give a name to the button release

// Here we attach the 2 buttons we defined to whatever actions we choose
SomeButtonPress SomeAction in the .axt file -- tie button press to an action
SomeButtonRelease AnotherAction in the .axt file -- tie button release to another action

I presume this isn't what you want, but I am confused when you say "This (currently) prevents CSI from internally doing different actions for press and for release. "

The above is an example of exactly that, so I must be misunderstanding what you need.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki

Last edited by Geoff Waddington; 01-16-2019 at 11:47 AM.
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 11:40 AM   #2349
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by poetnprophet View Post
well, I have the old C4 that can only connect via 5-pin midi
Haha, I was being facetious to make a point -- even with 31,500 baud the 2500 needed for the update is less that 10% of the bandwidth.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 12:19 PM   #2350
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post
Haha, I was being facetious to make a point -- even with 31,500 baud the 2500 needed for the update is less that 10% of the bandwidth.
But you also must take the update frequency into account. If you want the LEDs to reflect the actual states reasonably quickly after the control with internal feedback is released (say 1/10th of a second), you need 10 updates per second. This means (using the data from your example) 10 x 2500 bits = 25000 bits per second.
So now we are already at 80% the 31250 bits/second bandwidth of a (5 pin) MIDI stream.

Also, the 2500 bits update takes about 80ms to transmit. If you transmit it in bulk this may add a random 80ms latency to the response time of CSI to Reaper state changes. Of course you could spread out the update or prioritize traffic to mitigate this.
Not saying this will be noticeable, I have no idea what the current latency of CSI is.

So, again, I am not saying this will be a big deal or not in real world scenarios, but it is stuff to take into account (if I did the math correctly).
dixo is offline   Reply With Quote
Old 01-16-2019, 01:00 PM   #2351
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
But you also must take the update frequency into account. If you want the LEDs to reflect the actual states reasonably quickly after the control with internal feedback is released (say 1/10th of a second), you need 10 updates per second. This means (using the data from your example) 10 x 2500 bits = 25000 bits per second.
So now we are already at 80% the 31250 bits/second bandwidth of a (5 pin) MIDI stream.

Also, the 2500 bits update takes about 80ms to transmit. If you transmit it in bulk this may add a random 80ms latency to the response time of CSI to Reaper state changes. Of course you could spread out the update or prioritize traffic to mitigate this.
Not saying this will be noticeable, I have no idea what the current latency of CSI is.

So, again, I am not saying this will be a big deal or not in real world scenarios, but it is stuff to take into account (if I did the math correctly).
You are correct on all points, my previous post was VERY rough math.

Another way to say this, along the lines of your approach -- 31.5 KBaud has sufficient bandwidth to update 2500 baud worth of traffic at about a .08 second refresh rate.

So a control surface with 75 or so controls can achieve about a .08 second refresh rate at 31.5 Kbaud, if every control on every pass is continuously refreshed.

So the takeaway is that we should be concerned, but not overly, and CSI should provide the ability to tune it on at least a per surface basis.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 03:15 PM   #2352
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
CSI doesn't hold state, nor should it, too easy to get out of synch.
Sorry for my unclear wording (again). Of course I did not mean that CSI holds the state itself, but if CSI stores the state into Reaper (via an action) and later retrieves it from Reaper (by whatever API means), this results in the same logic (regarding managing the lights) as if CSI would use some internal variable to hold that state.

-Michael
mschnell is offline   Reply With Quote
Old 01-16-2019, 03:27 PM   #2353
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by mschnell View Post
Sorry for my unclear wording (again). Of course I did not mean that CSI holds the state itself, but if CSI stores the state into Reaper (via an action) and later retrieves it from Reaper (by whatever API means), this results in the same logic (regarding managing the lights) as if CSI would use some internal variable to hold that state.

-Michael
Cool, got it, yes, as far as the lights, CSI behaves logically as if it stores state.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 03:40 PM   #2354
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Hmmm...

Thinking about this a bit more, perhaps we just repurpose the existing syntax, PressFBR will now mean Press with FeedBack and Refresh:

SomeButton PressFBR 0.1 90 4a 7f 90 4a 00

Notice the new parameter 0.1.

That is the requested update frequency for this widget in seconds.

0 seconds means continuous update.

Any of the "R" family (e.g. PressFBR) will require this.

Very simple and it gives us per widget control.
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 01-16-2019, 05:07 PM   #2355
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post
Very simple and it gives us per widget control.
Genius! I like it! 👍😃
dixo is offline   Reply With Quote
Old 01-17-2019, 02:01 AM   #2356
Travesty
Human being with feelings
 
Travesty's Avatar
 
Join Date: Nov 2014
Posts: 567
Default

Nice!
Travesty is offline   Reply With Quote
Old 01-17-2019, 06:07 AM   #2357
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

In fact using completely separate "buttons" for the press and the "release" case is problematic, as with the "weird" surface button implementation just discussed, the state changed by press might be necessary to be sent to the surface when release is detected.

Quote:
Originally Posted by Geoff Waddington View Post
I still don't understand you I guess....
It seems that I often fail to express my thought in a way that matches your's

The cause might be that I usually start a task not by considering how I can get the work done, but by trying to analyze the issue in question and looking for related stuff that might be handled with the same project without too much effort.

So let me phrase my point in a different way.

If I were to start my own "CSI extension" project right now, but of course building on all the great stuff I learned from the work you did on yours, I would try to follow a similar structure as you do, allowing the users to write definition files for any Surface device they want to attach and definition files for any workflow they want to control by the surface devices. Of course the Surface definition files will define actions to be sent to the workflow definition files, and the "surface handler" will need do request and be sent "Workflow State" information by the "Workflow Handler". As you recently stated, theses states will (usually) be "DAW states" and stored in the DAW itself.

Regarding the Button definition I would start by defining a universal button (which later should only be used by experts, and only when no predefined dedicated button definition is available).

Once this works, I would define easy to use dedicated Button keywords, as shortcuts for certain lengthly universal definition, as they seem to make sense.

So I would collect list what should be definable for a "Universal Button".

Of course I would need a message that we will receive when the button is pressed and another one we will receive when the button is released.

The actions to send to the Workflow handler when push and receive are detected both need to be defined. Now the workflow handler can decide what to do with them. Usually it will modify a state (either an internal CSI state or a state in he DAW).

Now the messages to send to the Surface need to be defined. I would allow a list of multiple messages both for the press and the release case. The messages would be sent after the appropriate message has been received, and the messages are selected according to a "Workflow state" that can be requested from the "Wokflow Handler". In this universal case, I would allow for completely independent states to be used to select from a list of possible messages. Of course this can result in a horrible lengthly syntax, but this is only to be used if we would not provide a "shortcut" syntax, which would be very similar to what you offer in your project.

With this we can define a lot of usage cases and surface button implementation (some of which would be supported by appropriate shortcuts):

Simple press button to trigger some action. Optionally with a light that can be handled independently. E.g. [ PLAY ] (Of course the button definition allows for the Workflow handler to switch a button light if the button is not touched.)

Toggle button. E.g. [ MUTE ]

Set a state as long as the button is pressed. E.g. [ SCRUB ]

Restore the light state after release to handle "weird" surface implementations.

Abuse an incremental rotary as a pair of "up/down" buttons. E.g. "Bank Shift".

Allow the workflow handler to detect multiple simultaneously pressed buttons and provide appropriate behavior.

-Michael

Last edited by mschnell; 01-17-2019 at 06:17 AM.
mschnell is offline   Reply With Quote
Old 01-17-2019, 06:23 AM   #2358
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 9,698
Default

Quote:
Originally Posted by Geoff Waddington View Post
Hmmm...
A periodic refresh of course in any case is a great way to improve the reliability of the display !

-Michael

Last edited by mschnell; 01-18-2019 at 07:20 AM.
mschnell is offline   Reply With Quote
Old 01-17-2019, 06:46 AM   #2359
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 83
Default

Quote:
Originally Posted by Geoff Waddington View Post

0 seconds means continuous update.

Any of the "R" family (e.g. PressFBR) will require this.
Geoff, what exactly do you mean by "continuous update"? Do you mean: instantaneous update upon button press/release? Or a constant flow of updates at max rate?

And I was thinking, if you change the order of the parameters so that the refresh time is at the last position, and if you allow it to be omitted (meaning: no periodic refresh required), the PressFB syntax could handle all cases with a single keyword. No need for the "R" family, but it may complicate your parser.

"Normal" button with feedback, no periodic refresh:
Code:
SomeButton PressFB 90 4a 7f 90 4a 00
Button with feedback and refresh @ 100ms:
Code:
SomeButton PressFB 90 4a 7f 90 4a 00 0.1

Last edited by dixo; 01-17-2019 at 08:30 AM.
dixo is offline   Reply With Quote
Old 01-17-2019, 10:32 AM   #2360
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,216
Default

Quote:
Originally Posted by dixo View Post
Geoff, what exactly do you mean by "continuous update"? Do you mean: instantaneous update upon button press/release? Or a constant flow of updates at max rate?
Constant flow at max rate.

You can think of it this way, 0 represents a time lapse of 0 seconds between updates, in other words flat out -- as fast as the system can provide.


Quote:
Originally Posted by dixo View Post
And I was thinking, if you change the order of the parameters so that the refresh time is at the last position, and if you allow it to be omitted (meaning: no periodic refresh required), the PressFB syntax could handle all cases with a single keyword. No need for the "R" family, but it may complicate your parser.

"Normal" button with feedback, no periodic refresh:
Code:
SomeButton PressFB 90 4a 7f 90 4a 00
Button with feedback and refresh @ 100ms:
Code:
SomeButton PressFB 90 4a 7f 90 4a 00 0.1
Fabulous idea, done !!
__________________
Beta software https://stash.reaper.fm/v/38349/CSI%20beta.zip Donate GeoffWaddington.ca
Installation / documentation / source https://github.com/GeoffAWaddington/...ntegrator/wiki
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 01:29 AM.


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