Wavetable waveform type

[cdromain]

Feature request & motivation

Had a lightbulb moment the other night, thinking we could have a wavetable available as a new waveform type, using the Morph parameter to move between the waves.

Implementation

• Wavetable would be a new selectable waveform type.
• A WaveEdit universal open source format wavetable file could be placed on the SD card, which would make it user-editable.

More ideas

• Ideally we could have several wavetables on the SD card and choose between them in one of Juniper menus.
• Would be great also to be able to choose between smooth or stepped transition between the waves within the wavetable.
• We could also have some digital control on the waves themselves, like aliasing, folding or bitcrushing ? Actually we already have the Wavefolder advanced function to build upon.

References

• An obvious and solid reference here would be Industrial Music Electronics Kermit MKIII, a wavetable-based modulation source.

[ost-ing]

Hi @cdromain ! A very early alpha version of Juniper actually had a wavetable waveform, and also an editor within the firmware to modify it - it was experimental but I decided to leave it at the time to focus on using the mod bus for complex waveform generation.

One thing that I'm wanting to avoid is conflating Juniper with an oscillator, which going into wavetable territory starts to do, but I do agree that having a wavetable waveform could be handy for creating more "fine tuned" shapes that the modbus cant easily achieve.

Regarding Aliasing and Bitcrushing: these would be advanced functions are would be out of scope for a "wavetable waveform".

Many features of WaveEdit seem overkill for CV, but a user could ignore those features. Then the Bank size is questionable: 1 Bank = 64 waveforms. 1 waveform = 256 elements and each element is 16bit. So this means loading approximately 32kB into RAM. Its doable and there is space for it, but I'm wondering if an entire bank is really necessary? I would have thought 8 waveforms would probably be enough for CV - then again, maybe I'm wrong.

I also like the idea of doing the editing of the wavetable in the firmware itself to bypass the computer entirely. The problem though is building an editor in the firmware you are limited by the encoder and from memory when I first played with this idea, its a PITA to dial in 16bit waveforms with an encoder without some heavy rounding or using percentages which makes it crude.

All in all, I like the idea and I think it would fit very nicely and easily into the UX. Like you suggested, its really just adding a new waveform and then using the morph function.

I'll have a think about this a little more and think about how it can maybe improve Waveform Modulation which I want to revise.

[cdromain]

Glad to see that we're on the same page and that you had the same idea from the start 😃

As I wrote in my max frequency feature request, I understand and respect you want to keep the focus on CV modulation versus audio oscillations. But yes, having a wavetable waveform type would be super cool for modulation and open up the possibilities even more - modulating the waveform itself ! (Waveform Modulation)

More feedback :

• 32 or 64 waveforms would be great - the more the better I think.

• As I suggested, I think having the choice between smooth and stepped transition between the waveforms could be interesting - even for pure modulation purposes.

• Having an editor on board would be the icing on the cake but as you said given the UI constraints it seems quite complicated - would still be nice to have though and am curious to see your implementation !

Again, thanks so much for improving what is already one of my favorite modules 🙌🏼 Can't wait for the next firmware iteration !