Old 03-01-2012, 05:02 PM   #321
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Quote:
Originally Posted by Banned View Post
I also tried using the Learn dialog and actions list, but still didn't see how to send values to the action.
If you're trying to set FX parameters by binding to something like "Adjust track FX parameter 01(MIDI CC/OSC only)" then what you need to do is make sure you click on the Param button at the top of the FX dialog and select "Show in track controls" then it should work.

If you're just wanting to execute an action.., most of them don't take values.., you just need to send the message. For example if you learn/bind using this message /ummagumma then you just send that same message each time you want to execute the action.

Last edited by Anton9; 03-01-2012 at 05:14 PM.
Anton9 is offline   Reply With Quote
Old 03-01-2012, 05:46 PM   #322
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 Anton9 View Post
If you're trying to set FX parameters by binding to something like "Adjust track FX parameter 01(MIDI CC/OSC only)" then what you need to do is make sure you click on the Param button at the top of the FX dialog and select "Show in track controls" then it should work.[...]
Well, that's how I got them to appear there as Track FX parameters. And I can set/get them just fine under their own name; but not as Track FX parameters using actions (also, when I use the Learn window from the TCP controls, it targets the plugin parameter directly under its own name) - when selecting a different track (with a different set of parameters as its Track FX parameters), the same control source sending the same OSC message to the same action should now target the Track FX parameters of the newly selected track, and not the parameters which happened to be the Track FX parameters of the previously selected track.

