Repro-1 (out now)

[beely]

There's nothing like geeking out on math first thing in the morning.

Ugh!

[deltaMACHINE]

Its time Urs ,

please let us know what happens

[Urs]

working on it

[deltaMACHINE]

Urs do you remember 3 years ago i ask you for a pro one clone
and you told me your pro one is broken,
now i thank you for your passions and thanks for the Dark Zebra that comes out of my mind .
Please let the spirit go on.

[Urs]

Urs do you remember 3 years ago i ask you for a pro one clone
and you told me your pro one is broken,
now i thank you for your passions and thanks for the Dark Zebra that comes out of my mind .

My Pro-One was broken, indeed... it's been serviced since and I've accumulated quite a number of CEM chips

My interest in doing a Pro-One started peaking when I also got a Synthex and when everything was about the Laserharp sound. The Pro-One was the only non-modular synth in my arsenal that also does a decent Laserharp. So it dawned on me that the Pro-One might be a good choice to start getting into monosynth stuff (which I had contemplated for a while, since I needed test beds for analogue filter emulations).

[deltaMACHINE]

ok what ever but you know the quality it is your duty and over what to do with it,
because you're just the best

[Funkybot's Evil Twin]

I'll start writing my conclusion today and I hope to publish it next week

I think it's clear from this test that there's definitely a difference in how the filters are calculated, so you've definitely shown that brute force oversampling alone isn't enough. For what it's worth, I think it breaks down where 1 is probably the cheapest way to solve the equation ("cheap" in terms of CPU), 2 and 5 are probably the next most similar, and 3 and 4 are probably the most expensive with 3 being the absolute most costly.

[urosh]

In arguments about DSP, people often argue that if one oversampled enough, the differences between the methods would disappear, and usually 8x is enough. But clearly, the differences do not disappear - which I think we're proving here, and which this is really about.

Well, those arguments are unsubstantiated. It's trivial to show that filters behave differently, here are plots of output of two (swept, with square wave input) otherwise identical filters, with red one having 2.84uS delay in feedback (which corresponds to 8x oversampling at 44K). Question are, do users hear differences and do they care for differences if they hear them? I guess that this RePro experiment has shown that answers are yes and yes.

[HunterKiller]

... This is called a unit delay and it is the opposite of what's called zero delay feedback...

And everyone was just getting started by jumping on the zdf bandwagon.

[realmarco]

i made 38 presets for Repro. where do i send them U-HE ?

[louderr]

@realmarco: I'll take em if nobody else wants em

[Vesius]

Lastly, one algorithm computes the actual equations of the form y = tanh( y ) as they are, but it involves computing the whole filter not once or twice, it involves computing it several times, usually between 2x and 6x until the correct solution is found. This algorithm provides for a mathematically accurate method without any form of unit delay.

Witchcraft confirmed. Repeat; confirmed witchcraft.

Smells like Newton-Raphson but I don't understand where the delay went, as my current understanding was that there had to be one *somewhere*, even, in a very real sense, with ZDF filters.

Unless, the previous state of the system is modelled as part of modelling the current state all within one sample ... but that previous state would require the previous previous state and so on ... urgh.

Anyhow, your secrets are your secrets obviously , I just like getting my brain spinning

[hakey]

Unless, the previous state of the system is modelled as part of modelling the current state all within one sample ... but that previous state would require the previous previous state and so on ... urgh.

That's how it's done (I think).

Several iterations of calculation are performed within one sample cycle, starting with a best guess as to what the output will be and using that as in input. Somehow, with each iteration the guesses get more accurate and eventually settle on the solution. And it's all done within one sample.

[Vesius]

From everything I've read on the thread and observed with the plug in, essentially, I suspect that the synth engine, or parts of it are abstracted away from the host plugin's main loop (which will be running at the host sample rate, effectively (it isn't quite that simple, but more or less)), this would allow the synth engine to run at arbitrary sampling rates, or more easily allow multiple samples to be calculated at once. This effectively would knock oversampling in the traditional sense (upsampling, multiple parallel processes, throw away aliases, downsample) on the head, as all one would need to do is downsample to the host sampling rate. Alternatively, you could also calculate several samples at once, a lot like convolution, and generate the required 'previous' inputs for the filter from the last calculated window.

Pure speculation mind. I can see it might be possible with what I know of the VSTSDK and DSP. I wouldn't like to try and implement it, or even state with certainty that it can be done.

Something 'strange' is going on with the plugin though, regardless. When I change sampling rate in my sequencer, the nyquist of the plugin remains static, so on some level at least, it is definitely running it's own sampling rate.

[FLWrd]

as my current understanding was that there had to be one *somewhere*, even, in a very real sense, with ZDF filters.

I don't think they are needed. Would you need a unit delay to model a network consisting of two resistors?