Physical modelling project

trogluddite · 9 Jan 2013

Welcome to the forum, dentistguba,

A very intriguing introduction - there have been very few excursions into physical modelling here, but I remember my old Yamaha VL module very fondly. Even when not strictly "realistic" it has so much scope for being expressive. The demo's certainly sound good, can't wait to see what you come up with.

And some good news for you over at the FlowStone site... LINK

Cheers, Trog

engineer · 3 Apr 2014

anything new about this recently? I am following VA projects...

KG_is_back · 3 Apr 2014

engineer wrote: anything new about this recently? I am following VA projects...

You might also be interested in this http://www.dsprobotics.com/support/viewtopic.php?f=3&t=2364 It is a physical modeling program that can analyze recording of a plucked/hammered string and calculate parameters for a physical modeling synthesizer (a simple synthesizer example is included). The actual model is relatively simple and parameters can be easily ported, possibly even to HW synth

engineer · 11 Apr 2014

hm not bad. Will be my weekend task to inspect that 🙂

dentistguba · 1 May 2014

Hi again,

been a while since I posted but have still been beavering away on this stuff when i've found a moment haha.

I haven't put up a sound demo for a little while as I tend to get carried away trying to completely perfect the code before showing it, typical programmer vice.

I have a fairly recent drumhead demo here: https://soundcloud.com/dentistguba/deta ... e-drumhead.

as some newer stuff on my Youtube that i mentioned before.

I also have two much more recent models of a snare and hihat which i should be demoing soon and possibly putting up a demo vst export for people to play with.

The new snare and hihat are a bit more physical now as I set up a way to handle collisions so that losses don't have to be increased artificially to get closed hat or tight snare sounds. As in some of my previous demos the snare has each cable modeled like a karplus string.

One goal I have at the moment is to create a new delay which will allow more crazy modulation by adding a smart slew limiter: in a real string an instant doubling of tension would only double the speed of the wave meaning you should get two samples out of the delay whereas in a naive karplus you suddenly hop over half the samples. Once you get to half length from moving two samples at a time (in a circular buffer-one extra sample) the whole thing should settle in as the recirculated samples reach the output at that point. The other part of this is obviously a need to read out any samples the output jumps over and zero them to keep things lossless and realistic.

I already had a go at messing with weird delays and got an odd recirculating time stretch with bitcrushing when the input moved slow and zero padding when fast lol. I guess I'm now extending that to make it actually useful.

Another improvement seems to be force waveguides which I have a prototype of as you can feed in DC to allow 'pressed' hihat sounds for example.

KG_is_back · 4 May 2014

on the topic of the delay. one way to do it would be to re-stretch the delay buffer every time the delaytime changes. So for example when delay 200 is changed to 150 the buffer will be resampled to 75% length.

dentistguba · 4 May 2014

That was my first Idea of how it should work however it's obviously not an efficient method especially with SM/flowstone arrays so I decided not to go down that route. This new idea should basically be mostly equivalent to that except that you are resampling one sample at a time as needed at the output. The other issue with resampling the whole thing is lossy downsampling when the delay is shortened which would necessitate storing the original.

On an additional note I've realised that stretching should be slower than squashing as zero or below speed for the read head would mean the wave would periodically stop or go backwards which isn't really possible. A decrease in length of /2 is 2* the speed but an increase in length of *2 is 0.5* the speed. A decrease in length of /4 would actually be 3* the speed as it's the difference we are interested in, an increase of *4 is more obviously 0.25* the speed.

My first attempt at this came out a bit buggy, partly as it was calculating a speed each sample even if the delay time stopped being modulated which made the read head slow down almost infinitely when nearing its target. If the delay time is changed the read head needs to do a one shot calculation of it's new speed and adjust relative to that if still moving when the delay is changed again.

I guess I should also cut out some variables by jumping around a static wavetable before making the actual delay.

KG_is_back · 6 May 2014

I was thinking maybe storing the value and delay in parallel. Values will be written one after another along with their respective delay. Reading will be different however. the read index will each time increase by old delay (stored with the sample that is being read at the time)/new delay (the one currently on the input) . If delay is not changing the step will be 1. however when delay changes to half the increment will be 2 and samples will be read twice as fast until they reach point where they were written at the new delay time.

Here's code for noninterpolated version

streamin in; streamout out; streamin delay;

float c,k; float samples[200]; float delays[200]=1; float startD;

stage(0){ k=200-delay; startD=delay; }

samples[c]=in; delays[c]=delay/startD;

//reads value at k out=samples[k];

//change indexes for next sample c=c+1; c=c&(c<200);

k=k+delays[k]*startD/delay; k=k-200&(k>=200);