Basic Project Advice for 6502-based Synthesizer?

[Chromatix]

commodorejohn wrote:

64K samples for a cyclical waveform is probably hella overkill, though, at least for the OP's purposes.

I wasn't suggesting it should all be used on a single sample! 64KB is enough to load lots of simple instruments, which could be one-shot percussion or voice samples (set the wrap behaviour so that the pointer halts at the end) as well as periodics.

But obviously the counter has to be able to access the entire address space of its attached memory, or some of the latter *definitely* goes to waste.

[commodorejohn]

Chromatix wrote:

But obviously the counter has to be able to access the entire address space of its attached memory, or some of the latter *definitely* goes to waste.

Well, yes in the sense that memory the voices can't address is memory that has no business being in the sample side of the architecture at all. But also no, in the sense that bits that can't directly serve as address bits to the sample memory can still serve a purpose as fractional values that allow for greater precision in frequency selection, which is a non-negligible factor in musical applications (you don't have to go very far up the scale in simple integer-clock-divider counter designs before the closest available output frequencies start being measurably off from the correct notes.)

Additionally, you don't necessarily need to max out the possible size of the sample memory, depending on other design choices. If, say, your maximum loop length is 256 samples, and your hardware design allows for a total of 8 8-bit voices, there's really no point in providing a sample memory larger than 4 KB, unless you're using techniques that change voice samples often enough that sample-copying overhead beomes a significant factor.

[Chromatix]

Right, which is why I suggested a 20-bit counter of which the top 16 bits form the sample address, and the bottom 16 bits are addressed by the variable increment. The top 16 bits would also be where you should attach the wrap comparator and subtraction.

In practice you're unlikely to find a 32Kbit RAM to implement a 4Kx8 memory anyway, rather 64Kbit and up. If it's convenient to implement a 64KB memory - why not?

[commodorejohn]

Chromatix wrote:

In practice you're unlikely to find a 32Kbit RAM to implement a 4Kx8 memory anyway, rather 64Kbit and up. If it's convenient to implement a 64KB memory - why not?

True, but you could implement it as 2x2KB RAMs, which are still readily available (if not exactly cost-effective at large volumes.) Or kick it up to 8KB and get it on a single part instead. (In fact, 8KB for 8 voices with a maximum sample length of 512 and minimum of 8 would leave a generous 64 bytes leftover for configuration registers, if you chose to do it that way.)

As for the "why," it's all dependent on the design strategy and how the OP wants to interface things. It's probably simpler to provide a fixed 4KB memory region that the synthesizer hardware uses than a mappable 4KB window into a larger region. Having each voice use a fixed range of addresses instead of a semi-arbitrary address within a large wavetable also means that's one less register for the software to keep track of, or if a select register is provided, it's at least significantly fewer bits. And going for a fixed wavetable region rather than (say) having the synthesizer hardware DMA samples from main RAM means there's no cycle-stealing going on outside of CPU accesses to wavetable RAM, if that's a thing the designer cares about.

I'm not saying that one technique is the only and inevitable ultimate and the other must ever grovel before it. I'm just saying that there are merits to both strategies and it depends to a significant degree on what the designer wants.

[GARTHWILSON]

commodorejohn wrote:

Well, yes in the sense that memory the voices can't address is memory that has no business being in the sample side of the architecture at all. But also no, in the sense that bits that can't directly serve as address bits to the sample memory can still serve a purpose as fractional values that allow for greater precision in frequency selection, which is a non-negligible factor in musical applications (you don't have to go very far up the scale in simple integer-clock-divider counter designs before the closest available output frequencies start being measurably off from the correct notes.)

I'm probably not understanding you correctly; but to be clear, in DDS, if the phase accumulator and the incrementer are both 16-bit, and you do 16,000 SPS, and you have a 256-sample table, each count of the incrementer is 1/65536 (ie, 1/256 of 1/256) of a wave, so you get 16,000/65,536K Hz resolution, ie, better than 1/4 Hz resolution, linearly, from deep-subsonic up to just below the 8kHz Nyquist frequency, or actually whatever your anti-alias filter can handle, perhaps 7kHz.  A 1/8Hz error (which is the worst case, where you have to go a half of a 1/4 Hz increment one direction or the other to a playable pitch) at the low end of the hearing range is about 10 cents off, which is somewhat of an offense to anyone with a good sense of pitch—except that down there, you can't really discern the pitch accurately at all anyway.  You would rely on the pitch of harmonics, or just see how many seconds it would take to complete a cycle of the beating against a reference, in this case more than eight seconds!  At the lowest note the bass can play (if it doesn't have the C extension), the maximum error becomes about 5 cents.  Up at A440, 1/8Hz error is less than half a cent.  (Hopefully I don't have any errors in my math.)

Quote:

Additionally, you don't necessarily need to max out the possible size of the sample memory, depending on other design choices. If, say, your maximum loop length is 256 samples, and your hardware design allows for a total of 8 8-bit voices, there's really no point in providing a sample memory larger than 4 KB, unless you're using techniques that change voice samples often enough that sample-copying overhead becomes a significant factor.

It's even better than that.  2KB.    256 8-bit samples, times 8 voices is 2KB.  But you might want different tables for different ranges of notes for the same voice.  For example, on my cello, playing the lowest notes on the C string does not give just a shifted-down spectrum of what I get playing one or two or three octaves higher.  (I regularly get up to the top of the treble clef, over three octaves above the lowest note, but I don't feel confident playing above that in public, as intonation becomes more difficult, except sometimes in harmonics.)

[commodorejohn]

GARTHWILSON wrote:

I'm probably not understanding you correctly; but to be clear, in DDS, if the phase accumulator and the incrementer are both 16-bit, and you do 16,000 SPS, and you have a 256-sample table, each count of the incrementer is 1/65536 (ie, 1/256 of 1/256) of a wave, so you get 16,000/65,536K Hz resolution, ie, better than 1/4 Hz resolution, linearly, from deep-subsonic up to just below the 8kHz Nyquist frequency, or actually whatever your anti-alias filter can handle, perhaps 7kHz. A 1/8Hz error (which is the worst case, where you have to go a half of a 1/4 Hz increment one direction or the other to a playable pitch) at the low end of the hearing range is about 10 cents off, which is somewhat of an offense to anyone with a good sense of pitch—except that down there, you can't really discern the pitch accurately at all anyway. You would rely on the pitch of harmonics, or just see how many seconds it would take to complete a cycle of the beating against a reference, in this case more than eight seconds! At the lowest note the bass can play (if it doesn't have the C extension), the maximum error becomes about 5 cents. Up at A440, 1/8Hz error is less than half a cent. (Hopefully I don't have any errors in my math.)

Quite right, and that's one of the advantages of the phase-accumulator design. I was speaking more in terms of simple linear down-counter designs like (for example) the NES pAPU, where the counter is simply loaded with a value and then decremented until it reaches 0, at which point the position within the waveform is incremented. In that system, output frequencies can only be even divisions of the master clock rate, so that there are only two possible frequencies within an octave of the maximum rate, four within two octaves, etc. etc. But really my point is just that extra bits can still serve a purpose even if they don't get directly hooked to the wavetable address.

Quote:

It's even better than that. 2KB. 256 8-bit samples, times 8 voices is 2KB. But you might want different tables for different ranges of notes for the same voice. For example, on my cello, playing the lowest notes on the C string does not give just a shifted-down spectrum of what I get playing one or two or three octaves higher. (I regularly get up to the top of the treble clef, over three octaves above the lowest note, but I don't feel confident playing above that in public, as intonation becomes more difficult, except sometimes in harmonics.)

