Sonifying math functions

Jumps and wrapping are the interesting things in sound; f.i. synchronising is a simple method to get an interesting sound which can be shaped by filters and is simple to realise.
When you want to have a smooth waves from start to end of phase it will be boring by my experiences.

There is another important aspect when creating a wave with a formula: how do you want to get the wave; calculating every sample tick from a saw oscillator or calculating offline and storing into an audio table?

 

After looking more closely at the graph, and the interesting relation of the 'phasing' of the zero-crossings, I wondered if there would be any way of predicting what the harmonic content of such equations would be???

Thanks for the helpful reply!
I'm pleased to say that it's more or less what I had 'intuited.'
(And I think I've seen lots of wavetable oscillators use more severe slope changes than in rachMiel's equation as originally graphed.)

So is it 'cheating' to use interpolation to smooth out the slope changes? I.e. would it likely remove some of the equation's 'identity' in sonified form, or would it simply diminish unwanted aliasing? I guess this too would be in the ear of the beholder.

 

I surmise that calculating every sample tick would be more CPU-expensive.
In your experience is there an audible reason to choose one over the other? (I always come back to 'sounds good'.)
Is using a wavetable likely to be a little more 'boring' because of the repetitions in the samplings? Would it take especially sharp ears to hear a difference? Would we see the difference easily on a scope?
All of these questions make me think it continues to be an interesting topic for experimentation...

 

yes - the „problem” is to find a start for systematic experiments. Therefore i like the basic waves and only few modulations.
but there are other interesting things: i am experimenting with my zero-phase-oscillator in EMSCHER and it is very interesting because you don't need a filter or sharp waves to get different sounds - and modulations is very simple, which is important (for me).

 

Colin is your dc-offset killing the aliasing also?

 

Yes that's true of course.

The issue is that generating waveforms with discontinuities that don't alias is difficult enough when they are simple pre-determined shapes like pulse, saw etc. The idea of an instrument that can 'sonify' math functions would need that to be done automatically for arbitrary waveforms, or use a lot of oversampling or just accept aliasing. That's my point. I'm not saying they should be removed, I'm pointing out the problems they cause.

 

no

 

Why do you surmise that? It would depend on the complexity of the math function being sonified... and also a bunch of other stuff we can't know without profiling different methods in real world contexts. Memory access can be slow compared with simple math and logic operations.

 

Habit I guess: back in the bad old days, math operations were much more costly than reading a wavetable. And I figured a wavetable getting hit regularly would be cached and access would be pretty fast.

 

> After looking more closely at the graph, and the interesting relation of the 'phasing' of the zero-crossings, I wondered if there would be any way of predicting what the harmonic content of such equations would be???

Fourier analysis should do that, right?

Btw Fourier series also balk at discontinuities: square wave jumps from -1 to +1, for example.

 

Sounds cool Herwig! I'll download and experiment with it later today.

 

I think the potential for a wavetable to 'sound good,' CPU cycle for CPU cycle, is actually much higher than that of a polynomial being read out by a ramp. The reason I say this is that running a phase accumulator through a polynomial (or, more generally, any composition of univariate elementary functions) essentially corresponds to the already well-characterized domain of waveshaping. The values in a wavetable, however, could be generated in advance (when the phase wraps, when the Ensemble loads, whenever) with any number of recursive relations, which to me promise interesting harmonic structures due to the potential for self-similarity, chaos, and other aesthetically pleasing phenomena. The initial values of such a relation would exert considerable power over the resulting timbre.

 

One possible issue with this is memory usage. Reaktor (and particularly core) is very memory inefficient due to the lack of code reuse mechanisms, and the result is that when users start adding more blocks to a patch (particularly duplicates), the cpu usage can start to go up exponentially, AFAIK this is a result of cache thrashing. In this scenario it's possible that a real-time calculation could be might lighter on resources than a table based approach even if a comparison shows otherwise in a simpler 1 vs 1 context. As usual, the only way to know for sure is profiling in a 'realistic' situation.
Remember that due to that inability to reuse code, if you create an oscillator that uses a large look up table, and then have multiple instances of that oscillator in your module, then make a patch with multiple instances of the module, Reaktor wont reuse the table, it will keep loading in a separate copy of the table for each individual oscillator instance... not nearly the same as in c++, java etc. so the same rules of thumb do not apply.

 

If I understand, you're saying that it's easier CPU- and programming-wise to grab a sequence of values from a wavetable and manipulate it (recursion, self-similarity, etc.) than it is to grab the same sequence from a real-time ramp/function setup?

Can you give some examples of what you might grab from a wavetable (whole wave cycle, partial, multiple?) and how you might manipulate it?

 

If i would use audio wave tables, i would try to use two different waves and morph from one to another sample by sample so that after some times one changes to the other.
But you could morph from one to another quickly perhaps by an envelope? There are many ideas of manipulations i think - but only non realised ideas.

 

I like the idea of grabbing a sequence of samples and looping it and/or mirroring it and/or joining it to other sequences and/or leaving samples out and/or adding samples in and or feeding it back to itself, etc. These might be easier to do with an audio table than real-time function solving.

 

Ah, good point. I wasn't even thinking about a Blocks application.

Imagine you have a waveform stored in a table 2048 samples long. Take this waveform, shift and scale it horizontally and vertically, and add it back on top of the original table. Then repeat the process, starting with this updated wavetable. You can use the nested loops in the Partials Framework to repeat this as many times as is necessary or practical, and you can use the index of the outer loop to select a different transformation to apply at each level. You can also store each iteration in sequence within a larger table, so that the wavetable position functions as a sort of complexity control.

 

yes - all these are interesting aspects. I think it is necessary to have a framework (tables framework ? ) for writing and reading etc. and basic algorithms.
@ NI : please expand tables framework for core (writing)!

 

Got a chance to hack this together today. Play a low note and sweep the Depth knob... wub wub wub. The other knobs generate the wavetable, which is updated at the start of each note.

 

Oh yes, that is wonderful! I love the way the sound 'comes apart' and comes back together during the sweep of Depth.
Looking forward to digging into the structure for this. 2 thumbs way up!
Edit: Plus, this is a great demonstration of what you 'advertised': the nested looping from the Partials Framework, at a nice cool CPU level (insofar as I'm competent to gauge such things).
Many thanks, for the concept, its very nice-sounding execution, and great pedagogical value in such a jewel-like package!
Attached is an interesting looking result...