So my 'problem' (I'm just testing if this works; it would not generate feedback anyway) is simply that I can't get "Adjust track FX parameter 01(MIDI CC/OSC only)" to bind to an OSC message which includes an argument. But this set of actions simply needs to be provided an argument to do anything useful, but then it doesn't seem to listen when I give it one. So either I'm using the wrong pattern, or it doesn't work.

Have you successfully executed any actions taking arguments via OSC? (If so, what does the message look like?)
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ

Last edited by Banned; 03-01-2012 at 06:02 PM.
Banned is offline   Reply With Quote
Old 03-01-2012, 06:06 PM   #323
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Quote:
Originally Posted by Banned View Post
Have you successfully executed any actions taking arguments via OSC? (If so, what does the message look like?)
Sending to "Adjust track FX parameter 01(MIDI CC/OSC only)" with the parameters control visible on the TCP using GlovePIE Example: SendOsc(127.0.0.1,8000,"/ummagumma", 0.5)

However I did find a bug.., when sending a value of 1.0 it doesn't set the parameters value to the max.., it falls sort by just a little bit.
Anton9 is offline   Reply With Quote
Old 03-01-2012, 06:10 PM   #324
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default Bug

When sending a value of 1.0 to the "Adjust track FX parameter nn (MIDI CC/OSC only)" actions it does not set the parameters value to max. It falls short by just a little bit.
Anton9 is offline   Reply With Quote
Old 03-01-2012, 06:12 PM   #325
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Binding OSC messages to continuous actions seems to be working here. I opened the actions window, selected "adjust track FX parameter 01 (MIDI CC/OSC only)", clicked "add" shortcut, moved a control on the OSC device, and clicked OK. Now that control is linked to the track FX parameter knob (when the track is selected).
schwa is offline   Reply With Quote
Old 03-01-2012, 06:13 PM   #326
BenK-msx
Human being with feelings
 
BenK-msx's Avatar
 
Join Date: Jun 2008
Location: Whales, UK
Posts: 6,009
Default

potential bug with the last touch fx parameter,


i have these in my config

LAST_TOUCHED_FX_PARAM_VALUE /fxparam/last_touched/value
LAST_TOUCHED_FX_PARAM_VALUE_STRING /fxparam/last_touched/paramval


i can control last touched fx parameter independant of where it is, just fine - but feedback of the above data only occurs if the last touched fx is from the 1st fx of master track.

i'm aware .../name not working is a bug and due fixing,

tried a bunch of things so think its dodgy - or have i just not tried the right thing?
__________________
JS Super8 Looper Template & intro | BCF2000 uber info Thread | Who killed the Lounge?
BenK-msx is offline   Reply With Quote
Old 03-01-2012, 06:26 PM   #327
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 Anton9 View Post
Sending to "Adjust track FX parameter 01(MIDI CC/OSC only)" with the parameters control visible on the TCP using GlovePIE Example: SendOsc(127.0.0.1,8000,"/ummagumma", 0.5)
That is encouraging, I should give it another try then... (with that funky message, I assume you used the Learn feature to bind it to OSC ) Perhaps the trick is to avoid using the action number - using both integers and floats may be the issue somehow.
Quote:
Originally Posted by Anton9 View Post
However I did find a bug.., when sending a value of 1.0 it doesn't set the parameters value to the max.., it falls sort by just a little bit.
That may be a similar issue to what I had found when using Pure data with mrpeach's OSC externals; a value of exactly 1.0 (and 0.0) is sent as a integer, not as a float. For the time being, I made a pretty ugly hack that 'repairs' such malformed messages on the raw byte level at the client's end. If it is, no idea about how to do somthing similar for GlovePIE, since I haven't used it yet. It does look pretty awesome. (btw, have you ever heard of the late Michel Waisvisz (STEIM) and his 'Hands'?)
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-01-2012, 06:27 PM   #328
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 schwa View Post
Binding OSC messages to continuous actions seems to be working here. I opened the actions window, selected "adjust track FX parameter 01 (MIDI CC/OSC only)", clicked "add" shortcut, moved a control on the OSC device, and clicked OK. Now that control is linked to the track FX parameter knob (when the track is selected).
Ok, so I definitely did something wrong. What is the OSC message that the device was sending?
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-01-2012, 06:28 PM   #329
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Quote:
Originally Posted by schwa View Post
Binding OSC messages to continuous actions seems to be working here. I opened the actions window, selected "adjust track FX parameter 01 (MIDI CC/OSC only)", clicked "add" shortcut, moved a control on the OSC device, and clicked OK. Now that control is linked to the track FX parameter knob (when the track is selected).
The binding is working just fine.., it's just not sending the right values.., for example bind to the delay parameter of JS: Delay/delay_chorus and when you move or set the controller to 1.0 the delay parameter will read 3960.0 when it should be reading 4000.0.

Binding to actions of the MIDI editors is still not working.., although sending /midiaction/##### does work.
Anton9 is offline   Reply With Quote
Old 03-01-2012, 06:29 PM   #330
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Quote:
Originally Posted by Anton9 View Post
The binding is working just fine.., it's just not sending the right values.., for example bind to the delay parameter of JS: Delay/delay_chorus and when you move or set the controller to 1.0 the delay parameter will read 3960.0 when it should be reading 4000.0.
That's an old bug actually, and applies to CC and mousewheel bindings as well. Fixed, thanks for the report.
schwa is offline   Reply With Quote
Old 03-01-2012, 06:44 PM   #331
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Quote:
Originally Posted by Banned View Post
btw, have you ever heard of the late Michel Waisvisz (STEIM) and his 'Hands'?)
Yeah, his pioneering work with 'The Hands' was done way back in the 80s' I wish STEIM's software was available for Windows though.
Anton9 is offline   Reply With Quote
Old 03-01-2012, 07:26 PM   #332
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 Banned View Post
Ok, so I definitely did something wrong. [...]
Indeed, I now have it working too. No idea why it didn't before, but will keep an eye out for any possible issues if I can reproduce it again.