True enough - there's a variety of benefits provided by multi-sampled waveforms. You could also do something like assign completely different timbres to the higher and lower ranges of a channel that the music alternates between a bass part and a treble part, to reduce the overhead of making the most of limited polyphony, or anything else you can think of.

[GARTHWILSON]

commodorejohn wrote:

Quite right, and that's one of the advantages of the phase-accumulator design. I was speaking more in terms of simple linear down-counter designs like (for example) the NES pAPU, where the counter is simply loaded with a value and then decremented until it reaches 0, at which point the position within waveform is incremented. In that system, output frequencies can only be even divisions of the master clock rate, so that there are only two possible frequencies within an octave of the maximum rate, four within two octaves, etc. etc. But really my point is just that extra bits can still serve a purpose even if they don't get directly hooked to the wavetable address.

Ah yes, like trying to do standard RS-232 bit rates without a standard UART.  The faster you try to go, the more error you're likely to get in the rate, until it becomes unusable.

[BigEd]

It's notable, I think, that the Music 5000 has a 24 bit phase accumulator. I think that's an indication that 16 bits isn't enough. According to this, you'd need 23 bits if you were clocking samples at 48kHz. Of course, standards for 'musicality' are variable, unless you're selling your kit as a musical instrument.

[GARTHWILSON]

