Graillon 1.0, VST effect fully made with D

[Guillaume Piolat via Digitalmars-d-announce]

On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote:
>
> um, come on, you sit here and preach that I don't know what I'm 
> talking about yet you can't even be right on the first sentence?
>
> jitter is the standard deviation of the timings. Do you know 
> what standard deviation is? It is the square root of the sum of 
> the squares...

There is different "jitters":
https://en.wikipedia.org/wiki/Jitter see at Sampling Jitter

Audio plugins create latency if they are slow but not sampling 
jitter, which is a property of the sound card.

What you mean is that when a plugin is slow it create a jitter 
sound when the get back?


> Also, if you simply removed the GC from D so it doesn't get 
> called, then whats the point? Anyone can do that(more or less). 
> If you used manual memory management, then whats the point? C++ 
> already does that and does RT audio already. We know D can be 
> made to do this already.

No, I've seen people claim exactly the reverse, that D can't do 
RT audio. You even do so below.


> If you pause the GC so it doesn't get called a lot, then whats 
> the point? If you run your software for 3 hours, if it going to 
> survive or glitch?

GC isn't paused, it doesn't trigger because there is no periodic 
allocations.


> Do you know what "design for the worse case scenario" means? 
> While RT audio isn't life and death, it's treated that why by 
> the professional community.

It's important to me, else I wouldn't have ensure the GC never 
collects.

Please stop the appeals to authority already. Unless you state 
who you are perhaps? Jonny the drummer.


> Just because it's acceptable to you to define RT audio in some 
> way that justifies it for you does not mean it's RT audio. I'm 
> not saying your software isn't RT, but if you use the GC in any 
> way what so ever, you don't have RT audio...

This doesn't make sense. If it doesn't glitch, doesn't introduce 
latency or jitter, then it's RT audio. You can try the plugin at 
home to verify that.

> regardless if it behaves like RT 99.99% percent. (there is 
> something about guaranteed *maximum* latency that you have to 
> deal with)

Familiar with the IPlug framework? It takes locks in the audio 
callback.
A lock isn't guaranteed to have a maximum latency, but it's very 
fast. That doesn't prevent successful software like KlangHelm's 
MJUC to work.
https://github.com/olilarkin/wdl-ol/blob/cb51edc105c6cc927530a6ac0459dcee0097a23c/WDL/IPlug/IPlugVST3.cpp#L341

But wait!
JUCE is also doing that.
https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp#L582

It turns out the two most used audio plugins frameworks out there 
do things that don't have maximum latency predictibility. Have 
you gone bugger them?