I'd still love to get feedback for those track FX values though.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-01-2012, 07:37 PM   #333
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 Anton9 View Post
Yeah, his pioneering work with 'The Hands' was done way back in the 80s' I wish STEIM's software was available for Windows though.
Or for Intel Macs even, in some cases... But it does run on my old hackint0sh. When I talked them about that, they said that anyone willing and able to help porting to Windows would be welcome, but they can't really offer much more than e.g. an intern position (for computer science students or such), since they'rea non-profit organization. As such, they always had to fight for their existence, currently more so than ever, in a political and economical climate with decreasing subsidies for the arts (especially the experimental/pioneering stuff). It's still an amazingly inspiring place nevertheless... and the non-profit price for beer is pretty awesome, too (so that's where the subsidies go, heh).

Apologies for wandering OT, STEIMs pioneering work deserved a little mention.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-02-2012, 04:46 AM   #334
pentecost
Human being with feelings
 
Join Date: Jan 2011
Posts: 91
Default

Is vu data only one-way, or can we also feed data (from the upcoming rme software, for example) into a dummy track to keep all metering in one place?
Seems like it would be a nice option if it doesn't already exist.
pentecost is offline   Reply With Quote
Old 03-02-2012, 05:37 AM   #335
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default Bug

Thank you for
# OSC: fixed binding OSC messages to MIDI editor actions

BUG:
I can't get the actions "Adjust track FX parameter 'nn' (MIDI CC/OSC only)" to work at all now with OSC through binding or by sending /action/@.

Last edited by Anton9; 03-02-2012 at 05:45 AM.
Anton9 is offline   Reply With Quote
Old 03-02-2012, 06:32 AM   #336
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default Attention all OSC geeks!!!

Are you ready for some real fun with TRACK_VU ?

Here is how to control an FX parameter using the Track VU:

Warning!!!: Follow instructions exactly and if by some freak of chance you still end up breaking something or losing some data don't blame me nor Cockos.

1: Add an FX to track 1 slot 1
2: Make a copy of the "default.ReaperOSC" file and rename it with something that does not start with "default".
3: Delete or comment out every line using # except "TRACK_VU" and "FX_PARAM_VALUE /track/@/fx/@/fxparam/@/value"
4: Add the pattern "/track/1/fx/1/fxparam/@/value" to the description line "TRACK_VU"..., substitute the @ with the parameter you want to control.

So now your ReaperOSC file should look something like this:
TRACK_VU /track/1/fx/1/fxparam/5/value
FX_PARAM_VALUE /track/@/fx/@/fxparam/@/value

5: Add the newly configured ReaperOSC to the "Control surfaces" dialog
6: On the "Control Surface Settings" dialog set the "Receive on port" and the "Send to port" to the same port.., Examp: 7000 and set the "Device IP:" to 127.0.0.1

7: Now for the fun part.., apply some audio to track 1 and watch the FX parameter that you assigned above react to the VU meter.
8: You can also adjust the settings in "Preferences/Appearance/VU Meters/Faders" to get it to react to a different range.

Enjoy

Last edited by Anton9; 03-02-2012 at 06:56 AM.
Anton9 is offline   Reply With Quote
Old 03-02-2012, 06:44 AM   #337
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default Request

Schwa,

This is in regards to my post titled "Attention all OSC geeks"
If you could add the ability for users to add descriptions to the ReaperOSC file such as TRACK_1_VU.., TRACK_2_VU.., etc.., which would send the VU's of each track then some real cool modulations could be accomplished using different/multiple audio sources.

What do think?

Thank you
Anton9 is offline   Reply With Quote
Old 03-02-2012, 09:46 AM   #338
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

Who can help me please?

my endless rotary control in TouchOSC spits out this "/endless [f] 0.000000" &
"/endless [f] 1.000000"

is there any way i can code this in to OSC "Action Rewind & Forward" :?: (for use as a Jog/Scrub Wheel)

i got some nice VU's in my TouchOSC template & a last touched parameter page

also PARAM_VALUE_STRING dose not feedback values when adjusting via OSC controller, moving with the mouse will show the string but if you move the osc controller then then it goes blank (i can post video if needed)

Subz

