Old 03-06-2014, 09:18 PM   #1
Sid Chip
Human being with feelings
 
Sid Chip's Avatar
 
Join Date: Sep 2007
Posts: 180
Default Reaper OSC

I've been working with Reaper OSC interface for the past week, after only finding out about it a week ago.

I wanted to implement a HUI and I thought to myself "I bet Reaper implemented some sort of open method of control surfaces" - Checked and BAM -OSC-. Send commands via UDP instead of looping MIDI hacked Mackie HUI back? SOLID. I'm interfacing with another open implementation called SharpOSC so I didn't even have to write a parser!

Just wanted to say a big thanks for OSC implementation! And a huge thumbs up. I haven't had this much fun coding in a long time. Just adding new features and features. After I get basic control functionality in and I start to think "Hmm, I wonder if I can get reaper to do.... this?" The /action/# command comes to the rescue. The latest being /action/41743 (refresh control surfaces) when I restart my wedge app it refreshes my control surface.

I wish I had have read the comments in the default ReaperOSC. I started out worrying about maintaining virtual fader<>track ID's but /bankswitch with proper DEVICE_TRACK_COUNT configured, takes care of this for me!

Rock on,
Sid
Sid Chip is offline   Reply With Quote
Old 03-07-2014, 06:57 AM   #2
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

You're lucky that you're late to the party, pal. I remember nagging schwa on IRC like five years ago for OSC support in REAPER, when he replied (paraphrasing): but... why? If it's supposed to be something like MIDI, then is there even *any* synth or controller out there that supports it? And tbh, the answer to that question *still* is quite a hard one...

So yeah, I totally agree, big thanks, rock on, thumbs up for the Cockos devs!! <3

PS: I guess we should also be thankful that Justin apparently had some crappy old hardware.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-07-2014, 09:40 AM   #3
EcBaPr
Human being with feelings
 
Join Date: Aug 2009
Location: Sydney
Posts: 147
Default

im noticing OSC in more and more devices now.. i think the growth in tablets and apps like touchOSC and Lemur is directing manufacturers to implement it their devices a lot more.. most newer digital consoles have OSC..

would be good to see more support for it in reaper.. to easily create OSC commands on JS faders which can run seperate from the wildcard naming in the config file.. load dummy faders, right click and type an OSC command you want.. nice and easy..
EcBaPr is online now   Reply With Quote
Old 03-07-2014, 10:58 AM   #4
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by EcBaPr View Post
im noticing OSC in more and more devices now.. i think the growth in tablets and apps like touchOSC and Lemur is directing manufacturers to implement it their devices a lot more.. most newer digital consoles have OSC..
Still, something like a simple keyboard that 'speaks' OSC is still kind of exotic. About as rare as one with USB only, without plain MIDI output, I guess. I suppose that allowing for infinitely flexible configuration more or less implies that all the important stuff will happen on the software side. Simple hardware that does not require any configuration and 'just works' out of the box is simply not an option anymore. But yeah, things have certainly been moving forward in the last years.
Quote:
Originally Posted by EcBaPr View Post
would be good to see more support for it in reaper.. to easily create OSC commands on JS faders which can run seperate from the wildcard naming in the config file.. load dummy faders, right click and type an OSC command you want.. nice and easy..
You can do that, sort of, by using MIDI Learn. You can't just type the desired address/command, but it's often easy enough to type that on the other end and send it. What's really missing there, is feedback. Simple tick boxes for send / receive / bidirectional in the MIDI Learn window, where are you? Right now, REAPER will only responding to incoming OSC messages for learned bindings, i.e. it does not provide feedback - same as for MIDI (and tbh, feedback for plain MIDI is probably much more useful for more people than for OSC).
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-07-2014, 12:10 PM   #5
EcBaPr
Human being with feelings
 
Join Date: Aug 2009
Location: Sydney
Posts: 147
Default

Quote:
Originally Posted by Banned View Post
You can do that, sort of, by using MIDI Learn. You can't just type the desired address/command, but it's often easy enough to type that on the other end and send it. What's really missing there, is feedback. Simple tick boxes for send / receive / bidirectional in the MIDI Learn window, where are you? Right now, REAPER will only responding to incoming OSC messages for learned bindings, i.e. it does not provide feedback - same as for MIDI (and tbh, feedback for plain MIDI is probably much more useful for more people than for OSC).

I have been trying to use Reaper in reverse, to send OSC and control other devices. my goals been to use the timeline to automate RME TotalmixFx with envelopes etc.. The problem i hit is reaper config files are all wildcard naming.. I know that makes sense to syncronise a large control surface to control reaper, but if you just want a couple of dummy fader on arbituary tracks to send specific OSC commands i dont think you can isolate those faders from the wildcard naming..

