Roland Alpha Juno-2 pwm sawtooth

[aciddose]

It was pretty novel, sure. I haven't followed the prior argument in this thread, but I'm pretty sure we came to the conclusion that Roland used the bits of the digital phase counter to "chop" the waveform, or the PWM signal.

It's more likely the digital waveforms are produced by a digital division circuit. The 2x pulse is the input frequency waveform and further divisions are then made. The PWM waveforms however are most likely analog integrators and comparators as the clock frequency is not high enough in this system to provide the width precision it demonstrates. The chip itself also lacks a master clock input and takes only the frequency clock input after division, unless I'm mistaken.

It should be possible to observe error in the minimal width waveforms which changes based upon frequency most evident at the highest frequencies. You can also observe the peak to peak volume changes in the analog integrated ramp waveform. This is due to a limited number of integrator input voltage bits used to only roughly maintain consistent volume for the ramps across the frequency range.

[aciddose]

Whether there is a digital counter and width comparison N-bits wide or an integrator and voltage comparator would essentially be proven indirectly by either:
1) Digital: There is a master clock input and the pulse width input bits are input directly.
2) Analog: There is no master clock input and the pulse width input is an analog voltage.

From the Alpha Juno service manual:


Unfortunately I haven't been able to locate actual schematics to fully verify, but it seems the EXTAL input may be the master frequency from the 12 MHz crystal. This can be misleading as the frequency is often divided once from the full frequency to improve stability.

Without seeing any error in narrow pulse widths it would be safe to assume the pulse is generated using a digital counter ... but from these block diagrams I can not locate a distinct pulse width input. In which case the pulse width register(s) may be some multiple of 8-bit width passed in via the data bus + address latch paths.

Measuring the maximum clock frequency at 12 MHz and the minimum pulsewidth variation at the maximum note frequency and across multiple notes may reveal more regarding the mechanisms and precision of the circuits.

I think I posted years ago in the earlier part of the thread; whether or not the pwm circuit is digital doesn't seem to make much difference. The audible components should be almost entirely indistinguishable as for a pulse above 20k width == volume with a single audible partial. Given 6 MHz master clock input, 6e6/256 = 23437.5, over 8-bit width precision would be present past 20 kHz. The skew on the edges is also far beyond the range of audible hearing (<50 uS).

The "digital" timbre of the juno pulse waveforms vs. analog comparator outputs would mostly appear at low frequencies and width error at high frequencies should lead mostly to audible variations in level.

So these are likely indistinguishable from fully digital "perfect" oscillators (software blit/blep-based) with intentionally quantized pitch precision. It's a sad trade-off in my opinion and I wonder whether true analog pulse outputs would have acceptable precision.

[Scrubbing Monkeys]

@aluxp
That WT is in fact 256 frames at 2048 samples. Very nice thanks.

[aciddose]

Well, thing is, the "curve" depends on the setting of the highpass filter in the synth, and the note you play... analogue oscillators are commonly pretty perfect. But as people hardly ever see them in isolation, people attribute the waveform they see to the oscillator. Most of the time, the quirk of the visible oscillator waveform is actually a highness filter or some other process in the chain...

Kkkkkkl

You just summed up 7 pages of arguing.

Well, no. The first pages were on such a topic but the later 2/3rds were re: whether the oscillator is analog or digital. The truth is it's a hybrid system that generates digital pulses and noise but with an analog integrator and chopper circuits for the ramp sync'd to those digital pulses.

So in that respect it's much more like the near ideal digital oscillators we use in software today. Accurate frequency precision & "virtually" continuous waveforms that are filtered before being quantized or aliased.

Sadly that trade-off means they're boring and you can't expect to get the interesting analog pulse timbres, interference, frequency drift, sync or other modulation effects you find in a true analog system. It also means although the tuning is static and doesn't drift, the frequency precision and range are both between poor and very poor. The keyboard doesn't track true equal temperament closer than at best several cents and the fine-tuning range and precision are both low.

