Old 07-16-2019, 03:02 PM   #1
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default OSC & wetdry

Let's say you have a ReaperOSC file with DEVICE_FX_PARAM_COUNT 48. If you have a VST with more than 48 fxparam's, wetdry is not received - because it's always listed *after* all other fxparam's! Some of my VST's have several hundred fxparam's, and I can't raise DEVICE_FX_PARAM_COUNT to let's say 500... It would take forever with 50+ tracks.

Why is such an important fxparam like wetdry last in line? Suggestions for workaround?

Last edited by netphreak; 07-16-2019 at 03:12 PM.
netphreak is offline   Reply With Quote
Old 07-17-2019, 01:16 AM   #2
Gerrit
Human being with feelings
 
Join Date: Aug 2018
Location: Maastricht
Posts: 84
Default

Quote:
Originally Posted by netphreak View Post
Let's say you have a ReaperOSC file with DEVICE_FX_PARAM_COUNT 48. If you have a VST with more than 48 fxparam's, wetdry is not received - because it's always listed *after* all other fxparam's! Some of my VST's have several hundred fxparam's, and I can't raise DEVICE_FX_PARAM_COUNT to let's say 500... It would take forever with 50+ tracks.

Why is such an important fxparam like wetdry last in line? Suggestions for workaround?
The wet/dry you mention is not part of the parameter set of the plugin but it's a Reaper parameter so it's appended to the FX parameters. I think this is how it should be, remember that most FX plugin already have their own 'mix' parameter. The Reaper FX wet/dry parameter is available as a separate addressable value but unfortunately this does not work.
You can switch FX parameter banks to get at the next 48, or get the previous bank and thus get to the end of the parameters. It depends on what you're trying to achieve, can you use smaller banks or do you really need to get a lot of paramaters at once?
Do you have a design for your controller with a list of requirements?
For my controller I decided on getting 48 parameters at once because this covers my needs and I'm of the opinion that FX plugins that have more parameters are of limited usefulness because the sheer number of parameters distracts from actually making music (or even just sound).
Gerrit is offline   Reply With Quote
Old 07-17-2019, 02:47 AM   #3
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

I completely agree on the number of fxparam's, maybe 48 is even over the top...

My "complain" here is: why is not Reaper's parameteres listed before the plugin? I mean, there's only a few anyway...

Yes, looping banks until the names of fxparam's starts to display as "" is a possibility, but there's a lot of extra code just to ensure wet/dry is always available for every plugin.

My controller designs are not final, I need to get a grip on what OSC can offer, or if I have to mix in MIDI. Basic idea is a combination of two controllers - foot controller, and hand controller (foot switches to use while playing, and hand controller between songs).

Gerrit - you're a massive resource to this subforum Maybe I will be one day as well. Thanks!
netphreak is offline   Reply With Quote
Old 07-17-2019, 03:43 AM   #4
Gerrit
Human being with feelings
 
Join Date: Aug 2018
Location: Maastricht
Posts: 84
Default

Quote:
Originally Posted by netphreak View Post
I completely agree on the number of fxparam's, maybe 48 is even over the top...

My "complain" here is: why is not Reaper's parameteres listed before the plugin? I mean, there's only a few anyway...

Yes, looping banks until the names of fxparam's starts to display as "" is a possibility, but there's a lot of extra code just to ensure wet/dry is always available for every plugin.

My controller designs are not final, I need to get a grip on what OSC can offer, or if I have to mix in MIDI. Basic idea is a combination of two controllers - foot controller, and hand controller (foot switches to use while playing, and hand controller between songs).

Gerrit - you're a massive resource to this subforum Maybe I will be one day as well. Thanks!
Thanks, it's my hope that the usage of OSC can be promoted by building OSC controllers.

I like the order of the parameters as is, if anything the FX_WETDRY parameter should be made to work. It's in the config:
Code:
FX_WETDRY n/fx/wetdry n/fx/@/wetdry n/track/@/fx/@/wetdry
FX_WETDRY s/fx/wetdry/str s/fx/@/wetdry/str s/track/@/fx/@/wetdry/str
I tested this but the values are not sent and sending this parameter to Reaper has no effect. If this where to be fixed then you always have access to this parameter independent of the FX parameter count.
Gerrit is offline   Reply With Quote
Old 07-17-2019, 04:19 AM   #5
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

Quote:
Originally Posted by Gerrit View Post
... If this where to be fixed then you always have access to this parameter independent of the FX parameter count.
/fx/@/wetdry works fine here, after selecting a fx. Example:

Code:
/device/fx/select/2
/fx/2/wetdry f 0.5
But that's just half a victory...
This is not returned when selecting a FX or a track...
netphreak is offline   Reply With Quote
Old 07-17-2019, 05:31 AM   #6
Gerrit
Human being with feelings
 
Join Date: Aug 2018
Location: Maastricht
Posts: 84
Default

Quote:
Originally Posted by netphreak View Post
/fx/@/wetdry works fine here, after selecting a fx. Example:

