DSP Robotics Support

One of the biggest issues Synthmaker had for creating good sounding synths was a lack of free running poly oscs (as well as other things, non linear envelopes for one) , well I think I may have cracked it with a very simple solution but as yet unoptimized.

This is just a prototype so the osc is just a basic saw with no bandlimiting. I am planning to create a wavetable version that takes a float array for the waveshape which should suit all needs.

The effect of a free running osc can be quite subtle but it makes the sound more 'organic'.

Let me know if this is working like you would expect and then I can get on with creating a super wavetable version

Stable and finished version now available on Flowstone Guru....

Free Running Polyphonic Oscillators

It is not working here... Using mem write primitive is always tricky. I have checked by changing the frequency to fixed very low value and conected the whole thing to a scope, so I can easily observe where the osc starts and ends. In both modes the phase resets.

KG_is_back wrote:It is not working here... Using mem write primitive is always tricky. I have checked by changing the frequency to fixed very low value and conected the whole thing to a scope, so I can easily observe where the osc starts and ends. In both modes the phase resets.

Thanks I was testing if the phase is written and read which it is. The problem I think is a stupid error in that I should be sample and holding the phase that is read, as it is now the phase is set for only the first sample.

Thought I could hear it working must have been placebo effect

I'm not at my machine now to test (won't be till tomorrow) but like I said adding a sample and hold for the phase should work.

The sample and hold code would be....

Code: Select all

polyin phase;
polyboolin trigger;
polyout startPhase;

startPhase = startPhase - trigger&(startPhase - phase);

Hoping that is the issue anyway could be wrong!

Yes, that, and the execution order is wrong... you need to read first and then write. Connecting the write primitive to the code component rather than the read primitive solves the issue.

I have found another issue - write primitive works only for fist SSE channel. so only every 4th voice phase is written... others remain intact. Therefore you need to use four of them an unpack the 4sse channels.

Here's a working fix

KG_is_back wrote:Yes, that, and the execution order is wrong... you need to read first and then write. Connecting the write primitive to the code component rather than the read primitive solves the issue.

I have found another issue - write primitive works only for fist SSE channel. so only every 4th voice phase is written... others remain intact. Therefore you need to use four of them an unpack the 4sse channels.

Here's a working fix

Thanks a lot for the help . I was assuming that the write primitive would be using SSE internally as the mono section uses it, guess there is no reason to and probably doesn't for safety reasons, so one channel doesn't overwrite another.

Guys this is really wierd, I wanted to detune two saws to check their phase, but they seem to get the same pitch even though they are independent. Also the scope is showing the oscs detuned but I get one saw output in my speaker. what the hell?

adamszabo wrote:Guys this is really wierd, I wanted to detune two saws to check their phase, but they seem to get the same pitch even though they are independent. Also the scope is showing the oscs detuned but I get one saw output in my speaker. what the hell?

You are detuning for less then one semitone - You'll not hear it as two independent tones - rather as one tone with flanging/phasing effect. It works perfectly the way it should - disconnect one of the oscs to hear the difference.

Ok I managed to make it work. Hmm, I think you guys are not doing it the correct way, or at least the way it works in every other synth. When I have two oscillators slightly detuned, their phase offset should follow their relative frequency speed. But in the examples posted, it seems random, so one might as well just use a random number generator which is much simpler. I have posted an example of what I think it should be like. Each oscillator should have its own accumulator that is the same speed as the ramp itself, and when one stops playing a key and starts again, the phase should continue where it left off.

Unfortunately since I had to use mono even though its poly it sounds best only with mono voices

Yes, that is the thing I have proposed. Current version saves the pases per pitch - so the phase will be recalled only when you press the same key - other keys have their own phase storages.

I have proposed a way that'll use memory queue to store phases. It would be a circular buffer. Every time you release the key, the phase is stored in the queue and queue end is increased by 1. Every time you press a key, the phase is recalled from queue start and start point is increased by 1. If start and end point are identical (which means queue is empty) zero phase is recalled instead.