Last edited by Subz; 03-02-2012 at 10:36 AM.
Subz is online now   Reply With Quote
Old 03-02-2012, 10:27 AM   #339
diversgens
Human being with feelings
 
Join Date: Oct 2010
Location: France
Posts: 125
Default

Quote:
Originally Posted by Subz View Post

also PARAM_VALUE_STRING dose not feedback values when adjusting via OSC controller, moving with the mouse will show the string but if you move the osc controller then then it goes blank (i can post video if needed)

Subz
the same here on Lemur for FX_PARAM_VALUE_STRING
diversgens is offline   Reply With Quote
Old 03-02-2012, 10:35 AM   #340
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

Quote:
Originally Posted by diversgens View Post
the same here on Lemur for FX_PARAM_VALUE_STRING
Thanks!

FYI the strings for volume & pan are working fine its only on plugin parameters.

Subz
Subz is online now   Reply With Quote
Old 03-02-2012, 10:46 AM   #341
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

Quote:
Originally Posted by Subz View Post
FYI the strings for volume & pan are working fine its only on plugin parameters.

Subz

FYI2 if the plugin paramater is Wet/Dry Mix then it works so its only parameters from/to the VST GUI that play up,

PPS, Switching plugin to Native Reaper UI makes no difference

Subz
Subz is online now   Reply With Quote
Old 03-02-2012, 01:45 PM   #342
BenK-msx
Human being with feelings
 
BenK-msx's Avatar
 
Join Date: Jun 2008
Location: Whales, UK
Posts: 6,009
Default

re the encoder issue @subz - had no joy here on that too.

looks to me after a quick scan of the touchosc documentation that it's reaper that needs to be able to deal with these '1 clockwise, 0 anti-clockwise' msgs from touchosc and recognise they are acting as a relative encoder, in order to let us assign to things like jog/scrub etc.

not much we can do about it as yet.

seeing as cockos have touchosc running on a tablet/ipad (courtesy of their twitter video!) i encourage them to create an quick encoder and see how 'not usable' it is with reaper in its current form, to see what problem is - am sure its a relatively easy fix, maybe.
__________________
JS Super8 Looper Template & intro | BCF2000 uber info Thread | Who killed the Lounge?
BenK-msx is offline   Reply With Quote
Old 03-02-2012, 06:00 PM   #343
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

Thanks Ben

dose anyone think it would be worth adding a "TRACK_VU_PEAK_STRING" for Peak Readouts?

Subz
Subz is online now   Reply With Quote
Old 03-02-2012, 07:53 PM   #344
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

It's coming along

https://www.youtube.com/watch?v=vXMB-8fTzu8

MAIN PAGE (Transport & Volume/Pan VU)
[IMG]http://img35.**************/img35/5210/img00621.png[/IMG]


SENDS & FX
[IMG]http://img401.**************/img401/3197/img00581.png[/IMG]


JOG & LAST TOUCHED FX PARAMETER (& Master VU) [Jog not currently working]
[IMG]http://img703.**************/img703/4926/img00631.png[/IMG]


FOCUSED FX
[IMG]http://img708.**************/img708/5097/img00601t.png[/IMG]

Subz

Last edited by Subz; 03-02-2012 at 08:06 PM.
Subz is online now   Reply With Quote
Old 03-02-2012, 08:58 PM   #345
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

OSC support for Pan 2 does not seem to work correctly yet. When changing pan mode to dual or stereo pan, only the name and initial value / value string are sent, but no further value / value string updates are sent. REAPER also does not seem to respond to incoming messages targeted at the pan 2 value.

[EDIT:] With build 25, I'm seeing dropped OSC messages (path doesn't begin with /) immediately after the initial pan 2 value is sent (e.g. when changing track selection). I didn't see those in build 24 (still same results otherwise).
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ

