007- The Data Stream

The Data Stream for the DAC (digital analog converter) is crucial to understand. Without it we can not make any sound!
This video is one of many in a series that educates how a DIY Virtual Analog Monosynth synthesizer, called the “BP Synth”, was programmed.
Go here to find the BP Synth Code Tutorials Playlist:
• BP-Synth Code Tutorials
To see how to build the BP Synth you can go directly to the Playlist:
• BP Synth.. a DIY Virtu...
Links (AKA “Resource Tab”)
==================================================================
You can download the "BasicSaw" Project Folder directly from here:
drive.google.com/file/d/1zhhM...
You can find Atom here:
atom.io/
==================================================================

Пікірлер: 5

  • @davidkain9046
    @davidkain9046 Жыл бұрын

    nice video.what do you think about the implementation of the sampler on the BP?

  • @Synthetech

    @Synthetech

    Жыл бұрын

    It can be done. There is already a simple Sine Wave wavetable used as the LFO for the phaser.. I did manage to convert 8bit wavetables from a Korg DW 8000 and play them on the BP Synth... needs more RAM to pull it off though.. but possible and proven! PS.. it can also do some basic 4op FM synth too.. but it's not in this version ATM

  • @afonsusmuralha
    @afonsusmuralha11 ай бұрын

    Congrats for the synth series, very interesting and infomative. I might have missed this on the videos, but why compute samples for the whole buffer array? Since the oscillators frequency can changed at any time due to an external input, shouldn't samples be computed one at a time, once per sampling period, and have only a 2 sample buffer? Thanks!

  • @Synthetech

    @Synthetech

    11 ай бұрын

    Thanks for your interest.. we need to keep the buffer full so it can stream HALF the buffer out while the other half is written in by the CPU. Every time the DMA reaches a halfway point in the buffer(one in the middle and one at the end), it triggers an interrupt to make the CPU fill up the half that it just streamed out while it keeps on streaming audio out from the other half. The DMA is feeding the audio data out a lot slower than the CPU will write it. Unless too much is asked of the CPU to do while it keeps updating the buffer (a buffer underrun condition that would cause clicks/noise). Samples are computed one at a time, but in groups of 1000 each time the interrupt routine is called(those halfway points in the buffer).. 500 for Left channel and 500 for Right. Each sample is computed with the most current frequency every time each sample is rendered. This interrupt routine (CPU writing samples to buffer) is very low priority. But a MIDI Note On command received on the MIDI Port will trigger a higher priority interrupt than the sample rendering process. This higher priority interrupt will immediately change the frequency value. Once the freq. value is updated, when the CPU returns to writing samples it will immediately write them at the new frequency. Hope that all makes sense for you.

  • @afonsusmuralha

    @afonsusmuralha

    11 ай бұрын

    @@Synthetech I see. That's makes sense if the change on the osc comes from a midi message. That way you can compute all the required samples at a time and leave the CPU free for other tasks (such as uart, gpio, etc). Imagining the case that a change on the osc is made by reading an input (such a frequency change depending on a value of a potentiometer). In this case, computing a whole set os samples would introduce a delay between the user input and the output change, so it would be preferred to be always computing individual samples, right? I guess that optimizing this process is not a trivial task, specially when you start factoring in asynchronous inputs (such as midi) and continuous input (also considering input sampling frequencies, which I didn't consider in the last example).