On the bright side, I've disassembled the BIOS for the alpha juno and it should be possible with a hand-made disassembler capable of a-20-bit (?) address wrapping to produce source-code and a replacement BIOS including customizations of the various trade-offs they made. Just don't look for that from me.

[Kraku]

I didn't read the whole thread through but I'll ask anyway about the chopped waveform this thread is about:

What's the easiest way to model that kind of oscillator in DSP code? Is wavetable the best way to go or is there some fairly straight forward way to go using other methods?

[nix808]

is this shape similar to the Hoover?
-I played with this at some point Kraku,
if sendy is barking up the right tree,
it can be a modulation of pulse and saw, however you want to generate them

[mystran]

I didn't read the whole thread through but I'll ask anyway about the chopped waveform this thread is about:

What's the easiest way to model that kind of oscillator in DSP code? Is wavetable the best way to go or is there some fairly straight forward way to go using other methods?

If you can model a waveform using BLEPs then modelling a chopped version of said waveform using BLEPs is almost equally straight-forward.

[aciddose]

In my own code (I haven't finished) I generate waveforms by using operator overloads to do things like:
chopped_ramp_p2 = ramp & pulse_p2;


https://i.imgur.com/1RpmUT9.png (frequency)

Then from that point on "chopped_ramp_p2 " is just a normal input waveform vector table to the remainder of the oscillator. A word of advice: this is incredibly complicated and a ton of work. I've been held back by producing an optimal through-zero capable version of this for the past decade.

If I were satisfied not having FM/through-zero effects then my current implementation works well enough. One thing needed is simulation of slew-rate limiting and therefore phase delay in the output waveforms. The pulse and sub-pulse waveforms lag slightly versus the ramp by different amounts. This has the effect of applying a very light low-pass filter.

It's just a delay by less than a sample, so a type of FIR filter. When you mix ramp + pulse + sub waveforms together you get this "comb filter" effect. That makes the timbre of the juno oscillator "softer" than phase-aligned waveforms would be. So to simulate that you want to add a delay to your sync functionality. The sync origin might be "0.684282" samples ago but you may want to actually sync the pulse to "0.285238" samples ago or similar. That can be achieved with a sync-offset control that allows for fine tuning.

You could also build soft-skew into the waveforms to be more accurate, but since you need to apply sub-sample sync precision anyway there is zero cost to apply a sync-phase offset while adding additional n-order segments to the waveforms does have an incremental cost. Alternatively you could also use a high frequency all-pass filter as a phase shifter but these tend to have stability issues.

https://i.imgur.com/tTBUYVV.png
https://i.imgur.com/0XQsnkz.png (frequency)

[aciddose]

is this shape similar to the Hoover?

It definitely is used in the hoover sound along with sub-oscillator and mixed with pulse and noise. The ramp waveform has a 2x PWM "AND", so when the PWM pulse at an octave above is low the chopper-ramp waveform is zeroed out.

it can be a modulation of pulse and saw, however you want to generate them

You can use amplitude modulation by an anti-aliased PWM an octave up. This would probably be the easiest method by far and would require a high quality anti-aliasing filter applied to a 2x oversample. Since the band-limited ramp and 2x PWM would be band-width of "1 + 1 = 2".

That may be more expensive overall though because the 2x PWM is being redundantly "double anti-aliased" and the anti-aliasing filter on the 2x oversample would add to it too.

One mistake people are likely to make is that due to the pulse width parameter having a range 0 - 127 internally they might assume you can use a PCM wavetable with 128 phases... but the LFO applied to the width may be more precise. I'm not sure what precision the width has internally in the digital register input of the 6-DCO oscillator chip.

[nix808]

oh ok ty!
-I have done some work on this at some point,
will see if I can find it
I did some masking or something, some pulse modulation of the saw
... can't remember what and how successful, just with osc modules
that could be algorythmic or pcm waves