Last edited by Banned; 03-03-2012 at 01:59 AM. Reason: added info on pre25
Banned is offline   Reply With Quote
Old 03-02-2012, 08:59 PM   #346
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Missing from the configuration file (but does work ):
Code:
NUM_RECEIVES 4 /numrecvs /numrecvs/@
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 07:05 AM   #347
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 Anton9 View Post
Schwa,

This is in regards to my post titled "Attention all OSC geeks"
If you could add the ability for users to add descriptions to the ReaperOSC file such as TRACK_1_VU.., TRACK_2_VU.., etc.., which would send the VU's of each track then some real cool modulations could be accomplished using different/multiple audio sources.

What do think?

Thank you
I think we need such an ability in general, not only for VU's. Especially for FX_PARAM_VALUE. The current banking and wildcard systems are (or should I say "were") very useful, but too restrictive by themselves (i.e. forced to use/step through adjacent tracks / plugin slots / plugin parameters / sends / receives). And using the Learn menu can quickly become a pita when you have to click in hundreds of different places (and no feedback, no joy). But I'm not sure we should use different actions descriptions (e.g. the all-caps bits) for each. We should rather be able to define different message patterns for the separate targets of actions with a @ wildcard. For example, with the existing patterns:
Code:
TRACK_VU /track/vu /track/@/vu
FX_PARAM_VALUE /fxparam/@/value /fx/@/fxparam/@/value /track/@/fx/@/fxparam/@/value
I'd like to be able to do something like:
Code:
~/track/1/vu = /bang/this/button
~/track/2/vu = /flick/that/switch
~/track/12/fx/1/fxparam/153/value = /turn/the/big/knob
~/track/3/fx/4/fxparam/3/value = /lights/out
in the configuration file (of course the syntax used here is a completely arbitrary example that I just made up).

I don't understand what I'm seeing currently in reaper-osc-actions.ini First off, I think defining OSC messages should really be concentrated in a single configuration file - as far as I can see, there are now two configuration files, which is quite confusing. Is this perhaps the start of OSC support outside of the realm of control surfaces?
By the looks of it, REAPER is treating its own strictly defined addresses as arbitrary messages:
Code:
"/action/950" 0 0 950
Why is /action/950 in quotes? Should it not rather be something like:
Code:
/action/950 0 0 "/perform/something/useful/1 [f]" ?
... that is only needed when one uses a different message than has already been defined in the OSC configuration file? I would think the second part of
Code:
ACTION /action /action/@
already told REAPER to listen to such messages. Or is the only relevant information in those two 0's?

With regard to cool modulations: that was my main reason for asking for better configurability of update rates (for example, I've been using dummy sliders in REAPER to automate parameters in Numerology, and have Numerology modulate parameters in REAPER, basically extending Numerology's virtual CV system into REAPER). Ideally we could differentiate between different update frequencies for different actions (for some, once every audio buffer is plenty, for others, you'd typically want to go much further towards audio rate). Tying the OSC update rate to once every audio buffer seems to make most sense as a default option. I'm also wondering how performance scales, how much overhead OSC flooding actually costs, how it compares to modulation using audio channels, DC / CV, etc. - all areas which require quite a bit more testing (which I'll certainly do ).

It is also the main reason that I really dislike pre 25 has drastically reduced the amount of feedback. Much less opportunity for cool modulations.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 07:11 AM   #348
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

When multiple tracks are selected, and a message such as
Code:
/track/mute 1
is sent, it only affects the 'active' track, and not (all) the selected track(s) (similar for /track/solo, /track/recarm, etc.). I think this is as a bug. Or is it perhaps by design (which would be weird: in REAPER multiple tracks can be muted, solo-ed, etc.; and tweaking volume / pan for multiple selected tracks does work as expected)?
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 07:39 AM   #349
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Quote:
Originally Posted by Banned View Post
I don't understand what I'm seeing currently in reaper-osc-actions.ini
The pattern config file maps OSC messages to specific control surface actions, using a simple wildcard system. Separately, any OSC message can be bound to a REAPER's action or FX learn systems, regardless of whether it has any mapping in the pattern config file (you would normally want to bind messages that don't already have a pattern mapping, to avoid collisions.)

Whatever message the device sends when the action shortcut or FX learn dialog is open, will be bound to that action or FX parameter. In your example it happened to be /action/950, which is confusing because that would already have triggered the same action via the default pattern config file. A more realistic example would be /trackfx/1.

In other words, you could skip the pattern config file entirely, not care about using the OSC device as a defined control surface, and instead just map messages to actions and FX learn the same way you could map an extended keyboard or any MIDI device. Or, you can have the device set up as a control surface, and additionally map controls to actions/FX learn at run-time (just as you would keyboard shortcuts) without having to reload the pattern config file.
schwa is offline   Reply With Quote
Old 03-03-2012, 07:41 AM   #350
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Quote:
Originally Posted by Banned View Post
With build 25, I'm seeing dropped OSC messages (path doesn't begin with /) immediately after the initial pan 2 value is sent (e.g. when changing track selection).
What specific messages are you seeing?
schwa is offline   Reply With Quote
Old 03-03-2012, 07:46 AM   #351
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

