You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 20, 2022. It is now read-only.
I think everyone just abuses plain audio ports for CV-like functionality (so without offset or range metadata). This may need cv <-> audio conversion inside jlv2 then.
Nope, no sense of CV. Need a good way to handle it, but don't know how yet. Might have to make the AudioProcessor subclass public, with custom "process" function. THen calling code can use that, or just not support CV.
I have made quite a lot of changes to my local "juce" copy so the graph could support CV.
The internal patchbay of carla uses an old copy of juce when it was still GPLv2, heavily modified to remove all gui stuff and anything not needed to make it work as the super-base-support for carla.
Feel free to take any ideas, relevant code is at https://github.com/falkTX/Carla/tree/master/source/modules/water/processors
But I have to say it is not straight forward at all.. JUCE makes a lot of assumptions for audio.
(also for a single midi port per node, which is annoying but havent resolved that yet)
DPF allows a CV property hint to turn input/output ports into CV ports.
Might it be possible for jlv2 to allow something similar?
The text was updated successfully, but these errors were encountered: