simple sine oscillator without using sin1()

[tester]

Found a problem.

Schematic is made on both - biquad6 and SM stock sine. There is a sound oscillator, amplitude modulator and another modulator connected to phase node of AM. While stock sine works that way - modified version produces on my computer noise or rising loud dirty sound, that disappears.

SM stock sine accepts phase offset greater than 0-1, which produces greater modulation on phase node. Modified sine (biquad6) has a problem with that. Can this be repaired?

I also noticed, that sometimes modified sines (tested on biquad5, biquad6) stop working (or give a short sound and stop sounding) with no particular reason while other works fine (only some units, not all, usually one side), and this does not depends on input values in 0-1 ranges if there is suggestion on that. They get "restarted" when inserting modules into schematic (not always?), as if there was some triggering issue. Tested on intel CPU C2D.

[martinvicanek]

SM stock sine accepts phase offset greater than 0-1, which produces greater modulation on phase node. Modified sine (biquad6) has a problem with that. Can this be repaired?

Yes, with the sin1 cos1 approximations which I posted here.

[tester]

Thanks, but a project I'm working on - requires 3 input nodes - frequency, phase and resync. I have no idea where to add what in ASM code from "QuadOsc6.osm" uploaded above (cyto's upload on page 3) or how to combine them correctly. These asm parts are still beyond my comprehension.

[trogluddite]

SM stock sine accepts phase offset greater than 0-1,

While the code tinkers are at work looking into that one, here is a quick module that will "wrap" floats to the 0-1 range (i.e. getting just the fractional part)...

Wrap 0-1.osm

(12.44 KiB) Downloaded 158 times

Re: The stock sine innacuracy...
Don't forget also that the stock sine is only really a sin1 lookup table (65536 entries) with very basic interpolation (to keep CPU down). The amount of error in the interpolation will also fluctuate cyclically as the indices wander closer and further from the "datum points" at the integer indices. At very low frequencies, the samples will be spread out so far that the sine is approximated by a series of straight-line "segments".

[martinvicanek]

Yup, that's the quickest solution! By the way, you could even omit the "fiddle" trick as the ASM integer conversion works correctly for negatives. I know that some other implementations don't, and that's probably why Trog introduced this remedy in the first place.

[tester]

Doing a simple test on 50Hz tone and 400Hz tone - I can say, that frequency handling is inacurate, but this is regular pattern. Either frequency/time gets shorter or longer than real one. Is the wavetable responsible for only shape inaccuracy (stepped) or also for input frequency (time lenght of single cycle) handling? Something like +/- error depending on frequency? Isn't the time scaling beyond wavetable?

Regarding the conversions to 0-1 (in slow modulation module) - I think I forgot to add "trimmers" (min/max) on phase node in sound module or the intentnion mixed with imagination and logic failed. The general idea of smod was to trim values above thresholds, but I'm not sure if on phase node wasn't to just get smooth back and forth transition.

Now - in the project - there are c.a. 400 sine oscillators accessible right now. Can the amount of oscillators be related to the problem, that some of them break down or do not initialize? I'm trying to isolate the problem right now. Or can this be related somehow to mono4 primitive? (it is used to store left and right channel; left channel connected to node1 - tends to break down).

[tester]

Maybe this question sounds stupid to some people, but I ask it after finding the differences with my own ear and brief listening on non-studio headphones (so this is not a theoretical matter). What is the phase offsets in/accuracy (versus frequency I guess, range 50-1000 or to 3500Hz) in above developed sine productions?

I ask, because comparing audible differences between sonic patterns (10 pairs of stereo frequencies) created in cool edit and VST made of sinquad6 - the sinquad6 produces very unpleasant and noticable vibration/fluctuation. This could be either due to frequency instability over time or due to wrong phase settings.

But comparative/inverted mixng results - are stable in frequency domain (differential beats are much weaker than with using SM sine, although they are present too; small enough to make 5 minutes sound perfectly loopable), and audible sounds are very loud from beginning (different loudness on different frequencies), so this is phase offsets related issue. Can this be fixed? Are phase offsets from 0-1 range - linear (like time delay) or in degrees?

How the sine is created in cool edit then, so that there is so stable, precise and accurate? Can this accuracy be replicated? Even for offline VST exporting, so that digitally created sounds are fine (generally regarding phase offsets, there are simple math formulas working wround to make right sounds; so these values can be applied almost blindly).

It's not audiophilism, it's a simple gemoetry of simple sounds. Butterfly effect so to speak.

[tester]

I know that this topic is about making sine without using sin(), but after my initial experiments on sound and sound quality - I think it is worth to back to the origins. Remembering that there something was - I just found this:

http://www.synthmaker.co.uk/dokuwiki/do ... scillators

and following code:

Code: Select all

streamin frequency;
streamin phase;
streamin volume;
streamout out;
float a,b;
a = a + frequency;
a = a - (a > 1) & 2;
b = sin1(a + phase);
out = volume*b;


