DSP Robotics Support

-

Wow what a weird sound!

I'd be interested to hear the same sort of thing with a completely dry sound, so no reverb etc. I suspect the reverb diffusion is obscuring what's going on to some extent.

Thanks for doing and sharing this; very interesting.

Cheers

Spogg

I'm shocked. You seem to really understand my thoughts, because indeed, a fixed number of nodes is all you need to predefine! Everything else, their position in time and amplitude is totally free and depends solely on the modulated values (length, angle) of the previous vector, the modulation of the current one, and the applied interpolation math.

Another assumption I would make is that the start and end of the resulting wave should be at zero otherwise you could get a sharp step as the wave looped. Correct? I can see the result clearly in my mind and it would be great to play around with such an oscillator.

Since this is off-topic for this thread why not start a new one?

Cheers

Spogg

eternith15 wrote:Also,tulamide, perhaps you can write out the algorithm you have in mind in more detail in english step by step, and we might all have a go at it.

Well, the algo already exists. But only for graphics. I created a spline class some time ago, you can download it here: http://flowstone.guru/downloads/ruby-fo ... escription Make sure to read the included manual, it describes some of the concept. Then have a look at the Ruby code. But I will talk about it here in more depth:

The spline class draws bezier curves. The splines are defined by nodes. Each node has two control points, one to control the incoming line and one to control the outgoing line. So far so known. But to actually draw the curves, a technique must be used. This is mine.
Initially you set a maximum number of possible segments per curve (the part between two nodes). Then, the algorithm checks the linear length between two nodes and the curvyness (guessed by the position of the control points, not actually calculated) and based on that decides for a number of segments. The curve between the two nodes is then divided into those segments, and each segment is drawn as a simple line. The segment points on the curve are calculated with cubic interpolation. Instead of polynomials it uses a simplified method, based on the fact that two nested linear interpolations correspond to a quadratic interpolation, and two nested quadratic interpolations correspond to a cubic interpolation.

If we think in terms of an oscillator, the segments are nothing else than ramps, were time equals the x-ordinate and amplitude the y-ordinate. So, all there is to get it going would be to calculate cubic interpolation points and then ramp between those points. And all the segments are controlled by just two nodes. This offers a wide range of applications. For example, a table of just 3 (actually 4, but the last one is the first of the next cycle) predefined nodes can describe a sine wave, another set of 3 nodes describes, say, a saw. You'd now just use simple linear interpolation to move the positions of the nodes from the sine wave representation to the saw representation, et voila, morphing. Or you move the center nodes of a square; boom, pwm. Etc. Etc.

All it needs is efficient assembler code...

Yes, weird sound but very interesting. I have two brief comments

1. The sources sound "phasey". Might be due to the compression, don't know. But if you are concerned about phase interpolation, you should get that sorted out first.

2. The morphed results sound somewhat chopped, presumably as a result of STFFT blocks not blending seamlessly. Have you used any overlap/add at all and if so at which hop/block size ratio?

Thanks for sharing, and keep it going! Amazing how you pulled this off in no time!

Hi eternith15,

As everyone has sad really wierd, but very cool. A really good job so far. Keep up the great work!
Can not wait to see the finished product and more stuff from you in the future.

Take care, BobF.....