BigEd wrote:

It's notable, I think, that the Music 5000 has a 24 bit phase accumulator. I think that's an indication that 16 bits isn't enough. According to this, you'd need 23 bits if you were clocking samples at 48kHz. Of course, standards for 'musicality' are variable, unless you're selling your kit as a musical instrument.

I get a message that says, "You have either reached a page that is unavailable for viewing or reached your viewing limit for this book."  (The latter is definitely not the case.)  I can understand a 24-bit phase accumulator in applications like the professional recording studio I have done some repairs for where the owner has a digital noise generator for testing and has a one- or two-second repeat rate and generates the entire audio spectrum.  It would simplify certain things, but would take a table of a minimum of 100KB, ie, larger than the 6502's address range for just the one table.  One thing I'm thinking of is vibrato; but rather than hold tables with lots of cycles of sound to cover a full cycle of vibrato, the '02 would do better with just slightly varying the increment value about 50 times a second (for a maximum FM speed of about 6Hz).  Then the vibrato rate could be varied or stopped and started without changing a table.

[Chromatix]

Or slave one phase-accumulator's increment rate to another wavetable, for a much more space-efficient implementation.

[cynlic]

I think this question stems from my ignorance of some implementation details (I looked up a few data-sheets of various counters and was still confused) but if the phase accumulator is tied to the same Φ2 as the CPU, doesn't that clock-speed impact the lowest representable frequency? Taking Garth's example, using a 16bit accumulator to index into an 8bit memory address space, the slowest sample period is 1 sample per 256 16bit increments. But isn't the speed of that incrementation dependent upon the Φ2? It seems to me like you could easily overshoot and make it impossible to represent the lower frequency range. I assume that carefully adjusting the Φ2 and the number of bits used by the counter could result in something that’s “just right,” representing the necessary range of frequencies, but I don’t think that’s what everyone is saying should be done. Garth mentioned using the interrupt handlers to control when playback happens, but I still need to read the interrupt primer . In any case, I seem to be missing the more elegant solution that would handle this issue!

Chromatix wrote:

You can also try to use the wavetable RAM as a circular buffer for continuous playback; you'll need to be able to read back the upper 8 or 16 bits of the counter for that.

What exactly is the difference between a circular buffer and a buffer that is indexed by a counter that wraps over? It seems to me that if you’ve implemented the modulo operation that would wrap say, an 8bit address to a 4bit one, you’ve effectively tied the ends of a 16bit wide buffer together, right?

Garth wrote:

Speak up if/when you need a design for an anti-alias filter you can make with cheap, commonly available parts.

