KVR Audio

xoxos · Post by **xoxos** » Sat Jul 26, 2014 12:54 am

aciddose wrote:linear

i'll take your word for it

aciddose · Post by **aciddose** » Sat Jul 26, 2014 1:08 am

antto · Post by **antto** » Sat Jul 26, 2014 7:29 am

my explanation is: it's equivalent to slapping a 1st order LPF on the "Pitch" (in 1V/Oct scale) and set the LPF frequency to 7.23Hz
when there is no slide - set the LPF frequency to something high (so that it doesn't slide)

aciddose · Post by **aciddose** » Sat Jul 26, 2014 4:20 pm

antto · Post by **antto** » Sat Jul 26, 2014 4:42 pm

with "something high" i meant more or less something equivalent to forcing the LPF to follow the input signal
i just have no in-depth idea how "high" it has to be.. in my case i set the filter to some high freq (probably above 5kHz i don't remember exactly) so that it's "fast enough" and does the job

as for the other stuff - i don't understand quite
do you mean that the RC time constant (or frequency..) is different depending on which note is playing, due to the resistor network?

mystran · Post by **mystran** » Sat Jul 26, 2014 4:55 pm

antto wrote:my explanation is: it's equivalent to slapping a 1st order LPF on the "Pitch" (in 1V/Oct scale) and set the LPF frequency to 7.23Hz
when there is no slide - set the LPF frequency to something high (so that it doesn't slide)

Well, if you have the schematic from the web: the IC12 switch will connect C35 to either the IC11b input or output. If it's connected to the output it just tracks the opamp (since there is essentially "infinite" current), while if it's connected to the input, it forms an LP with the resistor network that forms the DAC. It's obvious a one-pole, but I think aciddose is correct in that the actual current (and hence cutoff) seems dependent on the bit pattern from the DAC.

So yeah.. well.. I don't know. If you wanted to simulate this, you should probably just generate the raw bits for the DAC and then use nodal analysis to solve the currents to integrate. As long as you assume IC9 is constant voltage source (probably safe assumption with 200k resistors) then this is still linear and doesn't take much CPU. Alternatively just precalculate the equivalent resistances for all 2^6 = 64 values.

And I just have to agree that "something high" is perfectly valid approach to the bypass; it's not like any opamp supplies infinite currents anyway, so theoretically it's "something high" in the original too.

Sendy · Post by **Sendy** » Sat Jul 26, 2014 5:28 pm

Why do people delete their posts? Either you want to contribute to the discussion or you don't, surely? You're turning these discussions to swiss cheese.

kingtubby · Post by **kingtubby** » Sat Jul 26, 2014 6:32 pm

Sendy wrote:Why do people delete their posts? Either you want to contribute to the discussion or you don't, surely? You're turning these discussions to swiss cheese.

Agreed. I just dipped in to this thread and it seems that perhaps some of this conversation should have been carried on in private.

antto · Post by **antto** » Sat Jul 26, 2014 8:33 pm

okay, it makes sense
however, with all my tests against the x0xb0x - a LPF at ~7.23Hz just worked
i didn't go down to see if the actual phase of the oscillator would end up exactly the same after a slide, because thats already beyond what i can measure ***
and adjusting the LPF frequency +/-0.5Hz really barely makes a difference against the real thing, so this detail is not significant as far as i'm concerned (whether each note makes a slightly different time constant for the slide time)
it must be uber slight

i don't think xoxos wanted to go that deep, but it's good to know that such thing is there

*** i mean, comparing the actual pitch slide, i didn't model the individual resistors of the resistor network, in my model, the spacing of the notes is "perfect" and i didn't want to go so deep
an easier way to measure the pitch slide speed would have been to actually record the pitch singal instead, however i don't have DC-coupled soundcard nor a scope
plus, ideally i don't think the goal of that circuit was to have a different slide time for different notes, that's why i simplified my explanation to "put a LPF on the 1V/Oct pitch signal"

aciddose · Post by **aciddose** » Sat Jul 26, 2014 10:01 pm

It can be better to use the exact times (90%, 150ms) rather than define it in hz, as you can see using ms we end up with what can be rounded off only slightly to nice round numbers. In hz you're going to be far less accurate at long times than the reciprocal of course.

I removed the stuff I posted before as I need to research this in quite significant depth to be posting this sort of description. I started to work on this but this is really something that requires countless hours of effort and I realized I was really wasting my time.

At a glance it seems the time constant is indeed constant, and not dependent upon the total resistance in line to the capacitor. In which case 150ms would be the time constant. 200k, 220n. Don't take my word for it though.

antto · Post by **antto** » Sat Jul 26, 2014 11:45 pm

i've actually done this recently, i hooked up one of my x0xes to send midi notes to xhip (some version i downloaded long ago) and matched the slide time accurately
no idea if the glide parameter uses "90%" in the formula (you'll know) but the value that got there was 105ms
http://www.muffwiggler.com/forum/viewto ... 54#1568254

the reason why i say it in Hz is because i have the formulas for converting RC to Hz handy, and also in the actual synth i use the formula for calculating the LPF cutoff coeff in Hz (which is slightly cheaper (one exp()) than the formula for calculating as tau (exp() with division iirc))
also, at first i used a SE module LPF which has Hz and would have had to use complicated converter modules if i wanted convert tau to Hz

mystran · Post by **mystran** » Sat Jul 26, 2014 11:55 pm

Oh right, so .. if the ICs can be treated as constant voltage (which would seem reasonable), then the capacitor must necessarily see a fixed impedance (the variation in current is between the IC pins) but the impedance probably can't be 200k since there is a resistor divide between 200k and rest of the maze through 100k.. so in practice it'll be somewhat less.

The rest of the maze has two 200k in parallel (so 100k) in front of it, then 200k to the second pin.. so if we cut the maze short there, we'd see 1/(1/200k + 1/300k) and the cap would see a total impedance of about 120k(?) and then if one expands the whole thing the same way, one ends up with exactly 100k (after the 200k to ground to balance it out)? That would then result in RC time constant (as it's normally defined) about 22ms -> cutoff 7.23Hz.. and I just checked my old Dolphin source code and I have it set 20ms (which is close; I have probably set experimentally, can't remember) so .. yeah.. antto was probably right.

edit: and after laboriously calculating it all out, I just realized how utterly silly that was: it's obvious when one thinks it out the other way: 200k to pin and 200k to ground -> 100k.. so we add 100k, and we have 200k and 200k to next pin again .. and we add another 100k and so on and at any point we have two 200k impedances in parallel .. and this kind of setup makes sense for a DAC, since .. well you probably want each lower pin to contribute about about half of the remaining range (= one bit)

antto · Post by **antto** » Sun Jul 27, 2014 12:14 am

well, i didn't come at it with so much brainz
it was long ago, before i knew about any RC time constants and fancy formulas
i slapped a LPF and a knob, and started tweaking the cutoff to see if i can get any sense out of it
then it started to look similar
so i fine-tuned it roughly (comparing it on an inconvenient sonogram) to 7.5Hz
and it was good enough then, so i kept it there for a long time
much later i became aware of the RC time constants and started looking around into the resistor and capacitor values and decided to see if i can sort of guess it
tried some random resistance values with that cap value till i get a cutoff frequency out of the formula close to 7.5Hz
and the closest i got was 7.234..Hz
so i tried that in the LPF - well, it was more or less the same (i couldn't measure a significant difference between 7.5 and 7.23) so i thought "must be this, yey"

edit: and now i have a slightly better sonogram (and also, MIDI synchronization) so i can much more easily see that 7.23Hz is "right on"

aciddose · Post by **aciddose** » Sun Jul 27, 2014 3:25 am

20ms with what % ?

Roland uses 90% for their timing on the schematics. See the envelope for example.

I'm getting ~50ms 90% from the circuit itself - that is the R/2R (R=200k) network into a 220n capacitor.

Specifying hz can make sense, but really the 3db point in relation to timing is not very practical. It makes more sense to specify, for a unity asymptote, the time to reach within some percentage of the destination value. 90% is widely used in electronics.

With a 200% asymptote (see sh-09, sh-101, mc-202 attack of adsr envelopes) the timing is for 50%. With any other asymptote (other than unity) in fact you can specify the timing exactly. A 111% asymptote would match the 90% value.

Regarding the idea that the glide operates differently depending upon the bit, this is misinformation passed down over and over through the years much like the "the tb-303 filter is 18db/o".

In fact the current from the R/2R network is always balanced by the fact that all the source pins are connected either to reference or to v+. If you connect only one pin (bit 6, bit 1) at a time the resistance in series will create the times I listed at first, but this is a naive view of the circuit that doesn't take into account the fact that there are multiple paths in the network and that the current is divided multiple times in such a way as to always yield the same impedance into the capacitor. That is, in other words, each bit input contributes current at all times whether it is true or false and the total impedance is always equal.

Code: Select all


V1 9 0 DC 0 PULSE(0 10 100m 1u 1u 999m 1) AC 1 0
R3 9 output 200k
R4 0 14 200k
R5 0 13 200k
R6 0 12 200k
R7 0 11 200k
R8 0 10 200k
R9 output 14 100k
R10 14 13 100k
R11 13 12 100k
R12 12 11 100k
R13 11 10 100k
R29 10 0 200k

C1 0 output 220n

.TRAN 1m 300m 0 1m
.END

I used schematic entry to generate the netlist so the nodes are numbered weirdly. Just run it in ltspice and you'll see the pulse starts at 100ms. It reaches 90% at ~150ms.

5v peak, 4.5v = 90%.

Sorry for the scrawl. Remember to subtract 100ms since I delay the input pulse by that much.

Open303 - open source 303 emulation project - collaborators wanted