it seems TRACK_VOLUME_DB & TRACK_VOLUME_STRING show the same thing?

i was hoping TRACK_VOLUME_DB may give a peak reading for my VU meter but they both just put out the volume slider level?

Subz
Subz is online now   Reply With Quote
Old 03-03-2012, 09:25 AM   #352
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 schwa View Post
What specific messages are you seeing?
Pasted from Pure data console (emphasis added):
Code:
[...]
SC input: /track/4/name Track 12
OSC input: /track/4/number 12
OSC input: /track/4/volume 0.716
OSC input: /track/4/level 0.00dB
OSC input: /track/4/db 0.00
OSC input: /track/4/panmode 
OSC input: /track/4/pan2 0.5
unpackOSC: Path doesn't begin with "/", dropping message
OSC input: /track/4/pan 0.5
OSC input: /track/4/panval C
OSC input: /track/4/mute 1
OSC input: /track/4/mutetoggle 1
OSC input: /track/5/name Track 13

[...]
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 09:45 AM   #353
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 schwa View Post
[...] In other words, you could skip the pattern config file entirely, not care about using the OSC device as a defined control surface, and instead just map messages to actions and FX learn the same way you could map an extended keyboard or any MIDI device. Or, you can have the device set up as a control surface, and additionally map controls to actions/FX learn at run-time (just as you would keyboard shortcuts) without having to reload the pattern config file.
Thanks for the explanation. Indeed, OSC support outside of the realm of control surfaces.
I do think it is very confusing to use the term "actions" in both places (actions list as well as OSC control surface configuration) as the central concept. Perhaps call the OSC actions "behaviors" instead, or "patterns". Or whatever, as long as it's not "action."

Btw, the Learn feature should also be able to distinguish separate arguments of messages with multiple arguments. If you have e.g. a XY pad or accelerometer you need to be able to tell which of the multiple arguments you want to bind the action to.

I'd also like to see something like a checkbox in the Learn window to enable/disable feedback per individual action, which preference could then also be stored in the reaper-osc-actions.ini file.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 10:33 AM   #354
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

After reading the updated notes in the default OSC configuration file, I have a few comments:

The notes about TRACK_FOLLOWS and BANK_FOLLOWS do not mention that REAPER should follow the track/bank selected in the device. Without explanation, new users will likely be confused by the term "track follows" because they will see REAPER's track selection following the device and wrongly assume it's related to the TRACK_FOLLOWS setting (also see my earlier remarks here). Thus, it probably shouldn't do so by default (i.e. unless specifically told to do so, which we haven't yet). More so because it can't be disabled. Currently, even if all three TRACK_FOLLOWS, BANK_FOLLOWS, FX_FOLLOWS are set to DEVICE, REAPER is still following the control surface. Which makes it practically impossible to use a control surface in parallel with REAPER's GUI. When one uses multiple control surfaces, the skies will fall on our heads.

