> 1) Fork these plugins and add a tuning frequency port, in Hz, which

> makes the current reality of them using absolute octave signals go away.

> The avwlv2 project will have to adjust the ported AMS modules likewise.

> Though your plugins do not currently do this, you now seem to think this

> is the correct solution?

> 

> 2) Define an absolute unit in octaves with a standard, absolute, center

> frequency. This is current reality, except the "define" part, and the

> 'standard' is a weird frequency.

Not sure if I can really comment on these two options but can't you move

tuning into the MIDI code? Here is what I mean:

 

> Suppose you have a VCO with two 1/octave control ports.

> One is used by a GUI element, say a slider which could

> have a scale in Hz, note names, or octaves. The second

> is the 'voltage' from a keyboard.

> 

> The actual frequency of the VCO would be

> 

>  F = exp2(V1 + V2 + C)        (1)

> 

> where C is some constant, e.g. log2(440).

The constant 'C' used to be the keyboard voltage from the resistor

divider circuit. It was intended to be the voltage that would produce

A440 on middle-A on an 8' transpose, no mods or detuning. It was never

that accurate by which I mean the oscillator signal depended on other

environmental influences and is why many of the old beasts had an A440

reference sine wave and global/auto tuning.

You could extract the same from your MIDI signal so that the MIDI input

is also converted into a port that is summed with the mods to produce

the output signal - you are going to have summing, it is needed to link

kbd, mod, fine/rough tuning.

> There is no such thing as "property of the VCO" except parameters (i.e.

> control inputs), so this is equivalent to saying there should be two

> ports where only one is absolute.

Well, in the voltage controlled synths there were properties of an

oscillator. If your synth does not have controls but only ports then how

do you select the waveshaping code? How do you select 12+24dB/Oct filters,

how do you select keyboard tracking versus non-keyboard tracking oscillators,

are these all input ports with implied semantics? Are they different modules?

There are other examples but when I was starting on Bristol this single issue

lead me to separate out mod/volt controls and property controls since the option

of using an input port to define a constant is a waste of CPU cycles and is also

going to be pretty arbitrary. I also liked the concept of it being 'fully bussed' but 

that truth is that it does not apply itself that well. Having separate modules for 

each waveform, filter type, tracking methods, etc, is also a waste of time and even 

The other parameter that is going to be an issue is transpose. You could

look at this as another input port but that is another waste of CPU to have

a port for a constant value. Also, the original synths did not have a

voltage value that represented transpose, it was a property that adjusted

the rate of the oscillator which drove the waveshaping circuits. The issue

here (with the originals) is that the waveshaping was dependent on the

frequency so if an oscillator is transposed then some changes may also

be needed to the parameters of the shaping circuit. This is difficult to

emulate if you literally only have ports rather than properties/controls.

It can be argued here that you are not intending to actually emulate any

specific synth in which case these interactions are not necessary but if

you are not emulating then why do you want V/Oct which is an emulation of

the controls of the analogue synths?

Also, if you do want to use V/Oct then perhaps also get rid of -ve values.

I mentioned this before and I always get ainsy when considering 'what if the

control bus goes negative?' It is unanticipated results for an AMP and -ve

values to a filter cutoff can be, well, put it this way, I check for them.

The Moog spec for CV was 0..10v, the value does change according to your

sources but it never included -ve volts.

Regards, nick.