I’ll definitely need help with anti-aliasing at some point. I'm not too concerned now in as much as this design phase is pretty theoretical for me at the moment. Hell, I didn’t even know what was possible when I started the thread! Anyway, my current ‘lesson plan’ is to watch all of Ben Eater’s 8-bit breadboard videos (I’m about half-way through), then reading/rereading the primer. After that I’ll move on to deciding which kind of prototyping material to use, after which I’ll hopefully have a solid understanding of which design to use and why.

[GARTHWILSON]

You could have different instruments on different vibrato rates, as would be normal for musicians playing together.  There are more complicated things which although interesting, probably would not be addressed on a 6502-based synth, like the fact that with some instruments like flute and recorder, the color of the sound cycles with the pitch in vibrato, getting more airy and complex in the higher portion of the cycle.  We also have not taken into account the attack sound for beginning notes on various instruments; but again that's getting pretty complicated, and if controlled by a keyboard, would definitely need one that senses how quickly the key went down, or some variation on that theme.  Myself, if I really wanted all of that, I'd use a commercially available synth with MIDI, and use the '02 to feed MIDI commands.  Actually I have done this, although I only took it far enough to show that I could, not far enough to do real music.  I wrote a short tip about it at viewtopic.php?p=2313#p2313 .

[BigEd]

GARTHWILSON wrote:

BigEd wrote:

It's notable, I think, that the Music 5000 has a 24 bit phase accumulator. I think that's an indication that 16 bits isn't enough. According to this, you'd need 23 bits if you were clocking samples at 48kHz. Of course, standards for 'musicality' are variable, unless you're selling your kit as a musical instrument.

I get a message that says, "You have either reached a page that is unavailable for viewing or reached your viewing limit for this book."

Just for reference, then, this was the page I found:

From Digital Waveform Generation By Pete Symons

[GARTHWILSON]

cynlic wrote:

I think this question stems from my ignorance of some implementation details (I looked up a few data-sheets of various counters and was still confused) but if the phase accumulator is tied to the same φ2 as the CPU, doesn't that clock-speed impact the lowest representable frequency?

No.  Have your program set up T1 (timer 1) in a 65c22 VIA to produce an interrupt 16,000 times a second (or whatever your chosen rate is).  Whatever you decide to have doing the wave generation, whether software or hardware, it will increments the phase accumulators every time T1 times out.  The fastest rate is the φ2 rate divided by four if I remember correctly, and goes down to 2^17 φ2 cycles.  (I'd have to look it up again to get the numbers exact.)  The 65c22 really is quite versatile.  I have a lot of tips about it in the "Tip of the Day" column at viewtopic.php?f=7&t=342 .

Quote:

Garth mentioned using the interrupt handlers to control when playback happens, but I still need to read the interrupt primer .

There would be an interrupt for every sample period, or in my example, 16,000 interrupts per second.  Again, the '02 has magnificent interrupt performance, and this is a breeze for it to handle.

Quote:

Chromatix wrote:

You can also try to use the wavetable RAM as a circular buffer for continuous playback; you'll need to be able to read back the upper 8 or 16 bits of the counter for that.

What exactly is the difference between a circular buffer and a buffer that is indexed by a counter that wraps over? It seems to me that if you’ve implemented the modulo operation that would wrap say, an 8bit address to a 4bit one, you’ve effectively tied the ends of a 16bit wide buffer together, right?

Yes, treat it as a circular thing, although not really a buffer since you probably won't be writing to the tables during play.  256-byte tables are extra easy this way, since you can use the 8-bit X or Y index register to index into the table.  The modulo portion is taken care of automatically, and you don't have to shift or AND like you might have to with a 64-byte table for example.  If you start each table at a page boundary, ie, at address XX00, you won't even incur the one-cycle penalty for indexing across page boundaries.

[Chromatix]

Ah, what I meant by "circular buffer" was specifically for cases where you want to stream audio data continuously from some source, rather than using the sound hardware as an instrument. It's like a more general form of double buffering.

As for concerns about not being able to go slow enough - if you run into that problem in any practical scenario, just add more bits at the less-significant end of the counters.