dan b

I'm trying to write some chaotic iterative oscillator externals in C (simple things that almost certainly already exist like Henon Map, Gingerbreadman map etc, but the goal at this stage is for me to learn coding and DSP through doing something I find interesting).

I've found it pretty straightforward to get the oscillators working at a fixed iteration rate (eg. equal to the host sample rate or 1/[int] x the sample rate).

What I'd now like to do (the more challenging bit) is make the iteration rate of the function freely variable - which I guess means interpolation because my the iteration of my function will be running at a different rate to the sample rate, and so the timing of its outputs will more often than not fall between samples.

All the resources I can find on interpolation start with a band-limited waveform at fixed sample rate, whereas I (effectively) need to fit a signal running at arbitrarily variable sample rate into a fixed sample rate, so I've had to freestyle a bit, and I'd like to see what people think of my planned solution:

First off, I'm thinking it makes most sense for me to start with a higher sample rate than the host app because then the calculated time points from the algorithm will be closer to the time-points of the sample grid and there's less room for adding interpolation noise.

1) calculate the values of the function for the vector,

2) interpolate the values for the two adjacent (over)sample-rate points for each value from the function

4) low pass and reduce rate to the host sample rate.

Does that make sense? There's plenty of "black box" within that, that I'll need to decide (which filter, which interpolation, etc.) but as it stands there any obviously bad ideas in that scheme? Is there a better way of doing this? Are there any specifics I should bear in mind?

Also, can anyone recommend a good introductory book/resource on DSP theory that talks about oversampling and interpolating? I've been reading Olli Niemitalo's "elephant" paper on interpolation which is great on solutions, but I'd like to understand the basics a bit better rather than just nick his code.

(I think I can fairly easily hack together a linear interpolating version without any oversampling and to be honest I suspect - given the noisiness and "unnaturalness" of the functions, that might just be fine. But I'm using this to learn, so I'd also like to think my way through to a more sophisticated solution, even if in the long term I decide the cheaper solution is fine. )

I'm trying to write some chaotic iterative oscillator externals in C (simple things that almost certainly already exist like Henon Map, Gingerbreadman map etc, but the goal at this stage is for me to learn coding and DSP through doing something I find interesting).
I've found it pretty straightforward to get the oscillators working at a fixed iteration rate (eg. equal to the host sample rate or 1/[int] x the sample rate). 

What I'd now like to do (the more challenging bit) is make the iteration rate of the function freely variable - which I guess means interpolation because my the iteration of my function will be running at a different rate to the sample rate, and so the timing of its outputs will more often than not fall between samples. 

First off, I'm thinking it makes most sense for me to start with a higher sample rate than the host app because then the calculated time points from the algorithm will be closer to the time-points of the sample grid and there's less room for adding interpolation noise.
I guess from there I'll:
1) calculate the values of the function for the vector,
2) interpolate the values for the two adjacent (over)sample-rate points for each value from the function
3) zero stuff the remaining points
4) low pass and reduce rate to the host sample rate.

(I think I can fairly easily hack together a linear interpolating version without any oversampling and to be honest I suspect - given the noisiness and "unnaturalness" of the functions, that might just be fine. But I'm using this to learn, so I'd also like to think my way through to a more sophisticated solution, even if in the long term I decide the cheaper solution is fine. )


iterative-oscillators-and-interpolation

Generally when making oscillators at a low level, whether band limited or not, one starts with a ramp between 0 and 1 with an increment size of fc/sr, then applies functions to this, the 'phase accumulator,' to form different waveforms. if sr is not =samplerate it doesn't make any difference, it should still work the same way. There's a dozen different ways to make the phase accumulator without significant difference, and often when people show c++ code for band limited functions they assume the phase accumulator already exists elsewhere which can be confusing.

I recently made a page on antialiasing which you could find useful as an introduction, some other people have found it very helpful, including c++ coders:

http://www.yofiel.com/software/cycling-74-patches/antialiased-oscillators

Generally when making oscillators at a low level, whether band limited or not, one starts with a ramp between 0 and 1 with an increment size of fc/sr, then applies functions to this, the 'phase accumulator,' to form different waveforms. if sr is not =samplerate it doesn't make any difference, it should still work the same way. There's a dozen different ways to make the phase accumulator without significant difference, and often when people show c++ code for band limited functions they assume the phase accumulator already exists elsewhere which can be confusing.  

http://www.yofiel.com/software/cycling-74-patches/antialiased-oscillators


I might possibly be wrong, but I think this is a slightly different case. I think I didn't explain as well as I could.

Phase isn't so a relevant a concept here as it is in eg a sine wave oscillator. In a sine wave the amplitude of the oscillator at a given moment is a function of phase. In the cases I'm looking at (henon map 

http://en.wikipedia.org/wiki/H%C3%A9non_map

 and other "iterative" functions) the calculation is stepwise and its amplitude at a given moment is a function of its previous amplitude value(s). eg I can calculate the value at the n+1th iteration on the basis of the value at the nth iteration, but I can't directly calculate at time x without knowing the previous iteration(s).

