On Sunday, 29 November 2015 at 09:12:18 UTC, Any wrote:
> 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...
>
> Jitter is any deviation in, or displacement of, the signal pulses in a high-frequency digital signal. The deviation can be in terms of amplitude, phase timing or the width of the signal pulse.
>
> The units of jitter measurement are picoseconds peak-to-peak (ps p-p), rms, and percent of the unit interval (UI).
>
> See google.

We're talking about whether a plugin / audio code / runtime environment can deliver audio to a soundcard in a reliable manner so that you don't get audio drop outs. We're not talking about the jitter of a digital clock source that's used to control the actual sampling stream. It's similar but at the level of the audio buffer timeslice, not the unit delta of the sample stream. The jitter of an audio clock source is for electronic engineers not audio plugin developers.

In general terms of delivering audio to a soundcard jitter would be the variation in the time take to deliver each buffers worth of audio data to the soundcard. If the sound card has 5ms latency, then you need to make sure your audio processing never takes more than that.

The point is that it is better to have an algorithm that always takes 3ms, than one that usually takes 2ms but occasionally takes 6ms. Because those times when it takes 6ms it cant feed the soundcard in time for the next audio buffer to be delivered.

In more precise terms jitter is the variation in the time a given algorithm takes to process. I mean if the code is identical and doesn't change from one buffer to the next, the variation in time take to produce a each buffers worth of data.

It's important to remember that a typical DAW user may have 10, 20, or 100+ plugins loaded, and it may be hitting 80 or 90 percent CPU usage in places. With constantly changing loads on the plugins.

IE. If you are at 90% cpu usage with 5ms timeslice you can only tollerate 0.5ms jitter before the shit hits the fan. So the important question is not "does it work", it's "does it work under heavy load".

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?

On Sunday, 29 November 2015 at 10:14:40 UTC, Warwick wrote:
> We're talking about whether a plugin / audio code / runtime environment can deliver audio to a soundcard in a reliable manner so that you don't get audio drop outs. We're not talking about the jitter of a digital clock source that's used to control the actual sampling stream. It's similar but at the level of the audio buffer timeslice, not the unit delta of the sample stream. The jitter of an audio clock source is for electronic engineers not audio plugin developers.

Thanks for saying this.
Said it better than anyone.


> IE. If you are at 90% cpu usage with 5ms timeslice you can only tollerate 0.5ms jitter before the shit hits the fan. So the important question is not "does it work", it's "does it work under heavy load".

A common counter-point to stay clear of glitches is stay way below 90% CPU usage, have larger buffers or a beefier CPU. If you are maxing out the CPU you are asking for problems, it's not just the plugins being unpredictable. After all our OS aren't RTOS.

On Sunday, 29 November 2015 at 09:55:43 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote:
>> I see that if that RT music thing doesn't pan out for you, you can always become a psychiatrist. You are a man a many talents, congrats.
>
> Maybe you and Guillaume Piolat should try to tone down your french rhetorics? I don't think Ponce's product benefits from this (or from announcing that he is using a GC.).

I must admit the inflammatory tone got me. Sorry to everyone reading this thread.

On Sunday, 29 November 2015 at 08:12:17 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote:
>> While, this doesn't prove you don't have a clue about jitter, my guess is, you don't.
>
> Yes, jitter is bad and worse than latency, but OS-X AudioUnits run at a high priority thread where you cannot do system calls, malloc or run a GC. So the GC statements are misleading.

Wait.
What GC statements are _misleading_?

I've never said the GC is compatible with real-time, it isn't. I said, we can avoid it in a small part of an application and be real-time. So D can do real-time (audio).

On Sunday, 29 November 2015 at 11:15:41 UTC, Guillaume Piolat wrote:
> On Sunday, 29 November 2015 at 09:55:43 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote:
>>> I see that if that RT music thing doesn't pan out for you, you can always become a psychiatrist. You are a man a many talents, congrats.
>>
>> Maybe you and Guillaume Piolat should try to tone down your french rhetorics? I don't think Ponce's product benefits from this (or from announcing that he is using a GC.).
>
> I must admit the inflammatory tone got me. Sorry to everyone reading this thread.

:) What about writing a blog about the sonic qualities and measurable qualities of your plugin? I sure would want to read that.

And I think that is more interesting to musicians than what language you use (which can easily be misinterpreted if you say you are not using C/C++ ;)

The sound samples sound quite a bit like the classic vocal sound of Infected Mushroom to my ears, which is cool. I assume you are using a peak detector to get the consonants through and granular synthesis to do the frequency shifting in the time domain?

Maybe something like this for transients, or perhaps something less involved?

http://recherche.ircam.fr/anasyn/roebel/paper/icmc2003.pdf