---

'Actions' should not be defined or categorized with direct reference to particular types of control elements. They may serve well as illustrative examples, but we have to be careful not to be more confusing than helpful. For example:
Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate buttons that do not latch, but have a light to indicate on/off.
It is not the action which emulates the behavior of a button (what does a button do then? A button can do anything...), but the control of that action. And for our purposes, there is no difference between a button and e.g. a switch. It should be described as a binary state, e.g. on/off, 0/1. Then you can mention that these are commonly controlled with buttons, switches, latches etc., but that should not be the definition. And since when does it matter whether a button has a light or not? Should users now go look at REAPER's GUI (default skin, of course) and check for functions that are represented by 'photorealistic' LEDs to know what is supported by OSC in which manner?

Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate faders or knobs.
Bad, not only because "fader" implies a certain function, in contrast to the more generic term "slider", but also because of the same reasons as above. An XY-pad or accelerometer also has a continuous range, but isn't a fader or knob. The typical targets of all these type of controls should rather be defined by their continuous range between fixed end points. And then we can give examples.

Quote:
Originally Posted by Default.ReaperOSC
# Actions that emulate endless rotary controls.
Again, the description is overly specific to irrelevant aspects. One can just as well achieve the same messages with two buttons as with one endless rotary knob. The unique bit is "endless", not "rotary" as in
Quote:
Originally Posted by Default.ReaperOSC
SCRUB_ROTARY /scrub/rotary
So, apparently, some actions are categorized by the ways in which they can be controlled. I think this is a really bad idea, because (1) the ways they can be controlled should not be fixed but configurable (see below), and (2) they should rather be grouped by functionality. If you have a multimode filter with one control for the cut-off frequency and another to switch between low pass / high pass filters, you don't want them ending up in completely different places because one has a knob and the other a button - and neither because has a binary state and the other a continuous range between fixed end points. They should remain close together because their functionality is highly complementary.