Not tested yet for quality (I check the freqency/phase accuracy when I'm on another computer), but I have following questions.
1. This one is accurate sine production, not wavetable based?
2. Can someone remind where to put resync node?
3. Can this be optimized (via ASM code) without loosing freq/phase accuracy?

Regarding optimizations I have a thought. Instead of optimizing single sine unit - wouldn't the theme work faster - if there was a cluster of sine oscillators created in one code/asm? Such multisine generator so to speak. I don't know - 16 or 32 per code? One resync piece of code for all - at least one optimization But maybe there are some common routines.

//edit:
Inaccurate frequency handling in code above too. Not loopable results. What is wrong with these codes? Is there no simple way to produce precise sine with precise frequency handling and precise phase handling?

[trogluddite]

1. This one is accurate sine production, not wavetable based?
2. Can someone remind where to put resync node?
3. Can this be optimized (via ASM code) without loosing freq/phase accuracy?

1) No - the sin1 funstion is the same 65536 entry lookup table.
The precision of the counter is what will determine the phase/frequency accuracy. This can be improved by using double precision numbers (e.g. look inside some of the sample player modules - you will find a "precise" counter in double maths).
But double precision is not available in code or assembly, and cannot work with mono4 data - so, in the interests of low CPU, I would imagine that the stock oscillators stick with single precision (though I don't know for sure).
This possibly explains the greater accuracy of CoolEdit - it may be using maths with greater precision for the counter (and possibly the sine function too).
In terms of the sine function itself - the only way to increase accuracy would be either a larger lookup table, or to use the super-precise fsincos opcode. As we saw earlier in the thread, using fsincos, while accurate, is extremely greedy for CPU - several orders of magnitude slower than a lookup table.
in fact, your code could well be less accurate than the stock osc', as it reads a only single lookup value directly without interpolation (i.e. there may be 'steps' in the waveform at low frequencies).

2) To resync, you just need to set the counter (a) back to zero, according to whatever rule you want for the re-sync input. The usual way it to look for rising edges (i.e. current sync input is greater than the previous one). Something like...

Code: Select all

a = a & (Trigger <= OldTrigger);
OldTrigger = Trigger;

3) I have done an optimisation on the sin1 function in the past - I'll see if I can find it. However, the CPU savings were quite modest, and it is not possible to improve the accuracy/function of the sine function this way. Again, it is possible that the stock oscillator uses more efficient code already (the dev's possibly have access to a wider set of instruction than we can use in code/assembly).

[tester]

Thanks for explaining.

I sent an e-mail to Outsim, we see how they react and when (next update)? If they are focused on Flowstone as a research tool, then they shoould be interested in improving research related tools. Otherwise - expensive toys not tools; sending a satelite to Venus will result that the rocket will land on Jupiter These small adjustments are important when dealing with frequency and time and predictable control of spatial (differential aka binaural which are slow rotations) and vibrational (chord-like) behaviours. For example - there is a huge difference whetner after 15 minues of playback - you still hear the audio track in center or everything is somewhere letf. Or whether you hear a progression of phantom tones or just a blurry blurness.

Anyway - right now, the stock sine seems to be the best choice due to proper phase offset handling (which is based on different than 2^n divisions). Not loopable tracks and lack of backward and intersoftware compatibility. After all these months - what a disappointment and shame... No wonder, that many market plugins (like harmonizers) have great cover descriptions with good intentions and poor quality inside. But if this quadsine will develop further, then there is a hope (as i said - frequency handling is much much better, allows to create loopable tracks, but phase handling still needs to be corrected) for better sound quality.

[cyto]

I'll admit to not having followed the most recent discussions here too diligently. But I noticed a few things in the last schematic tester posted that may be the source of some of the problems being discussed. First of all, there certainly is the issue of the "phase" going out of range. Any of the appropriate "wrapping" methods should fix this. But more importantly, I noticed that in the schematic, the phase offset is being continuously modulated by another sine. Even at the relatively fast hop of 32 samples, this will no-doubt introduce some distortion into the resulting audio signal. You are not getting smooth phase modulation, but rather stepped phase modulation. Could this be contributing to the latest issues you are having with the sine osc? One way to test is to go in and replace all of the lines that read and eax,31; and replace them temporarily with and eax,0;. If this alleviates some of your problems, I'd be happy to re-write the code for you to get rid of the hopping and also integrate the "wrapping" function. If I'm way off, then forgive me for bringing it up.

-cyto

[tester]

Cyto - whatever you do to improve the modified sine - I'd be happy to test it. I'm sending you PM something to test (PM system has some delay, so you probably get it tomorrow).

[DigitalWhiteByte]

Before putting all the pieces together, wondering if anyone has already done.

[cyto]

Before putting all the pieces together, wondering if anyone has already done.

Sadly, not me. Too many pots on the stove right now!

-cyto

[DigitalWhiteByte]

ok then, I'll try to put together all these wonderful optimizations!