Motherboard comes today. Now we can test it in combination with the CPU board .
I am hardworking solder on…
VCA, MicroAmp, Delay-circuit and Midi is function. Now I solder the stereo filter board (12dB LP/HP/BP) for testing before a PCB is made.
Great work So much looking forward to try it myself eventually
The 12dB Stereo-Filter Board for Degenerator is ready. This is a 12dB stereo multi-filter with switching to LP / HP / BP. The second filter board (SMR4 Pole mixing) is currently developed.
Degenrator with Filter Board
The three LFO LEDs are driven in PWM-Mode on the 74HC595 chip.
Video link: LFO-Led in action
Rolf > How many bit resolution has the PWM signal for VCA and VCF in your shruthi synth?
Pichenettes > 8
Rolf > I do it same way and have disturbances in vca output. My PWM out is 8Bit/125KHz.
The envelope value in envelope function is 16Bit.
Test CV out for VCA: CV_VCA1 = Env1_value >> 8;
Ok… i found the problem.
I have set the high resulation flag in the pwm control register
HIRESD.CTRLA = HIRES_HREN_TC0_gc;
The PWM frequenz was 500.000KHz. Its to high!
I have clear the flag and now i have 8Bit/125KHz PWM frequency and sound is nice :))
Hi… I have a little problem with sample buffer in my synth. The buffer size is 256 bytes. When I press two different notes then I hear a glitch sound (see pic). the sample rate for audio_out is 25usec. The buffer fill rate is about 4msec.
I could make the buffer smaller < 64 Byte but then I have other things less resource. Is there another possibility ?
I have try with a 64Byte sample buffer. Now… i can here a little glitch sound (870usec) from first note in the buffer (see pic). I think its not good result.
But… I have another idea! In another post I discuss with pichenettes over mute bytes (128) in the audio buffer if the vca gain < 2.
Now…my new idea: If I delete the sample Buffer after the release phase of a note, then should not the old notes in sample buffer ? I will try this…
It seems to me that your issue is simply that the CV generation path doesn’t have the same latency as the audio generation path. So your VCA envelope goes immediately to its maximum level as soon as the note is received, but the oscillator’s audio buffer still has several hundred samples to play before registering the new pitch.
What about buffering (or just delaying) the CVs, so they have the exact same latency as the audio samples?
How it works in your shruti synth?
I find two buffers in your code. The first buffer is filled with sample datas from oscillator render. The second buffer is filled when you calculate voises. In a 39KHz timer interrupt you send datas from the second buffer to pwm_out ?
In the Shruthi code, the buffer size for the oscillators is only 40 samples long (1ms).
Every time a new buffer needs to be rendered:
- I update the (software) values for envelopes and modulations.
- I do the oscillators rendering in a new buffer (the rendering takes between 0.5ms and 0.8ms).
- I update the CV outputs.
So there is at most a 0.5ms difference between the change in the oscillator pitch and the change in the CV. Considering the delay introduced by the CV low-pass filtering, this almost eliminates the problem.
Ok. Thanks for your information. This is a good result
I solved the problem for the CV outputs. My mistake was that: I have calculated the note frequency in the envelope task. This was too late and the buffer has old rendering values.
Every 1msec (interrupt task) i check midi_ events and calc note freuenzy for the oscillators
- after that i fill buffer (64Byte) with new oscillator rendering values
- after that i update envelopes values and cv values for modulation
Every 25usec (interrupt task) i read buffer values and send to dac outputs.
Pic: yellow is Midi data and blue audio output
In my 1 year old 70MHz Siglent scope SDS1072CML is the backlight broken. Well I have warranty and have changed it with little more money into a 100MHz scope SDS1102CML +. The Plus version has some improvements larger TFT resolution 800 × 480, a redesign of the controls, LAN interface and more memory for the recording function, and more memory for the recording function. Its a very nice Low-Budget sope :))
PS: The violet color of the second channel is too dark. In my old Scope the color was light blue and better seen
Today… I’ll tell you a little bit of buffer size and CPU resources
In Degenerator is much expected as real-time calculation of two oscillators, sampling, 3 LFO’s, 2 Envelopes, Modulation Matrix, Graphical User Interface, Oscilloscope function and more. The processor resources from my “fast” ATMEL MCU (32MHz Xmega128A1) are unfortunately very scarce and I had to search for intelligent solutions to make everything work quickly and shorter. For later development we may need more CPU power, the replacement of the CPU board is designed for a board with a powerful ARM processor or similar.
The calculation routine for the oscillators (Pic 2 violet) requires 41% of the entire computing power in Xmega MCU. All 25 usec are two oscillator values (yellow) sent from a buffer to the two DAC outputs on Xmega. This will take about 1 usec and corresponds to a sample rate of 40KHz. Since it would be not efficient the oscillator values all 25usec recalculate (I did it before). Now… I use a doublebuffer function to calculate and save values for the oscillator. In a 25usec timer interrupt read oscillator values from buffer and sent to the DAC. Theory is simple but it is a bit complicated to program. The buffer is actually two double buffer with 80 bytes for both oscillators. I illustrate the operation of the doublebuffer function for one oscillator.
Image 1: Doublebuffer
Function mode of doublebuffer
Image 1: The closed circuit illustrates the sequence, as in a constant repetition after the second buffer again, the first follows. Each buffer holds here 40 samples, corresponding to a latency of 1 ms. As this 1ms arise is easy to understand. When starting playback, the cursor is at the point marked. 0 Since the start of the reproduction of the first buffer has been playing the software copies the data first into the second buffer. Imagine (in slow motion), as the pointer moves clockwise. At a sample rate of 40 kHz, 40 samples are processed in only 1 ms. When the pointer reaches the boundary between the buffers (position 1) an interrupt is triggered, and the software calculates the next 40 samples and stores them in the (now processed) first buffer. The second buffer will be played at the end (position 0) an interrupt is triggered, Sampels be calculated again and copied into the second buffer … The whole buffer repeats itself endlessly.
Figure 2: Time interval of the buffer function
Yellow: 25 microseconds interval for sample output to the DAC (approximately 1usec)
Violet: 1 ms interval for the calculation of 80 samples (approximately 412usec)
In the next post the topic buffer and Midi goes latency
Best wishes from Germany. Rolf
Interesting. Double buffering is indeed very useful, not only in audio. User interface engines on desktop computers use it as well to draw on one buffer while another is sent to the diaplay. It is also useful when you have to separate a high priority hardware related task (e.g. sending data to the DAC or display) from the lower priority task that refills the buffers. The two can run separately and the only point of synchronization is when the buffers are swapped.
What happens if the buffers are swapped before the buffer-filling routine has finished?