DSP Robotics Support

Using large green numbers for more accurate calculations in ruby. I'm thinking on extending accuracy between users interface and some internal green calculations.

Can this be simplified in ruby somehow, so that only string is given and rouding digits?

You can directly input string and internally convert it to float. I've used that technique to enter values into my IIR to biquad and matrix solver on the FS guru.

Thanks.

And now a little bit more difficult question. I'm starting to wonder if it's possible to create shape player (something like wavetable oscillator) using waveread - with higher and linear step accuracy. For example, to get things like 100.001 and 10000.001Hz right. But also, the goal is to get shapes played in a way, that it can be looped correctly. For example at 0.01Hz, looping should work per each 100 seconds (and this isn't happening with wavetable oscillator unfortunately), independent from given input frequency. As for aliasing - sharp lowpass filter at sampling border wouldn't be enough?

The thing is. If there are two signals at 10kHz, different by 0.01Hz, then with adding them - they will make 100 seconds long pulse. That's why it's linear.

tester wrote:Thanks.

And now a little bit more difficult question. I'm starting to wonder if it's possible to create shape player (something like wavetable oscillator) using waveread - with higher and linear step accuracy. For example, to get things like 100.001 and 10000.001Hz right. But also, the goal is to get shapes played in a way, that it can be looped correctly. For example at 0.01Hz, looping should work per each 100 seconds (and this isn't happening with wavetable oscillator unfortunately), independent from given input frequency. As for aliasing - sharp lowpass filter at sampling border wouldn't be enough?

The thing is. If there are two signals at 10kHz, different by 0.01Hz, then with adding them - they will make 100 seconds long pulse. That's why it's linear.

Well, in assembler there are FPU operations that use 80bit float. and you may input higher precision values when you somehow split them into multiple parts (look at the double precision module pack at FS guru, or the way I entered 32bit int looselessly to stream). So it certainly is possible, but it will be CPU intensive (we can't use SSE for this, so only per channel processing)

Define "CPU intensive". Ruby-made simple precise sine - takes 20% of 2GHz CPU, while stock ostillator uses I don't know, 0.6%?

First I need to check if what I think makes any sense. As for sines, I remember, cyto on SM forum did a sine generator for me in the past, and it produced loopable results (there was some phase offsets problem however) and it worked at 0.01Hz accuracy well (no back and forth few samples, like with the case of wavetable oscillators). Actually, the 0.01Hz level of accuracy was rather a result of dealing with presets and automation stuff, but it's a different story. So the first step will be to see, if it's possible to get free running shape oscillator, that is loopable at this level, and whether it will produce relatively clean sound (with filter added on output), when scaling the playback speed up. I probably will get back to this in a few days, now have some other work to do.

Here's an ramp oscillator with phase and sync that operates in 80bit float.

Hey KG, while I'm stuck right now for a while with other non-FS related stuff - could you take some time to create wave read module, that uses large accurate numbers (and has phase offset setting and resync node like stock oscillators)?

*

A few thoughts of further things to check (for me), but it might be useful for others too.

I'm not sure yet (did not tested it), but my guess is, that it will be better to use larger waveshape files (2000 samples or more, to have very low basic frequency at ratio 1:1) for upscaling with ratio into audible ranges. Instead of starting with small shapes (= high freqs) and scaling them down. [But since such explorer would be for both - shapes and loops, then I guess it would be good to have on board the version that does not have the 6.5 min limit]

I'm not sure if for upscaling interpolation is needed, but if so, then my guess would be that b-spline interpolator should give clearest results (it does when playing with downscaling).

But basically - my guess is, that some sort of lowpass filter should be added around the SR/2 border, to avoid introducing artifacts when getting higher pitches (also not tested).

tester wrote:Hey KG, while I'm stuck right now for a while with other non-FS related stuff - could you take some time to create wave read module, that uses large accurate numbers (and has phase offset setting and resync node like stock oscillators)?

*

A few thoughts of further things to check (for me), but it might be useful for others too.

I'm not sure yet (did not tested it), but my guess is, that it will be better to use larger waveshape files (2000 samples or more, to have very low basic frequency at ratio 1:1) for upscaling with ratio into audible ranges. Instead of starting with small shapes (= high freqs) and scaling them down. [But since such explorer would be for both - shapes and loops, then I guess it would be good to have on board the version that does not have the 6.5 min limit]

I'm not sure if for upscaling interpolation is needed, but if so, then my guess would be that b-spline interpolator should give clearest results (it does when playing with downscaling).

But basically - my guess is, that some sort of lowpass filter should be added around the SR/2 border, to avoid introducing artifacts when getting higher pitches (also not tested).

The best solution to the wave table oscillators is the one that already in FS. When you input an wave shape to a wave table prim, the prim creates a set of tables. The first table is identical with the inputted shape and each next has one top harmonic removed (using Furrier transform). The next to last one is a single sine wave (the fundamental frequency) and the last one is complete silence (or only a DC). Within the wavetable osc firt thing the prim does is, it decides (based on the input frequency) which table to use so it does not produce any content above Nyquist (which would result in aliasing).
So when scaling up, you indeed need to lowpass by SR/2 to prevent aliasing (in the stock wavetable prims this is precomputed within the tables as explained above).
When scaling down no such lowpassing is needed.
In both cases though you need good interpolation. Imagine you have a wave table [0,1,0,-1]. If you look at it carefully and analyze it with a FFT you will see that it basically contains only one sine wave (a first harmonic = 2*fundamental frequency). If would would input this into a wave table osc then at frequency 0.25 it would indeed produce a sine wave [0,1,0,-1,0,1,0,-1,0,...], but with linear interpolation on lower frequencies it would produce a triangle wave (which is obviously not a wave with single harmonic) - you need better interpolation to "smooth" it to a sine wave when playing on lower frequencies (which in fact means you are upsampling the wave table). If you would use bigger wave table that would also contain only one sine, the result would be much better even with linear interpolation (the output at lower frequencies would indeed be close to a sine wave), but still some distortion would be present.
The very same thing happens when playing at higher frequencies, but it is harder to imagine since frequencies above 0.25*samplerate do not translate into samples so intuitively.

With perfect interpolation (which in fact exists and is called sync interpolation) the size of the wave table only affects one thing - the number of harmonics the wave table has. The math is really simple: no. of harmonics = no. of samples /2. That is what Fourier series (and Fourier transform) is all about. THe smallest wave table of a sine is [1,-1]. With perfect interpolation it would give you a perfect sine wave at any frequency - and a sine table of any size would too.
With nonperfect interpolation (like the linear interpolation is) you need to cheat a little - bigger wave table = more samples = smaller gaps to interpolate = smaller errors. Now obviously, with linear interpolation wavetable [1,-1] would produce a triangle wave and with each increase in wave table size, the result would be closer and closer to a sine.
So to make long story short, all your concerns and assumptions are correct.

To the topic of a custom wave table read - there is one here. Based on the rest of your post I assume you mean a wave table oscillator.

Thanks for technical details.

Basically - I need relatively fast, universal oscillator (with phase setting and syncing), that can use any kind of signal shape or loop, and operates smoothly in wide range of frequencies. In audible range (let say above 30Hz I guess) this means clarity of sound (which probably ends below 10kHz anyway). In non-audible range (from let say 0.001 to let say 100Hz) - this means relatively smooth modulation routines (how many steps per second it would require to create a smooth transition? 15-100fps?). Maybe this simplifies few things.

What I also do need - is a way to give the oscillator precise numbers above standard float resolution, being able to produce slow differential waves (let say over10kHz at 0.001Hz resolution = 1000 seconds period) via sound synthesis (adding two sounds). Another problem I have with stock oscillators is - they are producing few samples back and forth differences, depending on frequency; I need an oscillator being able to produce a wave, that has precise length (at 0.001Hz resolution it is 1000 seconds and no sample more or less), to automate looping.

The general problem with sound synthesis at 0.01 "or more" resolutions is - that phase differences that come from inaccuracies - will screw the panorama scenes of a stereo fields.

Universal oscillator is always good for universal experimentation.

There are sharp butterworths here, so I guess such single unit could be used above 16kHz, giving similar result like FFT-based frequency removal on wavetables. I basically play with blue units and this has nothing to do with midi nor poly.

Is this sync interpolation doable here?