Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

OSC bug report Issue Tools
issueid=5172 04-19-2014 09:37 AM
Human being with feelings
OSC bug report
OSC and OSCII-bot Bi-directional CS

Hi Fellow Reaper's,
I am new to the forum and have been initiated by an amazing member named "Banned". Amazing isn't really appropriate, he deserves much more, but as he is a humble individual, I will not embarrass him with further praise, though definitely warranted.

Banned wrote an OSCII-bot.text file that brought my ancient though completely functional Peavey StudioMix (motorized controller for Cakewalk ProAudio-Sonar) back to life. The StudioMix is NRPN based and Banned wrote code to translate NRPN to OSC and OSC translated back to NRPN, thus having bi-directional control via OSC. The thread is here if interested -> http://forum.cockos.com/showthread.php?t=137558.
During our experience from testing-working model, he/we uncovered a few OSC bugs that need to be reported:
**EDIT**
Quote:
Originally Posted by N2NPro
[...] Banned wrote code to translate NRPN to OSC [...]
Quote:
Originally Posted by Banned
For proper credit, I should clarify that this specific part was written by JeffOS - I piggybacked on his generic 'translate ALL incoming MIDI to generic OSC messages' script, and adapted it to pick out the specific MIDI messages that your device happens to use, and then started adding specific functions.
EDIT:4-20-2014
The modified individual list starts here: http://forum.cockos.com/project.php?...uenoteid=20519

1. Master Fader affecting other tracks:
Quote:
Originally Posted by Banned
- As for the master fader affecting track 8, 16, etc. after switching the track bank: you found a bug in REAPER, haha! I double-checked, and this is simply how REAPER responds when you set the volume for track 0. Fixed in the script by using a dedicated OSC message for master track volume. Should still be reported as bug nevertheless.
2. DEVICE_TRACK_FOLLOWS LAST_TOUCHED ReaperOSC config file
Quote:
Originally Posted by Banned View Post
Indeed, it seems we found another one. With this setting in the .ReaperOSC config file:
Code:
DEVICE_TRACK_FOLLOWS LAST_TOUCHED
... and using this 'OSC action description' (as we do, and which is also part of the default configuration):
Code:
MASTER_VOLUME n/master/volume
... REAPER stops sending out OSC messages for the master track volume after selecting another track (which includes touching any control *except* for the volume faders on another track) - until the master track is selected again (which includes touching any parameter *except* for the volume fader on the master track, such as pan, mute, or solo). This seems to be a bug / unexpected behavior, because touching a volume fader *should* count as 'last touched'.
3. When selecting tracks via device the ctrl, shift hotkeys do not work in combination.
Quote:
Originally Posted by Banned View Post
I'm not sure if that is actually supposed to work - but arguably, it should. It seems that we'd need to report it as a bug / feature request to Cockos.
4. We have logged Reaper continuing to send messages post execution of various tasks (ex: arm/unarm) that affect fader movement in the device.

Originally Posted by jico27 View Post
Can't we stop them at the output of reaper in this case?
Quote:
Originally Posted by Banned View Post
No, I'm afraid not. As you can see, these are simply volume messages. We have no idea of knowing whether they are related to track (un)arming. It's REAPER's job to minimize the amount of redundant messages (and as such, you may consider creating a bug report for this), but in doing so, it should of course err on the side of sending too much (i.e. redundant) messages rather than sending too few (in which case, the remote device would be out of sync because it did not receive the most recent value for all parameters).
These are a few that we encountered and verified. If anyone one else has had similar results or has info regarding these bugs, please come forward.

My experience in this forum has been an absolute blessing. I am so impressed by it's members, their courtesy, knowledge and generosity are unsurpassed! Thank you, and good luck to all.

N2N
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Audio recording and playback
Status Fixed
Priority 2
Affected Version 4.61
Closed Version 4.75
Yes votes 1
No votes 0
Assigned Users (none)
Tags (none)

04-19-2014 10:22 AM
Human being with feelings
 
I can add this:

5: OSC doesn't take into account which tracks that are hidden in MCP.
Reply
04-20-2014 02:16 PM
Human being with feelings
 
Hi Guys,
It has been brought to my attention that my report was too vague and that I should identify each bug individually.

Here is the individual list of the OSC bugs experienced:

BUG #1 Master Fader and Mute affecting other tracks:


Quote:
Originally Posted by N2NPro
During our experience from testing-working model, he/we uncovered a few OSC bugs that need to be reported:

1. Master Fader and Mute affecting other tracks: [...]
When sending OSC messages to REAPER (using a similar config to the default one) like this:
Code:
/track/0/volume [f] [value 0.0-1.0]
Quote:
Originally Posted by Banned
... REAPER changes the volume of the master track, IF the selected track bank is the first one. However, when another track bank is selected, REAPER targets (e.g., with track bank size = 8)
- track 8 when track bank = 2 (tracks 9-16);
- track 16 when track bank = 3 (tracks 17-24),
- etc.

REAPER does not seem to send feedback to the device for /track/0/volume, either (although it does, as expected, for /master/volume ).

