Sorry my computer logged me out from writing this, so I need to explain this quickly.
So I figured out supersaw leads can be done like this. Use a long BRR sample (but not too long because of memory constraints). Set every BRR block to filter 1. Set every sample to 0. Now for every oscillator peak/impulse sample, add 1 to the sample height. If multiple oscillators peak at the same time, add them up. Filter 1 will create the sawtooth pattern after every impulse sample.
I don't think the BRR filter on an impulse train is really equivalent to a saw's output spectrum*, but a filtered super-pulse-train might be a useful musical instrument of its own?
Have you tried just making a super-saw sample, though? That worked fairly well for MOD music. (i.e. record a few seconds of it, crossfade for a loop.)
* Edit: maybe it actually is, in the right circumstance, see lidnariq's post below.
The integral of a pulsetrain is a stairstep function. A stairstep function minus the line that bisects each rise and run is a sawtooth wave.
Filter 1 is a leaky integral: y[n] = x[n] + .9375*y[n - 1]. The leaky integral of a pulsetrain is a sawtooth with a bunch of DC added. So you might want to treat some oscillators as positive impulses and some as negative impulses in order to minimize spurious DC.
Saw's spectrum should just be a "perfect" lowpass (i.e. integrator) filter of an impulse train, IIRC?
I guess I should look at the interpolation filters...
Lessee... nocash says
Filter 0: new = sample
Filter 1: new = sample + old*1+((-old*1) SAR 4)
Filter 2: new = sample + old*2+((-old*3) SAR 5) - older+((older*1) SAR 4)
Filter 3: new = sample + old*2+((-old*13) SAR 6) - older+((older*3) SAR 4)
Filter 0 is easy.
Filter 1 is ...
y[n] = x[n]+y[n-1]-y[n-1]/16.
Y = X + 15·Y·z¯¹÷16
Y·(1-15z¯¹÷16)=X
Y÷X=1/(1-15z¯¹÷16)
so transfer function is a single zero at 0 and a pole at +15/16. That's a lowpass with corner frequency at ≈1/56 the sample playback rate ... probably close enough to a perfect integrator?
edit: add the other two-
Filter 2: H=1/(1-61z¯¹÷32+15z¯²÷16) → Two zeros at 0, poles at (61±sqrt(-119))÷64 → Resonant (underdamped) 2nd-order lowpass; resonance is +9db at sample rate÷36; -3db point is at ≈1/20th the sample rate.
Filter 3: H=1/(1-115z¯¹÷64+13z¯²÷16) → Two zeros at 0, poles at (115±sqrt(-87))÷128 → Critically damped 2nd-order lowpass; -3db point is at ≈1/39th of the sample rate.
rainwarrior wrote:
Have you tried just making a super-saw sample, though? That worked fairly well for MOD music. (i.e. record a few seconds of it, crossfade for a loop.)
I've tried doing so in the past and they always come out weak sounding, or take up too much memory. Just really difficult to get it to sound good. Using an algorithm would guarantee everything would be crystal clear.
lidnariq wrote:
Saw's spectrum should just be a "perfect" lowpass (i.e. integrator) filter of an impulse train, IIRC?
I was thinking that a sawtooth should be -6db/octave but... ah! Yes, a simple lowpass filter should produce that. Sorry, I was working from incorrect fuzzy memories.
Though, also I thought that our filter was at a fixed cutoff, but the impulse train was being streamed in, so I didn't think it was going to be tuned to the target oscillator frequency anyway. Maybe I misinterpreted this as well... maybe that's just a matter of adjusting amplitude to fit.
Unless I'm missing something, using real single-sample impulses would result in a muffled sound, since the BRR decoding is upstream of the gaussian interpolator. But since the BRR filters are linear, it should be possible to prefilter the impulse train to counteract this.
It seems to me that with a sufficiently compact treble boost filter, such as the one BRRTools uses, it might be feasible to synthesize the BRR data for this scheme in real time. This would allow very long notes with no looping artifacts in not very much RAM. On the other hand, avoiding buffer pacing glitches might be a bit fiddly, and playing more than one note at a time might require multiple buffers...
I can imagine that working by using {2,-1} pre-filter, but then you'd have to make sure more than 3 oscillators peak at once. You can probably use negative peaks instead just because the negative range is slightly bigger.
Here's some 65816 code to make a "pulse train." Registers X and Y need to be fed with a random seed value for where to start the first wave, so that the 7 oscillators don't merge into a single sawtooth at the loop point.
Code:
make_pulse_train:
clc
-;
inc {sample},x
tya
adc {wavelength_lo}
tay
txa
adc {wavelength_hi}
tax
cmp #$2000
bcc -
rts
So that we're all on the same page, I first want to understand the requirements for this synthesis.
- In a supersaw, by how much are the oscillators typically detuned?
- At what pitches is it used?
- How long is a note held?
- And at what sample rate did you intend to synthesize it? 8K? 32K?
tepples wrote:
- In a supersaw, by how much are the oscillators typically detuned?
seems to have a pretty good analysis of the detune setup on the original Roland JP-8000 supersaw:
Quote:
When you look at the SuperSaw's various examinations, which can be found on the web, it gets pretty clear that Roland used maximum pitch spreads expressed in prime numbers.
I chose maximum detune values in cents and these here should come pretty close to the JP8000: -191, -109, -37, 0, 31, 107, 181. Beating is reduced to an absolute minimum when using prime detune values. Phase randomization (on note-on) is also definitely needed or you won't get a strong attack on every note-on.
Having just tried reconstructing that in puredata... I'm think he meant to say "mil" not "cents".
Yeah, I'm pretty sure it's not actually supposed to span almost four semitones, but you get the idea.
Assuming those are in thousandths of a semitone, this one-liner spits out the frequency ratios:
Code:
$ python3 -c 'print("\n".join("%.5f" % 2**(detune/12000) for detune in [-191, -109, -37, 0, 31, 107, 181]))'
0.98903
0.99372
0.99787
1.00000
1.00179
1.00620
1.01051
Or to scale them by (say) 4096 for soft-synthesizing with integer math:
Code:
$ python3 -c 'print("\n".join("%d" % round(4096 * 2**(detune/12000)) for detune in [-191, -109, -37, 0, 31, 107, 181]))'
4051
4070
4087
4096
4103
4121
4139
I could possibly do variable detune amounts by making the loop longer or shorter. For example, If I have 8192 samples, and 32 samples per cycle (base frequency) then I can divide 8192 by {253,254,255,256,257,258,259} to get the oscillator frequencies. If I had 8224 samples, then I can divide them by {254,255,256,257,258,259,260} and have resulting frequencies that are slightly closer.
I got the 65816 side done (it looks correct in a memory editor). Now I got to move it to the spc700 side to hear it. Boy, SNES programming is a lot of work.
EDIT:
Got it working!!!
Fixed a bug that caused it not to work in Higan and ZSNES. I always have the worst luck with SNES9x for some reason.
Here's some Aquatic Ambience.
This one fixes a glitch caused by overlapping echo buffer. Oops!
What exacly is a "super" saw ? Doesn't just two detuned normal saw emulate this (at the acceptable price of requiring 2 voices) ?
Bregalad wrote:
What exacly is a "super" saw ? Doesn't just two detuned normal saw emulate this (at the acceptable price of requiring 2 voices) ?
Apparently it's normally seven detuned sawtooth waves, not just two.
It was 7 in a specific implementation that made the name popular:
https://en.wikipedia.org/wiki/Roland_JP ... e_SupersawI don't think there's anything inherently distinctive about exactly 7 though. I think pretty much 3 or more should qualify.
Honestly, it sounds like just recording the sample, converting to BRR and playing back is the best option. Sure it won't sound as crisp as the original, but nothing will on the SPC700 anyways. Doing that trick with filter 1 is just a particular case of this where you're recreating your sample in BRR format directly rather than converting it automatically. I don't think any method is supperior to the other - you should just try both and see which one makes a sound you like the most.