For instance i was trying to find a way to send /ReverbReturn and /MainMuteFx from a JS fader.. totalmix doesnt have anyway to make config files like reaper with its OSC commands so there is no way i could see to make a dummy fader send /MainMuteFx while other reaper FX maintained the normal naming system..

I saw the midi learn but it seemed to only work as input to control reaper and didnt send the learnt command back to the device.. Is that what you mean by feedback ? If so i would love to see this included also.
EcBaPr is online now   Reply With Quote
Old 03-07-2014, 03:15 PM   #6
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by EcBaPr View Post
I have been trying to use Reaper in reverse, to send OSC and control other devices. my goals been to use the timeline to automate RME TotalmixFx with envelopes etc.. The problem i hit is reaper config files are all wildcard naming.. I know that makes sense to syncronise a large control surface to control reaper, but if you just want a couple of dummy fader on arbituary tracks to send specific OSC commands i dont think you can isolate those faders from the wildcard naming..

For instance i was trying to find a way to send /ReverbReturn and /MainMuteFx from a JS fader.. totalmix doesnt have anyway to make config files like reaper with its OSC commands so there is no way i could see to make a dummy fader send /MainMuteFx while other reaper FX maintained the normal naming system..
Hmm, iirc I solved a very similar issue by simply using multiple OSC control surface configurations; a 'general' one using the wildcards, and then another for each dummy JS.
Quote:
Originally Posted by EcBaPr View Post
I saw the midi learn but it seemed to only work as input to control reaper and didnt send the learnt command back to the device.. Is that what you mean by feedback ? If so i would love to see this included also.
Yeah, that's exactly what I meant. The MIDI/OSC Learn approach (currently) seems to assume that you want to control REAPER remotely, while the 'control surface' approach seems to be intended for bidirectional control messaging (although it may not be very clear as to what functionality is supported in which direction). Between the very different sort of use cases that are possible with OSC (like, using REAPER to control something else and/or using something else to control REAPER), it may be hard to find a adequate solution for many of our needs and desires.

I think we need to think and discuss a bit more about what exactly is missing, so we can put up some appropriate FRs. I would guess the main problems with having REAPER respond to and/or send parameter changes using some automagically configured human-readable format, e.g. "FX_PARAM_VALUE n/{track name}/{effect name}/{parameter name}/" are:

(1) track / effect / parameter names are not guaranteed to be unique in any way; and

(2) how to prevent 'flooding': it may not be desirable to have REAPER send OSC messages for *every* parameter on every plug-in on every track.

Problem (1) could perhaps be solved by using the track / slot / parameter numbers as prefixes, e.g. "FX_PARAM_VALUE n/{@track name}/{@effect name}/{@parameter name}/".

And of course problem (2) explains why the OSC 'control surface' approach uses the concept of *banks*, i.e. *limited* numbers of *adjacent* tracks / effect slots / effect parameters.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-07-2014, 09:12 PM   #7
Sid Chip
Human being with feelings
 
Sid Chip's Avatar
 
Join Date: Sep 2007
Posts: 180
Default

Quote:
Originally Posted by Banned View Post
...
And of course problem (2) explains why the OSC 'control surface' approach uses the concept of *banks*, i.e. *limited* numbers of *adjacent* tracks / effect slots / effect parameters.

Oooo, lets not change the banks methodology! I had implemented a lot of shi..err code to keep track of where I was originally, and thankfully it was for naught, as reaper presented to me as 1-24 regardless of bank. Much more elegant solution for a controller interface IMHO.

I suppose you could just set DEVICE_TRACK_COUNT to something like 999 for a "flat" setup and (I should hope!) you'd never have to worry about that But oh the flooding I'm sure..
Quote:
Originally Posted by Banned View Post
PS: I guess we should also be thankful that Justin apparently had some crappy old hardware.
That post from Justin is Nov 2013...curious just how new is OSC to reaper? I've been using reaper for like 6 years, and I've only ever connected a borrowed BCF2000 to it like 4 years ago via HUI.

Sid.
Sid Chip is offline   Reply With Quote
Old 03-07-2014, 11:33 PM   #8
EcBaPr
Human being with feelings
 
Join Date: Aug 2009
Location: Sydney
Posts: 147
Default

Quote:
Originally Posted by Banned View Post