Code:
/device/fx/select/2
/fx/2/wetdry f 0.5
But that's just half a victory...
This is not returned when selecting a FX or a track...
Hmm, I must have made mistake while testing, I'll have to look into this in more detail.
Gerrit is offline   Reply With Quote
Old 07-17-2019, 04:24 PM   #7
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

I'm still curious as to why you PREFER "bypass" and "wet" to be the two LAST returned values - I can't see no reason whatsoever to not list them FIRST...

Do you ignore these two values in your controller if there's more than 48 fxparam's in a plugin, or loop through banks?
netphreak is offline   Reply With Quote
Old 07-17-2019, 11:57 PM   #8
Gerrit
Human being with feelings
 
Join Date: Aug 2018
Location: Maastricht
Posts: 84
Default

Quote:
Originally Posted by netphreak View Post
I'm still curious as to why you PREFER "bypass" and "wet" to be the two LAST returned values - I can't see no reason whatsoever to not list them FIRST...

Do you ignore these two values in your controller if there's more than 48 fxparam's in a plugin, or loop through banks?
I use the FX bypass from the config:
Code:
FX_BYPASS b/fx/bypass b/fx/@/bypass b/track/@/fx/@/bypass
The bypass in the FX paramater list is actually redundant, same for the FX_WETDRY (apart from the fact that some aspects don't seem to work), that's why I rather see them at the end or even completely removed. These two parameters are part of Reaper, not of the FX plugin parameter set, and as far as I'm concerned the FX plugin parameters should come first. Apart from that almost every plugin has it's own pair of bypass and wet/dry parameters.
Gerrit is offline   Reply With Quote
Old 07-18-2019, 01:58 AM   #9
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

Yes, default config to SET both wetdry and bypass is fine - but how do you read back the values to the device? They're not returned by /device/ selects...
netphreak is offline   Reply With Quote
Old 07-18-2019, 04:45 AM   #10
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

At this point I'm tempted to use MySQL as a "man in the middle", and use websockets to feed/update my displays, since OSC seems to have a few weaknesses on the response side... Storing data in a database gives me another feature - storing "presets", for easy switching on device side. Increased graphical update time on device is the obvious cost, but maybe just barely.
netphreak is offline   Reply With Quote
Old 07-18-2019, 10:57 AM   #11
Gerrit
Human being with feelings
 
Join Date: Aug 2018
Location: Maastricht
Posts: 84
Default

Quote:
Originally Posted by netphreak View Post
At this point I'm tempted to use MySQL as a "man in the middle", and use websockets to feed/update my displays, since OSC seems to have a few weaknesses on the response side... Storing data in a database gives me another feature - storing "presets", for easy switching on device side. Increased graphical update time on device is the obvious cost, but maybe just barely.
I don't see why you'd want to add this amount of complexity.
Storing the state of 32 channels(excluding the FX parameters but including FX name, bypass and wet/dry), the selected channel and 48 FX parameters for the selected plugin in a structure of structs takes up less than 40% of the memory of a Teensy 3.6. Here're the struct definitions for the the tracks :
Code:
// struct for fx plugin
struct trackInsert{
  char  name[NAME_LENGTH+1];                          // plugin long name
  int   number;                                       // plugin number
  bool  bypass;                                       // bypass status
  char  mixStr[VALUE_LENGTH];                         // mix string    
  float mix;                                          // normalised mix
};
typedef struct trackInsert TrackInsert;

// track send parameters
struct trackSend{
  char  name[NAME_LENGTH+1];                          // send long name
  int   number;                                       // send number
  char  volumeStr[VALUE_LENGTH];                      // volume string    
  float volume;                                       // normalised volume
  char  panStr[VALUE_LENGTH];                         // panning string    
  float pan;                                          // normalised panning
};
typedef struct trackSend TrackSend;

// struct containing Reaper track info & data
struct track{
  char        name[NAME_LENGTH+1];                    // track name
  int         number;                                 // track number
  char        volumeStr[VALUE_LENGTH];                // volume string    
  float       volume;                                 // normalised volume
  char        panStr[VALUE_LENGTH];                   // panning string    
  float       pan;                                    // normalised panning
  bool        rec;                                    // record arm
  bool        mute;                                   // track mute
  bool        solo;                                   // track solo
  bool        monitor;                                // track monitor
  TrackSend   send[NUM_OF_SENDS];                     // track sends
  TrackInsert insert[NUM_OF_INSERTS];                 // track effects/instrument plugins
  char        receiveName[NAME_LENGTH+1];             // first receive name, used to determine if track is a bus track
};
typedef struct track Track;
The 40% memory usage is with NAME_LENGTH=18, VALUE_LENGTH=16, NUM_OF_SENDS=6 and NUM_OF_INSERTS=8.
It doesn't take much code to save this to SD card on the build in card reader, the required libraries are all included in the Teensyduino installation. My controller also doubles as a MIDI controller for hardware synths and it can receive complete program dumps from synths and store them on SD card for retrieval.
Gerrit is offline   Reply With Quote
Old 07-19-2019, 12:49 AM   #12
netphreak
Human being with feelings
 
Join Date: Apr 2019
Posts: 40
Default

Great, but I still have not got a grip of my question in post 9...
netphreak 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 06:59 AM.


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