Values exist for integer values of n, but no value exists at a n value of eg 1.2 - i need to interpolate to get that.

So if I calculate my iterations at the sample rate (or at 

) this is fine and the values calculated line up with the sample rate. If I run my iteration calculation at other rates then the sample rate and the iteration rate don't coincide and I have to start thinking about interpolation.

Thanks Ernest.
I might possibly be wrong, but I think this is a slightly different case. I think I didn't explain as well as I could.
Phase isn't so a relevant a concept here as it is in eg a sine wave oscillator. In a sine wave the amplitude of the oscillator at a given moment is a function of phase. In the cases I'm looking at (henon map http://en.wikipedia.org/wiki/H%C3%A9non_map and other "iterative" functions) the calculation is stepwise and its amplitude at a given moment is a function of its previous amplitude value(s). eg I can calculate the value at the n+1th iteration on the basis of the value at the  nth iteration, but I can't directly calculate at time x without knowing the previous iteration(s). 

 Values exist for integer values of n, but no value exists at a n value of eg 1.2 - i need to interpolate to get that.
So if I calculate my iterations at the sample rate (or at [sample rate]/[integer]) this is fine and the values calculated line up with the sample rate. If I run my iteration calculation at other rates then the sample rate and the iteration rate don't coincide and I have to start thinking about interpolation.


And I couldn't speak for sure, but if you are generating a sine iteratively, and you want to create a single cycle sine in the way you describe, then the number of iterations in one wave cycle is just the other way up--sr/fc for the number of calculations in a wave instead of fc/sr for the phase increment -- whatever audio rate you are using.

In my example on the web page I provided, I do not upsample the band-limited output. I upsample the phase accumulator, and apply band limiting at the higher sample rate. there is some discussion of that in another thread with an illustration on how it would be done with objects rather than code in gen!, here:

https://cycling74.com/forums/upsample-to-reduce-aliasing-using-only-gen-not-poly-object/

But if you are doing it in max with uzi and saving it in a buffer, that may not help you.

And I couldn't speak for sure, but if you are generating a sine iteratively, and you want to create a single cycle sine in the way you describe, then the number of iterations in one wave cycle is just the other way up--sr/fc for the number of calculations in a wave instead of fc/sr for the phase increment -- whatever audio rate you are using. 

In my example on the web page I provided, I do not upsample the band-limited output. I upsample the phase accumulator, and apply band limiting at the higher sample rate.  there is some discussion of that in another thread with an illustration on how it would be done with objects rather than code in gen!, here:

But if you are doing it in max with uzi and saving it in a buffer, that may not  help you.


I'm doing this in C though, not inside max using Uzi. Typo on my first line- I wrote

’m trying to write some iterative oscillator externals 

I'm not trying to generate a sine wave -that was just a counterexample where I could calculate from a phase ramp as you sugest.

some iterative oscillator externals in C (simple things that almost certainly already exist like Henon Map, Gingerbreadman map etc,

Thanks Ernest,
I'm doing this in C though, not inside max using Uzi. Typo on my first line-  I wrote 

’m trying to write some iterative oscillator externals for C

I'm not trying to generate a sine wave -that was just a counterexample where I could calculate from a phase ramp as you sugest.
As per first post, I'm trying to write 

The the number of iterations for a single wave cycle, if you are doing it in a for loop or while loop, will be sr/fc, where sr is the audio rate to which you are upsampling in Hz, and fc is the signal frequency in Hz.

Thanks Ernest- but I think these examples (chaotic iterative functions) are slightly different from periodic waveforms in that they don't have a stable cycle length (at least not for all parameter values) - hence not being able to calculate from phase, and hence the challenges here being slightly different. Take a look at the wiki page I link to above.

If anyone has any experience of working with similar methods I'd appreciate their opinions on this.

Thanks Ernest-  but I think these examples (chaotic iterative functions) are slightly different from periodic waveforms in that they don't have a stable cycle length (at least not for all parameter values) - hence not being able to calculate from phase, and hence the challenges here being slightly different. Take a look at the wiki page I link to above.
http://en.wikipedia.org/wiki/H%C3%A9non_map

If anyone has any experience of working with similar methods I'd appreciate their opinions on this.


Well so far my experience with interpolation is, for oscillator waveforms that are not sine approximations, standard interpolation algorithms tend to provide no benefit at all in terms of audio quality. Others have found some benefit, but rarely enough to justify the extra processing.

This is why I built my own interpolators, but they are for a pulse and ramp, so they are straightforward really. If you can't use a phase accumulator in your algorithm which at least provides exact upsampling, the problem for more chaotic waveforms is that the resampling tends to introduce errors in the waveform which more than offset any antialiasing benefit. Most others Ive seen on this forum so far have not been able to find any upsampling method that has produced any reliable audio improvement, even in poly~, and some other people have said the same thing to me.

The general theory is though, which you probably already know, is that if your resampling is good, you can hope for an ideal a 6dB noise improvement for each 2x upsampling, and expect a 3dB noise improvement due to resampling errors. So if you are seeking, say, a 24dB improvement in noise, you are meant to upsample by 32x.

Most people find that prohibitive and, historically, that is why band limited things like bleeps and blots became so popular in the first place.

Well so far my experience with interpolation is, for oscillator waveforms that are not sine approximations, standard interpolation algorithms tend to provide no benefit at all in terms of audio quality. Others have found some benefit, but rarely enough to justify the extra processing. 

This is why I built my own interpolators, but they are for a pulse and ramp, so they are straightforward really. If you can't use a phase accumulator in your algorithm which at least provides exact upsampling, the problem for more chaotic waveforms is that the resampling tends to introduce errors in the waveform which more than offset any antialiasing benefit. Most others Ive seen on this forum so far have not been able to find any upsampling method that has produced any reliable audio improvement, even in poly~, and some other people have said the same thing to me. 

Most people find that prohibitive and, historically, that is why band limited things like bleeps and blots became so popular in the first place.


Well if I want to run these stepwise functions at variable iteration rate, in a host app that's running at a fixed sample rate (and that's what I want I do) then I have no choice but to approximate the values between the steps of these functions, since that's very often where the samples, at the host app's sample rate, are going to fall.

Seems to me, I can either do my interpolation against host sample rate, or I can interpolate at higher sample rate (to reduce interpolation error) then downsample

I guess the question is, given that I have decided to at least try out the latter (acknowledging that this is a learning exercise and I might be better not to bother), do people think my approach to doing this, as outlined in the first post, is reasonably sensible?

It is an interesting question though - there is no "correct" solution here - the functions are discontinuous, there just are no values between the steps that you could compare your solution against. Whatever you put there is a fiction. It's more or less purely a question of aesthetics. Which is partly why I want to try a few different approaches.

Seems to me, I can either do my interpolation against host sample rate, or I can interpolate at higher sample rate  (to reduce interpolation error) then downsample
I guess the question is, given that I have decided to at least try out the latter (acknowledging that this is a learning exercise and I might be better not to bother), do people think my approach to doing this, as outlined in the first post, is reasonably sensible?

It is an interesting question though - there is no "correct" solution here - the functions are discontinuous, there just are no values between the steps that you could compare your solution against. Whatever you put there is a fiction. It's more or less purely a question of aesthetics. Which is partly why I want to try a few different approaches.


All I could say to that is, as you know about zero stuffing, you know far more than most people here already, and I for one empathize with the problem. I tried Hamming, blackman, and triangle windows at various times, as well as gen~ spline method which is not really documented, and all of them work ok for sine and parabolic waves, but if its got steps or hyperbolic functions, all you can do is try various things and see which one products results you like best. My experience is that it becomes a qualitative evaluation rather than something for which the books can give you a better answer, and reading more on the subject may help you find something very slightly better, but with the knowledge you have already, you may be better off applying that effort elsewhere.

9edit: at least for oscillators. For a Butterworth filter, I did find upsampling made a real improvement, despite the raw waveform distortions, because it improves the self oscillation so much, which is by nature a sine wave and therefore at higher resonance values I think it really does make a worthwhile difference. But again this a qualitative evaluation, and others not interested in a filter's self oscillation may have different opinions.

This essentially is your clock. Every transition from high to low (assuming positive frequencies, you could just look at when x

If I can suggest, implementing this first in gen~ will make things much easier testing wise, and you can export the code back into C.

It also seems like any band-limiting that is done should take place outside of the function calculation if possible. As I understand it, band-limiting is really about reducing aliasing produced by large, rapid changes in amplitude/direction. This is something the PTR algorithm addresses; basically it ignores everything but the transition regions because the most noticeable aliasing occurs in the transition regions.

What little I've done with iterative oscillators (I made a signal rate implementation of the Latocarfian function), I find them most useful as a CV source rather than directly for audio. YMMV

Re: the phase accumulator
(To add to what Ernest said earlier)
This essentially is your clock.  Every transition from high to low (assuming positive frequencies, you could just look at when x

If I can suggest, implementing this first in gen~ will make things much easier testing wise, and you can export the code back into C.  

It also seems like any band-limiting that is done should take place outside of the function calculation if possible.  As I understand it, band-limiting is really about reducing aliasing produced by large, rapid changes in amplitude/direction.  This is something the PTR algorithm addresses; basically it ignores everything but the transition regions because the most noticeable aliasing occurs in the transition regions.  

What little I've done with iterative oscillators (I made a signal rate implementation of the Latocarfian function), I find them most useful as a CV source rather than directly for audio.  YMMV


Iterative Oscillators and Interpolation