Shruthi-Synthesizer and my "WAVE 1"


#1001

More test sounds from Degenerator


#1002

Motherboard comes today. Now we can test it in combination with the CPU board .

Greets

Andre’


#1003

Hi guys
I am hardworking solder on…


#1004

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.


#1005

Great work So much looking forward to try it myself eventually


#1006

Hello everybody…

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


#1007

The three LFO LEDs are driven in PWM-Mode on the 74HC595 chip.

Video link: LFO-Led in action


#1008

Rolf > How many bit resolution has the PWM signal for VCA and VCF in your shruthi synth?

Pichenettes > 8 :slight_smile:

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;


#1009

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 :))


#1010

@pichenettes

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 ?


#1011

Hallo…

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…


#1012

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?


#1013

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 ?


#1014

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.


#1015

Ok. Thanks for your information. This is a good result :slight_smile:


#1016

Hello friends

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.

My result:
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


#1017

Hi friends…

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


#1018

Hey friens

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
image

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


#1019

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.


#1020

What happens if the buffers are swapped before the buffer-filling routine has finished?

a|x