Some other actions have now apparently been grouped by directionality: send only, receive only, or bidirectional. This is also a bad idea imho. For many actions imho the user should be able to configure the direction of actions. We should be able to have REAPER send out a message every time it performs /action/12345 but *not* respond to such an OSC message. We should also be able to have REAPER send messages when FX_PREV_PRESET / FX_NEXT_PRESET are selected. Conversely, we should be able to set TRACK_NUMBER, TRACK_BANK_EDIT (which should be renamed "TRACK_BANK_NUMBER", FX_NUMBER, FX_PARAM_PAGE_NUMBER, FX_PRESET *directly*, i.e. have REAPER listen to them and not just send them. If any such changes would be implemented, it would imply that their definitions should be rearranged as well; that doesn't make much sense to me.

---

I think all the 'toggle' actions are an example of poor configurability. What we should do, is make the configuration smarter, not necessarily bigger. In this case, big is bad. Even by adding one simple -toggle flag, we could delete the entire *_TOGGLE section.

We currently have 2 sets of actions to achieve the exact same purpose, and there is not a single case where the feedback between both sets is different. The *only* difference is that we want the action to respond slightly differently to incoming messages, in this case whether we want to 'toggle' or not. We should do something slightly more sophisticated, like:

Code:
TRACK_MUTE -toggle /track/mute /track/@/mute
vs.
TRACK_MUTE -momentary /track/mute /track/@/mute
... where -toggle and -momentary are flags for predefined behavior (one of them could be left out if it is already clear what default behavior can be expected), and/or even more sophisticated, and allow the user to configure to what arguments the action should respond. We could do things like:
Code:
TRACK_MUTE {SEND} -ON 1 -OFF 0 {RECEIVE} -ON 1 -OFF 0 /track/mute /track/@/mute
vs.
TRACK_MUTE {SEND} -ON 1 -OFF 0 {RECEIVE} -ON * -OFF * /track/mute /track/@/mute
(of course the particular syntax is not really important, as long as its unambiguous)

I can think of many more interesting things we could do with configuration flags, e.g. set limits, rescale by applying breakpoint curves (e.g. -{1.0,0.0 0.0,1.0} to invert), set directions (e.g. use -receiveonly to limit feedback), etc.

Since OSC messages need to begin with a /, there's plenty opportunity to designate other characters between the action description and the message pattern. Let's use it.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 03:02 PM   #355
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Quote:
Originally Posted by Banned View Post
We should be able to have REAPER send out a message every time it performs /action/12345 but *not* respond to such an OSC message.
I totally disagree with this because looking in the actions window and finding the action id# then just sending /action/##### is the most logical way to do it. What would be the purpose in REAPER *not* responding to such an OSC message?

Last edited by Anton9; 03-03-2012 at 03:12 PM.
Anton9 is offline   Reply With Quote
Old 03-03-2012, 03:46 PM   #356
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 Anton9 View Post
I totally disagree with this because looking in the actions window and finding the action id# then just sending /action/##### is the most logical way to do it. What would be the purpose in REAPER *not* responding to such and OSC message?
For example, one might want to make sure REAPER listens to device one, but not to device two. One may have multiple instances of REAPER and select which one should respond. Or perhaps that message is already in use by other clients/servers.

The method you describe is indeed simple, however, it does not enable feedback. So it may be the most logical way to set up a one way binding, but that has nothing to do with my point, configurability of the directionality of messages. The (hypothetical) combination of examples is not intended as how actions should ideally be set up (and I definitely did not mean to imply that enabling feedback should always be combined with disabling reception, if that is how you understood it), but simply to illustrate that both sending and receiving should be individually configurable. Are you totally disagreeing with that general point, the specific examples, or both?

If you would want to enable feedback for one particular action, relying on the general /action/@ pattern alone would be highly problematic, since enabling feedback for the entire pattern would imply that each and every action in REAPER would send an OSC message every time it is performed. The general point is that "all actions are receive only" is quite restrictive, and "all actions send feedback" would be overkill.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 03-03-2012, 05:14 PM   #357
diversgens
Human being with feelings
 
Join Date: Oct 2010
Location: France
Posts: 125
Default

Sorry to ask a probably dumb question but what's the difference between the old FX_ prefix and the new FX_INST, what is it suppose to control and when is need to use instead of FX_ ?
Thanks.
diversgens is offline   Reply With Quote
Old 03-03-2012, 05:21 PM   #358
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

I don't see any point in having feedback from actions.., but rather the feedback comes from what ever the action is acting upon. For example if you send /action/22 to REAPER which toggles track1 mute.., REAPER sends /track/1/mutetoggle.., that's the feedback.

As for the multiple devices issue.., I think what we need are actions that toggle the state of Receive and of Send for each control surface listed.
Anton9 is offline   Reply With Quote
Old 03-03-2012, 06:14 PM   #359
Anton9
Human being with feelings
 
Anton9's Avatar
 
Join Date: Jun 2009
Location: Earth
Posts: 1,340
Default

Man.., something is jacked up.., REAPER is not sending messages when editing FX parameters. It sends other edits just fine. I can control FX parameters fine it's just not sending any feedback from the FX. Oh and I'm just monitoring with another piece of software, not sending to a device.
Anton9 is offline   Reply With Quote
Old 03-04-2012, 04:50 AM   #360
musicbynumbers
Human being with feelings
 
musicbynumbers's Avatar
 
Join Date: Jun 2009
Location: South, UK
Posts: 14,214
Default

Quote:
Originally Posted by diversgens View Post
Sorry to ask a probably dumb question but what's the difference between the old FX_ prefix and the new FX_INST, what is it suppose to control and when is need to use instead of FX_ ?
Thanks.
I thin the new one I for the top fx slot only as this is where instrument plugins normally go.
musicbynumbers 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 04:59 PM.


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