drlight-code / osccontrol-light Goto Github PK

This might get tricky to do cleanly when external control is possible (see #30) because we have to decide if 0/1 or rangeMin/rangeMax will set the button state and the respective values can be conflicting.

ability to factor out reoccuring network/ui/midi settings by some kind of include directive. maybe YAML spec or yaml-cpp already provides this somehow?

Currently we use Liberation Mono which needs the ttf-liberation package installed for example on ArchLinux.

I was able to load the plugin in ardour 6 but can not see the controls specified in .yaml. They dont show up in the automation options in ardour. That is, when you press the A button on a track, then select processor automation and then osccontrol-light, the only thing that shows up is "Plugin Enable"

dependencies: yaml-cpp
zenity required for prebuilt plugin or only Projucer?

This functionality is already there, just needs to be re-enabled and tested after the changes in how plugins are compiled (and named).

the value-range in yaml is ignored by the headless version in reaper. instead it outputs always float between 0 and 1 in osc-data stream.

Not sure how to replicate this issue in the debugger when running the JUCE Audio Plugin Host as it appears to not occur in that context. Only happens in Ableton, is there something I can do to fix this?

the lc4 yaml:

cmake options used:

OSCCONTROL_PRESET_PATH was set to F:\Users\Melborpon\Documents\Ableton\Plugins\osccontrol-light\Presets before building.

Hi @desterritorializ-ada, glad you're interested in my plugin :) let's see if we can make it work for you.

In order to install and use the plugin you will have to walk through the process of building it first. This is necessary for two reasons. In general, on a Linux system it's tricky to provide pre-compiled binary plugins because there are so many different distributions out there.

More importantly, in the case of this plugin you will need a pre-compiled version that is specific to each preset definition file that you want to use. The file contains the definition of the controls that you want each instance of the plugin to have and which OSC messages they are mapped to. That's because in order to create controls that can be automated within the host environment, the controls need to be known at construction time of the plugin, so no user interaction is possible in-between. At least I could not find a way to do this using the VST SDK or the JUCE audio plugin abstraction.

Did you try to follow the compilation instructions? How far did you proceed? Where did you get stuck and what is the problem that you ran into?

Every time I hit the cancel-button in Folderview, Ardour 5 crashes with the following Terminal-Output:

The program 'ardour-5.12.0' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 479 error_code 3 request_code 15 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) pure virtual method called terminate called without an active exception Aborted (core dumped)

I followed the readme.md instructions for headless configuration:

I export the Presetfolderpath to .bashrc

I made three links like so:
ln -s -T oscsend-light.so oscsend-light-track-1.so

I checked that the corresponding track-1-3.yaml are in the presetfolder.

I gave reaper the pluginfolder as vst-path and let it scan for new plugins. Reaper shows me the gui version and only one headlessversion, both with the same name.

The headlessversion do not send osc-data (Offcourse I set port and ip in yaml).

This will enable to send OSC to the plugin and record it as automation of the controls in the host environment. The automation data can then be replayed (in a timesynced manner with the host transport/timeline). This will finally provide the missing link between DAW automation and external OSC control.

Hi! Just wondering if at some point an LV2 builld target can also be set and released? Thanks!

This can for now be worked around by removing and re-adding the plugin inside the host.