Old 04-20-2014, 03:33 PM   #1
N2NPro
Human being with feelings
 
Join Date: Aug 2013
Location: SD Cali
Posts: 112
Default OSC bug reports

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.

During our experience from testing-working model, he/we uncovered a few OSC bugs that need to be reported:
Originally posted here: http://forum.cockos.com/showthread.p...39#post1339639
and here: http://forum.cockos.com/project.php?issueid=5172

The following threads are 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
N2NPro is offline   Reply With Quote
Old 04-20-2014, 03:35 PM   #2
N2NPro
Human being with feelings
 
Join Date: Aug 2013
Location: SD Cali
Posts: 112
Default BUG #2 Keyboard commands do not work in combination with device.

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
N2NPro is offline   Reply With Quote
Old 04-20-2014, 03:36 PM   #3
N2NPro
Human being with feelings
 
Join Date: Aug 2013
Location: SD Cali
Posts: 112
Default BUG #3 Reaper OSC sending redundant messages

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
N2NPro is offline   Reply With Quote
Old 04-20-2014, 03:37 PM   #4
N2NPro
Human being with feelings
 
Join Date: Aug 2013
Location: SD Cali
Posts: 112
Default BUG #4 OSC -> Reaper Action Cmd ID issues.

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
N2NPro is offline   Reply With Quote
Old 04-20-2014, 03:38 PM   #5
N2NPro
Human being with feelings
 
Join Date: Aug 2013
Location: SD Cali
Posts: 112
Default BUG #5 Scrub feature support acceleration?

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
N2NPro 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:44 AM.


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