Yeah, that's exactly what I meant. The MIDI/OSC Learn approach (currently) seems to assume that you want to control REAPER remotely, while the 'control surface' approach seems to be intended for bidirectional control messaging (although it may not be very clear as to what functionality is supported in which direction). Between the very different sort of use cases that are possible with OSC (like, using REAPER to control something else and/or using something else to control REAPER), it may be hard to find a adequate solution for many of our needs and desires.
Yeah i see what you mean.. In terms of under the hood logistrics im pretty green on how to achieve it, but that idea of just assigning OSC commands to a dummy fader that worked both in/out would be great. I would imagine a fader assignment like that should include an option to be excluded from the rest of the control surface naming heirachy also, otherwise it might have the potential to control two things at once ?

ie: you have dummy fader on track 8, FX slot 1, parameter 1 sending a value to a lighting rig but you also have a digital console setup for some automation.. you wouldnt want the track 8 fader to be changing FX on track 8 of the console also.. If midi/OSC learn had feedback it would be good to have an option to be able to exclude it from the surface setup to avoid that..

I'm really a novice when it comes to this stuff, but im hopeful to see some more versatility with these features..
EcBaPr is online now   Reply With Quote
Old 03-08-2014, 09:31 AM   #9
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by Sid Chip View Post
Oooo, lets not change the banks methodology! I had implemented a lot of shi..err code to keep track of where I was originally, and thankfully it was for naught, as reaper presented to me as 1-24 regardless of bank. Much more elegant solution for a controller interface IMHO.

I suppose you could just set DEVICE_TRACK_COUNT to something like 999 for a "flat" setup and (I should hope!) you'd never have to worry about that But oh the flooding I'm sure..

That post from Justin is Nov 2013...curious just how new is OSC to reaper? I've been using reaper for like 6 years, and I've only ever connected a borrowed BCF2000 to it like 4 years ago via HUI.

Sid.
Yeah, exactly, just set the track / slot / parameter counts to something really high if you want REAPER to just send 'everything' (never mind plug-ins with zillions of parameters... looking at you, REAKTOR!).

OSC support was first implemented in REAPER since v4.20 (and its associated pre-cycle), about two years ago. Justin's more recent post isn't so much about REAPER directly (but about osciibot), but it does show that he has started to use OSC himself - which can only mean good things, imho. In any case, we won't have to explain anymore what OSC could possibly be useful for.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-08-2014, 09:55 AM   #10
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by EcBaPr View Post
Yeah i see what you mean.. In terms of under the hood logistrics im pretty green on how to achieve it, but that idea of just assigning OSC commands to a dummy fader that worked both in/out would be great. I would imagine a fader assignment like that should include an option to be excluded from the rest of the control surface naming heirachy also, otherwise it might have the potential to control two things at once ?

ie: you have dummy fader on track 8, FX slot 1, parameter 1 sending a value to a lighting rig but you also have a digital console setup for some automation.. you wouldnt want the track 8 fader to be changing FX on track 8 of the console also.. If midi/OSC learn had feedback it would be good to have an option to be able to exclude it from the surface setup to avoid that..

