# Constant heterodynes for a given VOct

I’m not sure I’m posting in the right place. Sorry if wrong.

Does there exist a plugin that for a given Voct computes a Voct with a given heterodyne? That is: is there a module that computes the Voct for a second oscillator so that the beat frequency between the two is given? I have a simple Lua script that does this with VCV-Prototype, and it would be trivial to convert to C++, but I don’t want to reinvent the wheel.

Moving to #plugins since this isn’t about plugin development but about finding an existing module.

I have a module called ‘CV Frequency Shift’ that converts Voct to the corresponing frequency in Hz, then adds/subtracts a given frequency and converts the result back to Voct. See https://github.com/Ahornberg/Ahornberg-VCV-Modules for more info. It’s actually in the release stage.

I just grabbed it. I don’t recall seeing a update notice on the library. One thing I find a bit tricky is relating the volts into the freq mod to Hz displacement. E.g. what knob setting corresponds to say 1/2 Hz/volt. I had to find this by experiment, and the knob value was a weird magic number.

What knob setting did you choose to shift by 0.5 Hz?

I forget. I was feeding it with BogAudio’s lfo sending [-1,1]. A quick patch lfo -> CV_Freq Shift -> Hot Tuna requires the modulation knob set to 0.20897 to map +/- 1V to +/- 1/2Hz. When I experimented with this, I took into consideration that for the regular voltage scale, f = 440*2^(v-3/4), and rather than attenuating the input voltage, I instead summed the line in (if connected) with the knob value, and I scaled so +/-10 volts corresponded to some power of 10 displacement in Hz. Of course one needs to clamp underneath to keep things above zero Hz else the log2 blows up.

@caowasteland Canyou provide a VCV Rack patch please? Then I could exactly repoduse what you did and where your problem lies.

Pitch-CV in general says that there is 1 Volt increase/decrease per octave.

The question is: What frequency in Hz corresponds to 0 Volt Pitch-CV?

For VCV-Rack found the answer in the VCV-Rack itself by looking at the V/Oct output of the MIDI-CV module, and it turns out that 0 Volts corresponds to the MIDI key 60, aka ‘C4’, and that is defined by 261.6256 Hz.

In my module for frequency shifting Pitch-CV values, I provide a root octave selector to make it possible to give another meaning than ‘C4’ to the value of 0 Volts. It’s an octave selector, so you can choose from ‘C0’ up to ‘C8’. It’s not possible now to set it to e.g. ‘A4’ (440 Hz), but there’s no need for doing that, because when you input a Pitch-CV value of 0.75 Volts (that corresponds to ‘A4’ and 440 Hz) and you apply an increase of 0.5 Hz, you will get out the Pitch-CV equivalent for 440.5 Hz. If you input 1.75 Volts (corresponding to ‘A5’ and 880 Hz) you will get out the Pitch-CV equivalent for 880.5 Hz (and not 881 Hz).

I think you misunderstand. 261.6256 ~ 440 * 2^(v-3/4) where v=0. A 440 is a standard concert pitch and a natural number, so I base my thinking on that, and middle C is nine semitones (-3/4v) below that and an irrational number to be exact. Can you read Lua? I can send a VCV-prototype script that makes my thoughts clearer. I did have something committed as a private plug, but I wiped that when you told me about yours. I might get that going again, and send you the C++ stuff if that would be a preferred example.

Yes, you’re right. I’m not understanding what the results are you expect by a given input. My module can translate an input of 0.75 Volts (440 Hz) to the corresponding Volts for 440.5 Hz and an input of 1.75 Volts (880 Hz) to the corresponding Volts for 880.5 Hz on the same knob settings. Is that what you expect?

I think if I can whip up some working code, I’ll make my thoughts clearer, and at least I’ll have a module that meets my expectations provided it goes in a direction you’d rather not. The main chore in writing such a thing is getting the panel layout to look good. I might use some of your vector stuff for the polyphony. I just used a loop in my first stab, and was likely less efficient.

That’s not how I meant that. I mean if you see code, you’ll get what I’m targeting better than I can easily describe it. I don’t really want to be a module publisher. No no no no.

Note: not for general consumption.

Nothing to ‘consume’ there. I took a look at your code but I didn’t find the process() fuction where the calculations usually take place.

Oh duh! I have no idea how that got deleted.

Once more with feeling. (Same URL)

From my perspective, your module works pretty fine, so why not release it?

I just killed some copy pasta. The version you saw also missed the functionality on the 2nd shifter. I’ll consider it, but I’m avoiding the typical maintainer headaches; I’ve dealt with those on other FOSS projects. Also, I’d need to do better panel legends. I know what’s going on, but I don’t want to inflict lack of clarity on others. Also my copy also has a very ugly, Linux-only, IPC for importing triggers and voltages via UNIX domain sockets and nasty custom hackery on Rack itself.

BTW: if you notice bad C++, it’s 'cos I’m an old C hand with a bit of OO learned from Smalltalk and Lisp, and a lot of C++ stuff confuses me.

Don’t bother about that … your module compiles, it runs stable, and it does it’s job