Wavetable oscillator.
  • Greetings all... My first post.

    I cannot find any specifications for the planned 'sample' mode oscillator, so I'll submit this as a request for a wavetable oscillator.

    Many mainstream commercial VST instrument apps for PC & Mac as well as lesser freeware ones feature these as either a basis for the waveshapes or as a separate mode for added sonic variety. Sometimes with different table sizes (eg. 128,256,512,1024 bytes), sometimes fixed. Also the bit resolution - 8,16,24.

    Wavetables if not hard-coded into the app, can be imported from .WAV files.

    Could this feature be added to Audulus?
  • Hi @Nozokyo, welcome to the forum!

    Yes, I'm planning to do wavetable support :-) Actually the oscillators are already wavetable-based, its just a matter of adding UI to set the waveforms. I can't give you a precise estimate on when I'll get to it, but each request I see (and there have been several) increases its priority!

    cheers
    - Taylor
  • +1 for wavetable UI! would love to customize waves as mod sources for Envelope Following fx
  • Would be fantastic if you could also load in audio data into wavetables in realtime as well, like in Csound land...
  • @Alcomposer, that's interesting. How does that work?
  • A simple Csound example can be found here: http://iainmccurdy.org/CsoundRealtimeExamples/LiveSampling/TableRecBasic.csd

    Basically a realtime sampler.

    Csound uses ftables to store wavetables (or any single dimensional array data). Gen routines are used to create data for these tables, such as sine waves etc.

    So in Csound land- (as in Audulus land) a sine oscillator is simply a phaser reading out a waveform table.

    There a much more advanced uses of realtime ftable generation, and Csound has more custom made ugens for dealing with realtime audio acquisition & mutation etc.

    More info about Csound gen routines here: http://www.csounds.com/journal/issue12/genInstruments.html
  • @Alcomposer, ok I think I understand. One problem with changing the wavetable on the fly is that Audulus does pre-filtering of its wavetables to prevent aliasing. That's how I implemented the Oscillator node at least. The pre-filtering is a somewhat expensive operation and couldn't be done on a constantly changing wavetable. Does csound do anything to prevent aliasing as you, say, read through the wavetable at some multiple of its original sample rate?

    I suppose the anti-aliasing could just be turned off for realtime input.

    Do you think it would suffice to have a pair of inputs on the wavetable: one for write position, the other for value?

    cheers
    - Taylor
  • I found this: http://www.csounds.com/journal/issue6/BandLimiting.html

    I think that for what I was wanting (Break Beat Cutting etc) aliasing may not be an issue, but obviously for other material it would be… that article discussing using band limiting based on the estimated note output. (pitch detection)?

    Pure-Data has this to say on the subject: http://en.flossmanuals.net/pure-data/ch026_antialiasing/

    Oversampling sounds like a better approach, to me anyway… ;-)
  • @Taylor have you had a look at the code by Olivier Gillet for the Mutable Instruments Braids Eurorack oscillator module (see - see http://mutable-instruments.net/modules/braids )? There are several nice implementations of wavetable synthesis (and a lot of other oscillator models beside) in that, and Olivier has paid a lot of attention to band-limiting and anti-aliasing. And the code is open-source - see http://mutable-instruments.net/modules/braids/open - under a liberal MIT licence IIRC, so that not only can you study the code, you could potentially re-use some of it (with appropriate attribution, of course) in Audulus. It's all in C++ using integer maths because it is intended to run on a Cortex M3 processor (at 72MHz, I think), but I'm sure a naive port to the Apple platforms would be possible, even without re-writing the code to use floating point calculations. I mention this because I started to look at the feasibility of writing an AU plug-in based on the Braids code to run on Logic, outputting audio via ADAT to an Expert Sleepers ES-3 - see http://www.expert-sleepers.co.uk/es3.html (the ES-3 works fine as an audio output interface, as well as a DC-coupled CV interface), and thence processing and combining the signals through analog filters etc in my Eurorack modular (which already contains several hardware Braids). However, it would make much more sense to port some of the Braids oscillator models to the Audulus environment. Just a thought!
  • @bennelong_bicyclist, welcome! Good thought! Yes I've looked at the Braids code (I own a Braids actually), and it looks great. It could be used as-is, assuming the conversion to and from fixed point isn't a performance killer (I doubt it). I'll do some tests, and let you know!

    cheers,
    - Taylor
  • @Taylor - that would be fab! I've got three Braids (which I built myself, since not only is the code open-source, the hardware design is too), but I keep wanting more of them, for live performance, but there is a limit to how much hardware one can make, and if you always use a hardware modular with a computer (as I do), it makes more sense to use the Eurorack for things that are still best done in the analog domain, like vacuum tube distortion or idiosyncratic filters. Happy to act as a beta tester. I also have an Expert Sleepers ES-3 too which makes audio output from Logic at modular signal levels very easy.
  • I forgot to mention that Olivier even provides a target in the makefile for the Braids firmware that compiles just the bare-bones oscillator code using gcc (or clang++) and then calls from a test harness it to write a wav file, without even having to install the ARM cross-compiler for the Cortex M3 processor that Braids uses - thus the C++ code for the core oscillator functions runs fine on OS X without any modifications. Obvious much of the rest of the Braids code is hardware-specific, but you wouldn't use that in Audulus, of course.
  • @bennelong_bicyclist... 3 braids, that's awesome!

    Ok so the code was really easy to add to Audulus, and it seems to work, but I haven't got the scaling right for the inputs. Also, I need to upsample since the actual Braids hardware expects a 96kHz sample rate and Audulus usually runs at 44kHz. I'll just do 2x and see how that works.
  • @bennelong_bicyclist, thanks for the additional info! Afraid I figured that out after installing the dev tools :-\
  • @Taylor, OK, great! From memory, there are some hard-coded divisor constants in there for the phase accumulator etc than may need to be changed to run at a different sample rate. The input scaling is all done via pre-computed look-up tables created by some Python scripts. You probably have enough cycles to compute these on the fly rather than use look-up tables.
  • did this ever get finished?
    would love a Braids module in Audulus :)
  • Hey there!

    I would love to know if there's any updates on this front?

    I also own Braids and love it!!

    Imagine how powerful it would be to have many instances of Braids... Wow..
  • +1 for Braids in Audulus - that would be fantastic :)
  • Hi there,

    I would PAY for a Braids inside Audulus :->
  • Curious what form this took? I love my braids and wish I had that capability in audulus
  • So explaim this to me im a little ignorant but what do we need nodally to make wavetable? A sampler node? I assume spline doesnt cut it. Not familiar with this type of synthesis.
  • While it's not as good as the real thing, I did build an oscillator that allows you to draw your own wave:
    http://forum.audulus.com/discussion/834/new-oscillators#Item_2
  • @biminiroad Animoog, Waldorf Nave, and Poseidon all allow you to provide a wavetable that is 3d (width X time X amplitude), and you can select a waveform to play over and over by taking a slice along the width and using that as a table-lookup waveform. You can modulate the parameter that decides which slice you use, and that's one of the big differences between, say, Animoog and Nave.

    The simpler form is just a single cycle waveform with some magic that allows you to scale the waveform to various pitches. This article might be a good starting point on techniques you could use. https://en.wikipedia.org/wiki/Table-lookup_synthesis

    As far as nodes go, I'm not sure how this would work, since there currently isn't a UI for importing/attaching binary waveform data to a patch (e.g. for sample manipulation, etc).
  • @biminiroad Here's a pretty amazing resource for single cycle waveforms that could be used for something like this: http://www.adventurekid.se/akrt/waveforms/

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!