<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<font face="'Times New Roman'"><div>> 1) Fork these plugins and add a tuning frequency port, in Hz, which</div><div>> makes the current reality of them using absolute octave signals go away.</div><div>> The avwlv2 project will have to adjust the ported AMS modules likewise.</div><div>> Though your plugins do not currently do this, you now seem to think this</div><div>> is the correct solution?</div><div>> </div><div>> 2) Define an absolute unit in octaves with a standard, absolute, center</div><div>> frequency. This is current reality, except the "define" part, and the</div><div>> 'standard' is a weird frequency.</div><div><br></div><div>Not sure if I can really comment on these two options but can't you move</div><div>tuning into the MIDI code? Here is what I mean:</div><div> </div><div>> Suppose you have a VCO with two 1/octave control ports.</div><div>> One is used by a GUI element, say a slider which could</div><div>> have a scale in Hz, note names, or octaves. The second</div><div>> is the 'voltage' from a keyboard.</div><div>> </div><div>> The actual frequency of the VCO would be</div><div>> </div><div>> F = exp2(V1 + V2 + C) (1)</div><div>> </div><div>> where C is some constant, e.g. log2(440).</div><div><br></div><div>The constant 'C' used to be the keyboard voltage from the resistor</div><div>divider circuit. It was intended to be the voltage that would produce</div><div>A440 on middle-A on an 8' transpose, no mods or detuning. It was never</div><div>that accurate by which I mean the oscillator signal depended on other</div><div>environmental influences and is why many of the old beasts had an A440</div><div>reference sine wave and global/auto tuning.</div><div><br></div><div>You could extract the same from your MIDI signal so that the MIDI input</div><div>is also converted into a port that is summed with the mods to produce</div><div>the output signal - you are going to have summing, it is needed to link</div><div>kbd, mod, fine/rough tuning.</div><div><br></div><div>> There is no such thing as "property of the VCO" except parameters (i.e.</div><div>> control inputs), so this is equivalent to saying there should be two</div><div>> ports where only one is absolute.</div><div><br></div><div>Well, in the voltage controlled synths there were properties of an</div><div>oscillator. If your synth does not have controls but only ports then how</div><div>do you select the waveshaping code? How do you select 12+24dB/Oct filters,</div><div>how do you select keyboard tracking versus non-keyboard tracking oscillators,</div><div>are these all input ports with implied semantics? Are they different modules?</div><div><br></div><div>There are other examples but when I was starting on Bristol this single issue</div><div>lead me to separate out mod/volt controls and property controls since the option</div><div>of using an input port to define a constant is a waste of CPU cycles and is also</div><div>going to be pretty arbitrary. I also liked the concept of it being 'fully bussed' but </div><div>that truth is that it does not apply itself that well. Having separate modules for </div><div>each waveform, filter <span style="font-size: 10pt; ">type, tracking methods, etc, is also a waste of time and even </span></div><div><span style="font-size: 10pt; ">more so if different </span><span style="font-size: 10pt; ">modules have to be invoked each time somebody changes </span></div><div><span style="font-size: 10pt; ">parameters.</span></div><div><br></div><div>The other parameter that is going to be an issue is transpose. You could</div><div>look at this as another input port but that is another waste of CPU to have</div><div>a port for a constant value. Also, the original synths did not have a</div><div>voltage value that represented transpose, it was a property that adjusted</div><div>the rate of the oscillator which drove the waveshaping circuits. The issue</div><div>here (with the originals) is that the waveshaping was dependent on the</div><div>frequency so if an oscillator is transposed then some changes may also</div><div>be needed to the parameters of the shaping circuit. This is difficult to</div><div>emulate if you literally only have ports rather than properties/controls.</div><div>It can be argued here that you are not intending to actually emulate any</div><div>specific synth in which case these interactions are not necessary but if</div><div>you are not emulating then why do you want V/Oct which is an emulation of</div><div>the controls of the analogue synths?</div><div><br></div><div>Also, if you do want to use V/Oct then perhaps also get rid of -ve values.</div><div>I mentioned this before and I always get ainsy when considering 'what if the</div><div>control bus goes negative?' It is unanticipated results for an AMP and -ve</div><div>values to a filter cutoff can be, well, put it this way, I check for them.</div><div>The Moog spec for CV was 0..10v, the value does change according to your</div><div>sources but it never included -ve volts.</div><div><br></div><div>Regards, nick.</div><div><br></div></font> </div></body>
</html>