On Sunday, 29 November 2015 at 12:28:49 UTC, Ola Fosheim Grøstad wrote:
> The sound samples sound quite a bit like the classic vocal sound of Infected Mushroom to my ears, which is cool.

Infected Mushroom released another plugin recently: http://www.musicradar.com/news/tech/infected-mushroom-present-the-i-wish-granular-note-freezing-plugin-631043

> I assume you are using a peak detector to get the consonants through and granular synthesis to do the frequency shifting in the time domain?

It's a pitch-tracking poly-Bode-shifter. The pitch tracking part is secret(tm).
The frequency shifting is regular, doesn't need Overlap Add like pitch-shifting.


> Maybe something like this for transients, or perhaps something less involved?
>
> http://recherche.ircam.fr/anasyn/roebel/paper/icmc2003.pdf

The phase vocoders of IRCAM are very impressive at work, they have. I remember a demo where they changed male to female with algorithms tuned for a voice.
But it has different latency characteristics, overlapped FFT easily goes into the 20/30 ms.

On Sunday, 29 November 2015 at 11:58:20 UTC, Guillaume Piolat wrote:
> I've never said the GC is compatible with real-time, it isn't. I said, we can avoid it in a small part of an application and be real-time. So D can do real-time (audio).

Yes, but why say it if you don't use it after init?

It's not new that D, like C++, can work like a more powerful version of C. Although I had to create a lot of fuzz to even get to this point where we now have at least the @nogc tag. A couple of years ago neither Walter or Andrei showed any sign of understanding that being GC reliant was an issue for a system level programming language. That attitude is pretty common for languages that ship with a GC, and is the reason for why people don't want audio software using it (or is boasting it).

On Sunday, 29 November 2015 at 12:40:43 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 November 2015 at 11:58:20 UTC, Guillaume Piolat wrote:
>> I've never said the GC is compatible with real-time, it isn't. I said, we can avoid it in a small part of an application and be real-time. So D can do real-time (audio).
>
> Yes, but why say it if you don't use it after init?

Well, this fit some style of applications like video encoders too.
With games I did have more problems with GC, unless pooling.
Problems that C++ wouldn't have with malloc.

> It's not new that D, like C++, can work like a more powerful version of C. Although I had to create a lot of fuzz to even get to this point where we now have at least the @nogc tag. A couple of years ago neither Walter or Andrei showed any sign of understanding that being GC reliant was an issue for a system level programming language. That attitude is pretty common for languages that ship with a GC, and is the reason for why people don't want audio software using it (or is boasting it).

There is a perception problem, and it's reason enough not to talk about this GC thing anymore. Because tt hasn't been a problem, was easily avoided, and now is just negative PR for nothing.

On Sunday, 29 November 2015 at 12:40:30 UTC, Guillaume Piolat wrote:
> On Sunday, 29 November 2015 at 12:28:49 UTC, Ola Fosheim Grøstad wrote:
>> The sound samples sound quite a bit like the classic vocal sound of Infected Mushroom to my ears, which is cool.
>
> Infected Mushroom released another plugin recently: http://www.musicradar.com/news/tech/infected-mushroom-present-the-i-wish-granular-note-freezing-plugin-631043

Hmm, yes, that looks like a simple loop algorithm. One can do interesting things with simple effects, like zero-crossing slicing. Btw, I recently found out that an ex-colleague of me has created a song with them called "Nerds on Mushrooms", IIRC he is quite fond of the vintage game music soundscape.

>> I assume you are using a peak detector to get the consonants through and granular synthesis to do the frequency shifting in the time domain?
>
> It's a pitch-tracking poly-Bode-shifter. The pitch tracking part is secret(tm).

I remember the electro acoustic people here in Oslo (NoTAM) doing live pitchtracking 20 years ago, I believe they used an envelope follower of some sort. Just measuring the distance between the tops? That was to have the "electronic accompaniment" follow the lead of the vocalist I believe.

>> Maybe something like this for transients, or perhaps something less involved?
>>
>> http://recherche.ircam.fr/anasyn/roebel/paper/icmc2003.pdf
>
> The phase vocoders of IRCAM are very impressive at work, they have.

IRCAM has done a lot of interesting things. In the 90s they had the IRCAM workstation which was a NeXT cube with lots of DSP card so that you could run Max real time.

> But it has different latency characteristics, overlapped FFT easily goes into the 20/30 ms.

It depends on how low down in frequency you need to go, a female voice is at 160 hz and up, and a child is at 250hz and up. In that frequency range one could do better. And at the cost of complexity you could use two FFTs, one for the lower range and another for the higher range.

Or maybe one can use wavelets, but I don't know much about wavelet transforms (they don't map to cosine, so imagine it will be much harder to do well).