8 voice poly with wavetables

C

craigyb

Active member
This was my first attempt at an 8 voice poly using the Teensy Audio library, I wanted a stable front end for the DCOs but real analogue filters, so it's a hybrid. The Teensy 4.1 takes care of the three DCOs per voice, two LFOs, pitch envelopes and a noise source. The outputs of each three DCOs and noise source is then fed to a TDM device with 8 outputs. An analogue filter hangs off each output and has a hardware envelope and a VCA with it's own envelope. All the input controls are read by MCP23017 port expanders and 74HC165 shift registers (simply as I ran out of input pins for the buttons). I used encoders over pots for stability and instant recall of a parameters position. The teensy also drives 32 DAC channels for CV voltages such as filter cutoff, key track, envelope settings, velocity levels etc. The final audio mix is then sent to an FV1 effects unit with 32 effects algorithms and multiple variations with 3 pots. All settings are stored on SD card on the Teensy along with 4000+ wavetables that are loaded into ram on startup, I use an 8mb PSRAM to store the tables. Wavetables are full of waveforms in groups such as pianos, epianos, elec organs, bass, eguitar etc

Only thing it's missing is polyphonic portamento which I think I need to add, but I'm short of controls, so I might make the xmod encoder switchable between portamento and xmod by pressing the encoder button.



It's available in it's current form on my GitHub page.

github.com

GitHub - craigyjp/Teensy-Hybrid-TDM-Synth: Teensy Audio Library meets analogue filters

Teensy Audio Library meets analogue filters. Contribute to craigyjp/Teensy-Hybrid-TDM-Synth development by creating an account on GitHub.
github.com github.com

And a video of some of the sample sounds are available on YouTube. These sounds were made before I retuned the filters after a hardware mod, so they are not perfect, but you get the idea.

 

Attachments

  • 20251020_170322.jpg
    20251020_170322.jpg
    214.6 KB · Views: 23
Nice idea (mixing analog filters with everything else being digital). Proper 'analog' sounding filters are indeed the most tricky things in digital domain. One question: how did you make the front panel?
 
Last edited:
I got stuck into it again this evening and added polyphonic and monophonic glide, the xmod encoder can switch between xmod depth or glide time.
 
Awesome. I have presently designed a polyphonic synth using the Teensy 3.2. All analog signal path.

Iliad | Artisan Technology Workshop

artisan-technology-workshop.com artisan-technology-workshop.com

Tons of parts. I was thinking of using the Audio Library to replace just the analog oscillators. BUT, I am worried about aliasing. And I see no updates to the library for 6+ years! No polyBLEP module...
How does your instrument deal with aliasing, especially for PWM and Hard Sync? (I tried it out yesterday, bad aliasing!).
Any new modules out there for the Audio Library?
Thanks for any ideas before I move forward with this redesign.
 
Michael Bachman said:
I see no updates to the library for 6+ years!
Click to expand...
I don’t know where you’re looking, but this link shows more recent updates than that. Admittedly the release cycle is only when Teensyduino gets updated, which is glacially slow; and actually implementing version numbering is apparently not a thing, so it’s hard to know what progress is being made…

Michael Bachman said:
No polyBLEP module
Click to expand...
Maybe you could write one, then? It doesn’t look too hard on the face of it. I assume you’ve tried the band limited waveforms and they don’t work well enough for your purposes.

If you try it, you’d be doing future users a favour by using integer maths and the DSP instructions, which should keep CPU load under control, allowing plenty left for effects and polyphony. The existing waveform objects should be a good example to learn from, though you’ll find the DSP instructions are only used for the modulated versions.
 
FWIW: PolyBLEP requires floating point for those polynomial based step corrections, even if the rest of oscillator is integer based. Come on it is nearly 2026 and Teensy 4.x can do single precision floating point almost as fast as integer. The library should move to floating point for quality. 16 bit audio processing that the library is based on is a problem. It was great for Teensy 3 or lower. But now it is limiting. For example reverb suffers from integer only implementation.

That is one of the reasons why I don't use audio library at all. I do all processing in 32 bit float and the performance is great on Teensy 4.

Just my 2 cents worth.
 
Last edited:
@h4yn0nnym0u5e . Sorry, I did not see any new modules in the Audio Library. As you implied, these updates/fixes are not well known. I will look around that repository more and see what necessary updates I might be missing.

As much as I love the Teensy (and I do,) and the Audio Library is a cool feature, I, like Thomas feel it is in need of a revamp for the Teensy 4 (especially since you can no longer buy the 3, which killed a 3+ year project of mine, as listed above).

As more of an analog guy, that has written 1000's of lines of code for the Microchip dsPIC and Teensy 3, that still does not make me the person for this job... but I will try to fit in a BLEP function.

Here's the big reason: I did use band-limited waveforms and it works great for fixed shapes, like a Saw. But PWM, wave-folding and hard sync need BLEP to work IMHO. You could make a 1000 waveforms for all the different Pulse widths and wave folds, but hard sync I think would be tough to impossible. In Analog, these are all simple and add a lot of great tones to the oscillator section. I cannot see making a synth without these features.
 
Michael Bachman said:
@h4yn0nnym0u5e . Sorry, I did not see any new modules in the Audio Library. As you implied, these updates/fixes are not well known. I will look around that repository more and see what necessary updates I might be missing.

As much as I love the Teensy (and I do,) and the Audio Library is a cool feature, I, like Thomas feel it is in need of a revamp for the Teensy 4 (especially since you can no longer buy the 3, which killed a 3+ year project of mine, as listed above).