So it seems that we should either only use the dedicated OSC actions descriptions for the master track and get rid of the 'track 0' concept, OR ensure that it is used consistently and without bugs.
Special thanks to Banned for identifying the issue.

N2N
Reply
04-20-2014 02:42 PM
Human being with feelings
 
N2N OSC BUG LIST CONTINUED:

BUG #2 Keyboard commands do not work in combination with device.

Quote:
Originally Posted by N2NPro
When selecting tracks via device the ctrl, shift hotkeys do not work in combination.
Quote:
Originally Posted by Banned
I'm not sure if that is actually supposed to work - but arguably, it should. It seems that we'd need to report it as a bug / feature request to Cockos.]
Quote:
Originally Posted by Banned
To clarify: "selecting tracks via device" implies that this setting is used:
Code:
REAPER_TRACK_FOLLOWS DEVICE
Again, special thanks to Banned for identifying this issue.

N2N
Reply
04-20-2014 02:52 PM
Human being with feelings
 
N2N OSC BUG LIST CONTINUED:

BUG #3 Reaper OSC sending redundant messages


Quote:
Originally Posted by N2NPro
We have logged Reaper continuing to send messages post execution of various tasks (ex: arm/unarm) that affect fader movement in the device. [...]
Quote:
Originally Posted by Banned
To clarify: I think we have only seen some *redundant* messages (e.g. track volume) from REAPER when (un)arming tracks.

Insofar these messages "affect fader movement in the device", that is probably exclusively the result of behavior specific to the device (it seems to be reporting back the positions of its motorized faders, which may differ from the values it has received) and how our script attempts to handle the associated issues. So this seems to be a (minor) general 'flooding' optimization issue.
Special thanks to Banned for identifying this issue.


N2N
Reply
04-20-2014 02:58 PM
Human being with feelings
 
N2N OSC BUG LIST CONTINUED:

BUG #4 OSC -> Reaper Action Cmd ID issues.

Quote:
Originally Posted by Banned
We've also found that triggering some actions using their 'regular' ID doesn't seem to work for *some* users (it works for me, but not for the two others who have tested it so far, namely N2NPro and jico27). In particular, this goes for:
- 'Track: Toggle mute for selected tracks' (Cmd ID = 6)
- 'Track: Toggle solo for selected tracks' (Cmd ID = 7)
- 'Track: Toggle mute master track' (Cmd ID = 14)
When sending an OSC message such as
Code:
/action [i] 6
Quote:
Originally Posted by Banned
... REAPER does not respond as expected.

Notably, when using the same OSC action description for other actions (e.g. undo/redo, transport functions, Cmd IDs such as 40029, 40030, 40042, 40043) they *do* work. For now, we can aliased custom actions as workaround, but it would be nice to find out why the 'regular' actions don't work in some cases. Has anyone else seen this problem?

(Fwiw, the main difference I can think of between their setup and mine, is that I'm on OS X, and they're both on Window.)
Again, special thanks to Banned for identifying this issue.

N2N
Reply
04-20-2014 03:07 PM
Human being with feelings
 
N2N OSC BUG LIST CONTINUED:

BUG #5 Scrub feature support acceleration?

Quote:
Originally Posted by Banned
Another thing we've found, is that the 'scrub' feature / action description does not seem to support 'relative' messages with acceleration.
Quote:
Originally Posted by Default.ReaperOSC
Default.ReaperOSC
# r: rotary. The device triggers the action in the forward direction when sent
# with an argument greater than ROTARY_CENTER, and in the reverse direction when
# sent with an argument less than ROTARY_CENTER. For some messages, the magnitude
# of the argument affects the rate of change. REAPER does not send feedback for
# these messages.

# Example: SCRUB r/scrub
# The device sends /scrub 1 to scrub forward, and /scrub -1 to scrub in reverse
# (if ROTARY_CENTER is 0).
Quote:
Originally Posted by Banned
For example, I'm seeing the same result for these messages:
Code:
/scrub [f] 0.01
/scrub [f] 0.5
/scrub [f] 1
/scrub [f] 5
Quote:
Originally Posted by Banned
If this is correct, could this "magnitude of the argument affects the rate of change" thing please be added for scrubbing?
Please advise.....

Thanks go out to Banned for identifying this issue/request.

N2N
Reply
10-21-2014 01:26 AM
Mortal
 
Thanks for the detailed report N2NPro [EDIT: and Banned!]. However it'd help to report bugs/feature requests separately: we'll probably mark this issue as "fixed" since #1 and #2 were indeed bugs that should be fixed in v4.74pre4+, and because #3 and #4 are more like feature requests... But feel free to submit them again (as "feature requests", with discussion threads ^^), of course!
Reply
10-26-2014 11:09 AM
Human being with feelings
 
Hi Jeffos,
Thank you so much! Banned did so much work on this project. It's nice to see changes due to his efforts. I will add #3,4 to the feature request list.
Kindly,

dedicated reaper
N2N
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 01:51 AM.


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