Page 1 of 1
Interface Voltage Modular with VCV
Posted: Sat Dec 01, 2018 9:45 pm
by NothanUmber
Just tried to load Voltage Modular in the new VCV VST hosting module - works!
VCV CV->VM CV, VCV gate->VM gate and VCV audio in/out->VM audio in/out all seem to work! This should open a number of nice options, harmonicly combining exclusive modules from either world.
Is there a way to receive the vst parameters as cv inputs in the vst version of voltage modular? (The VCV host is able to map up to 16 cv inputs to vst parameters).
Edit: Apparently vst parameters can be assigned to knobs etc. only atm, not CV inputs. So the amount of data that can be sent back and forth between the two applications is a little bit limited. (Gate and pitch inputs of the VCV host seem only to generate MIDI with pitch rounding on first sight. So mainly audio in/out remains for getting two signals from a to b).
Perhaps an OSC I/O module on both sides could do miracles...
Re: Interface Voltage Modular with VCV
Posted: Sun Dec 02, 2018 9:29 pm
by NothanUmber
Ok, first attempt on writing a module that uses memory mapped files to transfer CV informations between processes. (Thought this should be faster than OSC over localhost as the overhead should be smaller...) Currently this is VM only, if it works one could write an equivalent module for VCV - or any other software where the CVs should be sent to or from.
Seems to work nice to "beam around" CVs in one Voltage Modular instance. But when having a second receiver in another instance the signal seems to be distorted - perhaps mapping from one address room to the other is too slow? Further experiments needed...
- CrossTalk.jpg (148.16 KiB) Viewed 5494 times
Re: Interface Voltage Modular with VCV
Posted: Mon Dec 03, 2018 8:28 pm
by NothanUmber
The size of the memory mapped file can now be a multiple of the buffer size. Not exactly the same as a delay, as the reader does not have to wait a defined number of buffers. But it can now fall behind a little and catch up (on average the reader should read as much as the writer writes as both run at the same sample rate). Can still lead to glitches, when the reader should coincidentally be faster than the writer sometimes. If it happens it wasn't obvious to me though - looks and sounds good now (cannot hear a difference between the "teleported" signal and the original one).
When teleporting the signal from Voltage Modular instance A to instance B and then back to instance A and subtracting the original signal from the twice-teleported one then they are not sample-identical. So there is a delay - which seems to stay constant though, the waveform of the subtracted signals doesn't change much. Looks ok on first sight!
- CrossTalk2.jpg (185.13 KiB) Viewed 5470 times
Ok, on second thought it is like a delay of random length (at some point the reader is initialized with pos 0 and starts iterating over the memory mapped file, same with the writer - but initialized sooner/later. As reader and writer have on average the same speed the delay (once determined) stays about constant.
In the screenshot the delay can be 0-999 samples. It also worked with 0-512 and mostly 0-256 samples - which indicates that the delay (random) is bigger than necessary most of the time atm (the bigger the file the more likely a long enough delay is chosen).
So it should be possible to come up with a better protocol that adds just as much delay as necessary...
Re: Interface Voltage Modular with VCV
Posted: Mon Dec 03, 2018 10:39 pm
by Cherry Dan
NothanUmber wrote: ↑Sat Dec 01, 2018 9:45 pmEdit: Apparently vst parameters can be assigned to knobs etc. only atm, not CV inputs. So the amount of data that can be sent back and forth between the two applications is a little bit limited.
You could use a DC Source module, and use the VST param to control the DC value knob. This will, for example, output -5 volts to +5 volts, which is probably exactly what you want. You can scale this mapping in VM's MIDI tab.
Dan
Re: Interface Voltage Modular with VCV
Posted: Mon Dec 03, 2018 11:02 pm
by NothanUmber
Cherry Dan wrote: ↑Mon Dec 03, 2018 10:39 pm
NothanUmber wrote: ↑Sat Dec 01, 2018 9:45 pmEdit: Apparently vst parameters can be assigned to knobs etc. only atm, not CV inputs. So the amount of data that can be sent back and forth between the two applications is a little bit limited.
You could use a DC Source module, and use the VST param to control the DC value knob. This will, for example, output -5 volts to +5 volts, which is probably exactly what you want. You can scale this mapping in VM's MIDI tab.
Dan
Thanks for the suggestion!
Two things look odd
* The value is apparently only modulated between [-5V;0V] instead of [-5V;5V] (I set MIDI mapping to [min;max] in VM
* at least in the osciloscope the curve looks quite edgy - could be a sign of data decimation from audio rate to some kind of control rate?
Not sure whether VM or VCV doesn't play nice here.
- vcvvm.jpg (197.17 KiB) Viewed 5454 times
Re: Interface Voltage Modular with VCV
Posted: Mon Dec 03, 2018 11:30 pm
by NothanUmber
Seems to be a VCV host problem on first sight. At least I get the same behavior in Bidule:
- vcvbidule.jpg (183.77 KiB) Viewed 5453 times
Re: Interface Voltage Modular with VCV
Posted: Thu Dec 06, 2018 11:13 pm
by josep
NothanUmber wrote: ↑Mon Dec 03, 2018 11:02 pm
* The value is apparently only modulated between [-5V;0V] instead of [-5V;5V] (I set MIDI mapping to [min;max] in VM
If you switch to UNI instead of BI in LFO-1 in VCV Rack, range goes from -5 to +5 volts as Dan says ... Also you can use 'Dual Atenuverter' from Befaco in VCV Rack to limit a voltage range.
NothanUmber wrote: ↑Mon Dec 03, 2018 11:02 pm
* at least in the osciloscope the curve looks quite edgy - could be a sign of data decimation from audio rate to some kind of control rate?
I have noticed that the curve in the Oscilloscope (VM) begins to be 'quite tense' when the FREQ command in LFO-1 (VCVR) begins to pass beyond the middle of its trajectory ... So, I think that this could be more a problem of the graphical routines that show the wave in the oscilloscope (VM) than something else ... As if they could not process the signal quickly enough with which the LFO-1 is sending it.