I'm really a novice when it comes to this stuff, but im hopeful to see some more versatility with these features..
Yeah, with the control surface approach, you always have to be aware of the fact that multiple 'clients' (control surfaces, REAPER's GUI, MIDI devices, etc.) can be controlling the same parameter simultaneously. There is currently no mechanism for (mutually) excluding parameters from control, afaik.

There are lots of corner cases that may complicate things. For example, what should happen when you insert a track before track 8, so track 8 become track 9 (or you insert another effect and change the order, so the slot number changes)? Should the bindings persist? And what should happen when you duplicate the track/effect to another location?
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-09-2014, 09:17 AM   #11
EcBaPr
Human being with feelings
 
Join Date: Aug 2009
Location: Sydney
Posts: 147
Default

if you insert a track i think binding should move to next track and stay with the fader, same with FX.. if you copy the effect i would have the binding on both unless that would cause problems ?? im not sure i can see how that stuff could be problematic though ?
EcBaPr is online now   Reply With Quote
Old 03-10-2014, 09:49 AM   #12
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by EcBaPr View Post
if you insert a track i think binding should move to next track and stay with the fader, same with FX.. if you copy the effect i would have the binding on both unless that would cause problems ?? im not sure i can see how that stuff could be problematic though ?
Well, let's see: after copying the effect, you could edit the parameter automation envelopes in REAPER for the parameters using *different* faders using bindings with the *same* OSC address/message. So, you could have two envelopes with a different shape.

That's not a problem in itself, but it becomes one when we want to add parameter feedback for the bindings, because that implies we would be sending *different* values to the *same* parameter at the *same* time.

Alternatively, if the envelopes would still remain exactly the same shape, we would be attempting to send duplicate, thus redundant values. That is very inefficient, problematic (in terms of network traffic), and possibly confusing - so REAPER would have to filter the 'flood'.

You see where this is going? For many relatively simple purposes, it may be hard to see why it doesn't just work out of the box - until you start looking at more complicated use cases. And, of course, we would ideally want to have REAPER's functionality accommodate as many use cases as possible. Which is why we may have to think hard about what exactly we want.

(Of course, this problem also arises when using MIDI bindings. Which is probably one of the reasons why feedback for MIDI bindings is not yet implemented in REAPER either.)
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-10-2014, 12:45 PM   #13
EcBaPr
Human being with feelings
 
Join Date: Aug 2009
Location: Sydney
Posts: 147
Default

In terms of duplicating tracks with the same bindings and device feedback.. the only (sensible) options i can see is either create a heirachy where one takes priority or sum them all before feedback.. A heirachy makes more sense to me though..

By default I think the first track created with each unique binding be priority 1.. If the track is duplicated the next track becomes priority 2 etc.. Have an overview window so you can see where all bindings exist in the project for each command and if there are duplicates provide a way of ordering them.. If there were 2 tracks with the same binding and priority 1 is muted, priority 2 becomes enabled etc.

Alternatively you could sum everything that isnt muted but i think that could become messy.. How are midi cc's handled if there are two or more tracks sending on the same channel with different automation ?
EcBaPr is online now   Reply With Quote
Old 03-11-2014, 05:59 AM   #14
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,334
Default

Quote:
Originally Posted by EcBaPr View Post
same with FX.. if you copy the effect i would have the binding on both unless that would cause problems ?? im not sure i can see how that stuff could be problematic though ?
When you copy/paste an effect or duplicate a track any "learned" OSC bindings are also applied to the copy. If you copy to a different track it may appear as though the bindings are not working if the previous track is still selected. If you want the FX on both tracks to react you will have to select both tracks.
Anton9 is offline   Reply With Quote
Old 03-11-2014, 09:51 AM   #15
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by EcBaPr View Post
In terms of duplicating tracks with the same bindings and device feedback.. the only (sensible) options i can see is either create a heirachy where one takes priority or sum them all before feedback.. A heirachy makes more sense to me though..

By default I think the first track created with each unique binding be priority 1.. If the track is duplicated the next track becomes priority 2 etc.. Have an overview window so you can see where all bindings exist in the project for each command and if there are duplicates provide a way of ordering them.. If there were 2 tracks with the same binding and priority 1 is muted, priority 2 becomes enabled etc.

Alternatively you could sum everything that isnt muted but i think that could become messy.. How are midi cc's handled if there are two or more tracks sending on the same channel with different automation ?
Exactly, it becomes messy and complicated. It wouldn't work properly, unless there would be a mechanism to resolve duplicate or conflicting bindings / messages. So this would require more functionality than just sending out a bunch of messages, which was exactly my point. (An overview window for all 'learned' bindings would be very handy even without adding feedback, btw.)

With MIDI, afaik, you're completely free to make things a complete and utter mess: if you want to send different values to the same CC# on the same channel (almost) simultaneously, nothing stops you from doing so. (And, again, such complications may well explain why feedback for learned MIDI or OSC bindings has not been implemented yet.)
Quote:
Originally Posted by Anton9 View Post
When you copy/paste an effect or duplicate a track any "learned" OSC bindings are also applied to the copy. If you copy to a different track it may appear as though the bindings are not working if the previous track is still selected. If you want the FX on both tracks to react you will have to select both tracks.
Oh, that's good to know! I don't use the 'learned' bindings much, as I typically want to have proper feedback, I tend to use the 'control surface' approach.

In any case, just to be clear: I was trying to explain the complications of the (still) *hypothetical* case where feedback would somehow have been implemented for 'learned' bindings, not the complications of the current functionality. But of course, we should discuss such issues as well when we're talking about possible improvements.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-11-2014, 02:10 PM   #16
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,334
Default

Quote:
Originally Posted by Banned View Post
I tend to use the 'control surface' approach.
As another side note, maybe you already knew this.., but you can also control multiple parameters using one message when using the 'control surface' approach. Depending on the capabilities of the sending device you can send something like this "/track/1,2/fx/1,1/fxparam/3/value", 0.3,0.3
In that example the fx in slot 1 of both track 1 and 2 will have parameter 3 set to 0.3.
Anton9 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 02:50 AM.


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