I’ve always wondered about the OSC RegEx matching prefs and recently found this:
OSC Reg Ex Example
This explains using RegEx Expressions for sending.
But I was wondering if it is also possible to use this for a receiver pattern.
IE:
/FromVVOSC/.
/FromVVOSC/[12]
/FromVVOSC/CSWindow[.]
/FromVVOSC/CSWIndow[12]
RE Strings
When setting OSC Name Spaces for receiving or sendings.
Or constructing Strings for display. It would be great to be able to
1A) Have a $recVal variable that represents the recivers Value
1B) Have a $userVar local variable that could be set by the user
then these values could be used for creating the OSC Name Space,
For example in a Text Field could have:
display string: “Layer 1’s Blending Mode is ($recVal)”
of further:
set Layer1’s blending mode menu to send it’s string value via OSC to:
/FromVDMX/Layer1/BlendingMode
set userVar to “1”
set receiver’s OSC Reciving Namespace to:
/FromVDMX/Layer($userVar)/BlendingMode
Now Can Set Text Field display string:
“Layer ($userVar)'s Blending Mode is ($recVal)”
Maybe these String Constructions for be achieved via a
Do Math String Function or
a new TextFX Chains functions
I’ve noticed Vezer uses the following OSC parameters
Composition name
You can use the containing Composition’s name in OSC tracks address with the keyword $COMP .
For example, if the Composition name is Foo , you can insert that to the OSC address by defining the OSC address of one or more tracks this way: /$COMP/parameter1 . This case, Vezér will send data to /Foo/parameter1 .
Composition index
You can use $COMPINDEX as a parameter in OSC address, which results in the index of the Compositions (starts from 1).
Track name
You can use the Track’s name in OSC tracks address with the keyword $TRACK .
For example, if the Track name is Foo , you can insert that to the OSC address by defining the OSC address of one or more tracks this way: /$TRACK/parameter1 . This case, Vezér will send data to /Foo/parameter1 .
Track Value
You can use $ mark in OSC addresses to use Tracks value in the address.
For example:
/layer$/trigger will turn to /layer0/trigger , /layer1/trigger and so on, depending on the Track’s current value.
Here’s some suggestions I have:
These would take up
- an additional tab in OSC preferences
- an additional tab / space in each plug in
- additional room / tab in each receiver / sender
These items would be available in any place where an OSC Message can be created.
GLOBAL OSC PARAMETERS
- $PROJECT
- $BPM
- $MEASURETIME
- $LAYER
- $LAYER_IDX
- $LAYER_GR_IDX
These can be set for each plug-in and used within the plug-in to create OSC Messages.
EACH PLUGIN - HAVE DEFAULTS BUT USER CAN EDIT
- $PLUGIN_NAME
- $PLUGIN_PATH
- $PLUGIN_MIDI
- $PLUGIN_INT1
- $PLUGIN_INT2
- $PLUGIN_EXT
- $PLUGIN_COMP
- would default to the name in the workspace IE
Control Surface 1
- but user could override IE.
ContSurf
- could be used to identify part of the OSC Address path IE
FromCS
- or used as an element as part of a receiver identifier IE
- say I have LFO plugins named
LFO 1X, LFO 1Y, LFO 1S
LFO 2X, LFO 2Y, LFO 2S
LFO 3X, LFO 3Y, LFO 3S,
LFO L then used as with a combo (using $PLUGIN_INT1 from below)
- /<$PLUGIN_PATH$PLUGIN_INT1>X/Sine == /LFO L2X/Sine
- /<$PLUGIN_PATH$PLUGIN_INT1>X/Triangle == /LFO L2X/Triangle
- /<$PLUGIN_PATH$PLUGIN_INT1>X/Ramp == /LFO L2X/Ramp
- /<$PLUGIN_PATH$PLUGIN_INT1>Y/Sine == /LFO L2Y/Sine
- /<$PLUGIN_PATH$PLUGIN_INT1>S/Triangle == /LFO L2S/Triangle
- could be used in receivers to Identify a MIDI Channel that gets used and only needs to be changed in one place. here IE
3
- this could be used in multiple receivers
- /MIDI/ch. <$PLUGIN_MIDI>/ctrl [71]
- /MIDI/ch. <$PLUGIN_MIDI>/ctrl [72]
- /MIDI/ch. <$PLUGIN_MIDI>/ctrl [73]
- and updated / changed very quickly
- could be used to identify which PlugIn Instance this is IE
2
- can use for building of the OSC Address path IE
/<$PLUGIN_PATH><$PLUGIN_INT1>
would give you
/FromCS2
- could be used for various MATHS in creating OSC Address or Value
- represent an numbered instance of a plugin, MIDI channel etc
- be able to collect a VALUE from Other Sources, just like you can with receivers
- also be able so select OSC VARIABLES like the ones defined here
- be able to select what type of Value it is
- later be able to get a string formatted value from this using standard formatting
- IE
<"%.3f", $PLUGIN_EXT>
- this would be a COMPOSITE string variable
- one that can be constructed from GLOBAL or LOCAL PLUGIN OSC VARIABLES
- be able to use REG-EX in the constructions
- be able to use REPLACE FOR ANY REG-EX Groups
These can be set for each plug-in and used within the plug-in to create OSC Messages.
EACH RECIEVER/SENDER - HAVE DEFAULTS BUT USER CAN EDIT
- $SEND_NAME
- $SEND_TYPE
- $SEND_VAL
- $SEND_USR_INT
- $SEND_EXT_VAL
- $SEND_COMP1
- $SEND_COMP2
- this would be name to identify sender (User can overwrite)
- this would be name to identify sender (User can overwrite)
- be able to use REPLACE FOR ANY REG-EX Groups
- this could be a value that can be calculated from the original $VAL but having either
- math applied to it
- NumFX Chain Applied
- String Formatting / Processing
- Value Processing IE
$SEND_VAL_ADJ = $VAL * (($SEND_EXT_VAL->rgbColor()->red())
- could be used for an additional address identifier or for maths
- be able to collect a VALUE from Other Sources, just like you can with receivers
- also be able so select OSC VARIABLES like the ones defined here
- be able to select what type of Value it is
- be able ti get other types of values from it depending on value type IE
- $SEND_EXT_VAL->isType(Color)
- $SEND_EXT_VAL->rgbColor()->red()
- $SEND_EXT_VAL->xyPos()->x()
- $SEND_EXT_VAL->stringValue()
- $SEND_EXT_VAL->lastPathComp()
- $SEND_EXT_VAL->listItem(4)
- as in the $PLUGIN_COMP be able to do multi string construction
- be able to use GLOBAL / LOCAL PLUG IN & LOCAL SEND OSC VARIABLES
- another alternative string to above
BUMP from the future. This would be an amazing addition!
Have you tried using the OSCQuery Browser?
Sure, but what OP was proposing was variable substitution in OSC paths
Oh maybe I wasn’t really clear in the part that interested me – I know we have regex matching, but the concept of receiver-side variable substitution (and variable management within the software) is the novel idea.
1 Like
Cool, thanks for the clarification.