As more of an analog guy, that has written 1000's of lines of code for the Microchip dsPIC and Teensy 3, that still does not make me the person for this job... but I will try to fit in a BLEP function.

Here's the big reason: I did use band-limited waveforms and it works great for fixed shapes, like a Saw. But PWM, wave-folding and hard sync need BLEP to work IMHO. You could make a 1000 waveforms for all the different Pulse widths and wave folds, but hard sync I think would be tough to impossible. In Analog, these are all simple and add a lot of great tones to the oscillator section. I cannot see making a synth without these features.
Click to expand...
I tend to agree a sync function is missing from the oscillators. Would be nice to have.

This synth although it's turned out well was more of an experiment than anything else, it gave me an opportunity to use the audio library, maybe not extensively, but I learned a lot. The analogue filter/VCA boards I had built over a year before and they were just gathering dust in my spare projects drawers until I found a suitable front end to drive them with. Again I built these to use up stock of AS2164 chips that I had from previous synth builds until I switched to more usable AS3364 chips.

If anyone is interested a colleague of mine is creating a set of PCBs for the synth, it might be a few months before they are available but they are certainly in development.
 
Last edited:
@Michael Bachman, you're pretty much right, there's a distinct lack of new modules in the Audio library, though a fair amount of tweaking and bug-fixing has taken place. If you look at that repo you'll not only see that a lot of forks have been made, but also a large number of issues and pull requests, which may give a pretty big clue as to why there's not much apparent movement. Subsequent to passing Teensy manufacture over to SparkFun in March 2025 (this year, just), Paul wrote:
Paul said:
we’re anticipating being able to participate in more community and project-focused forum conversations.
Click to expand...
but I fear that anticipation has pretty much failed to materialise. Certainly the Teensyduino release cycle has extended massively, and very little repo maintenance has taken place. A couple of reasons for this have been more or less evident if you look closely, but if you didn't do that you'd be forgiven for thinking there's very little enthusiasm left (for any aspect of Teensy, not just the Audio library).

As a result of all that, I myself am not doing as much as I could, unless someone comes up with a problem I happen to find interesting. I currently have nearly 20% of the open Audio library PRs, with just one being a significant new module and the rest being improvements or bug fixes. One of those very nearly got merged ... 3 years ago!

So, if you feel the motivation to do so, I think the only way a BLEP module is going to get into the library (or at least your fork of it) is to do it yourself. I'm not at all convinced that using floating point is required, but equally, if it does the job you need, or at least gets you off to a good start, why not? A huge amount of the library works to most people's satisfaction on fixed-point integer arithmetic, and "almost as fast as integer" is not the same as "as fast as integer": I put in some effort over on this thread to keep the audio CPU load down to 88% on a 12-poly synth running on a Teensy overclocked to 816MHz. Sometimes, every cycle really does count.
 
FWIW: I have 16 voice polyphony, each voice 3 band-limited polyblep oscillators, 4 envelopes, 3LFOs, two ZDF filters with nonlinear saturation, flexible mod matrix, effects units all running on stock 600MHz Teensy 4 all in floating point written from scratch, no audio library. So it is not a matter of floating point vs integer.

Yes in certain cases integer is faster if you don't do lots of scaling. Integer addition is faster than floating point, but if you need to do argument/result scaling/shifting (that you get for "free" with floating point unit), then your integer code might not be the most efficient solution. As usual the answer is "it depends" . Also as I mentioned earlier, recursive algorithms sometimes suffer when resolution of data is 16 bit. One of examples if reverb implemented in the library that simply sounds bad.
 
Last edited:
tomas said:
FWIW: I have 16 voice polyphony, each voice 3 band-limited polyblep oscillators, 4 envelopes, 3LFOs 2 four pole ZDF filters, flexible mod matrix, effects units all running on stock 600MHz Teensy 4 all in floating point written from scratch, no audio library. So it is not a matter of floating point vs integer.
Click to expand...

Do you have a link to this creature
 
@h4yn0nnym0u5e
"but I fear that anticipation has pretty much failed to materialise. Certainly the Teensyduino release cycle has extended massively, and very little repo maintenance has taken place. A couple of reasons for this have been more or less evident if you look closely, but if you didn't do that you'd be forgiven for thinking there's very little enthusiasm left (for any aspect of Teensy, not just the Audio library)."

Those are scary words. The teensy3.2 left me high-and-dry and the 4.0 is already getting old without any updates in recent times. I am worried that the Teensy is approaching a dead-end. I have oft considered just going to a rPi or Pico as they seem to have huge support. You can run PureData on the Pi. Korg uses the Pi in their new WaveState and FM synths.

I'll keep testing the Audio library and comparing to my existing analog poly. I'm not giving up yet,
 
Pico2's RP2350 (2x150MHz) is still HALF the speed of Teensy 4 (600MHz), has half RAM (520K vs 1M for Teensy) not to mention that Teensy 4 is way easier to program, so Teensy still has all advantages except the price.
 
Yes, it is dual core but each core is 150MHz. So as I wrote before it is 2x150MHz. It is HALF of performance of Teensy 4 and it is more difficult to program as when you really need those CPU cycles for single really complex real-time calculation, single thread programming is conceptually way easier than dividing single job for parallel execution.
 
If I went to a PICO, I would expect to use more of them.

Right now, I hope to get at least 12 complex oscillators, 16 ADSRs, 16 LFOs, a huge mod-matrix, 12 PWM/CV outs and CAN commination on 1 TEENSY 4.0/4.1.
 
You must log in or register to reply here.
Back
Top