www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Graillon 1.0, VST effect fully made with D

reply Guillaume Piolat <first.last gmail.com> writes:
OT: Readers of this NG probably know me under the name "ponce", 
however over the year I was made aware that it's an english swear 
word so I'll post under my IRL name from now on.

I'm happy to release my first commercial software, it's a voice 
effect designed for singers, follows the VST 2.x format, and is 
made entirely with D (LDC 0.16.0 for OSX 64-bit, DMD 2.069.0 for 
the rest).

http://www.auburnsounds.com/products/Graillon.html

Using D has been an interesting ride, even for a long-time user, 
but it went better than expected.

I don't really have a point to prove, but I'm really tired with 
people arguing that a language with GC can't possibly do 
real-time. It's not like you are unallowed to optimize.

I've only ever worked in real-time systems. All of those, except 
for one with 32kB of RAM, could have afforded a GC.
Actually very, very few development time was allocated to deal 
with the GC, if any.

If you want to make audio effects with D too, this one uses 
"dplug" which was announced already: 
https://github.com/p0nce/dplug

Thanks for reading.
Nov 26 2015
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
wrote:

 OT: Readers of this NG probably know me under the name "ponce", 
 however over the year I was made aware that it's an english 
 swear word so I'll post under my IRL name from now on.

 [...]


Awesome!

Congrats.

      Bit
Nov 26 2015
parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 26 November 2015 at 16:33:46 UTC, bitwise wrote:

 Awesome!

 Congrats.

      Bit


Thanks. You are in the manual BTW, without you and Martin Nowak 
and Jacob Carlborg, there would be no Mac version.
Nov 26 2015
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
wrote:

 I'm happy to release my first commercial software, it's a voice 
 effect designed for singers, follows the VST 2.x format, and is 
 made entirely with D (LDC 0.16.0 for OSX 64-bit, DMD 2.069.0 
 for the rest).


Awesome. Please write a blog post detailing your experiences with 
D while writing this software and share on reddit. It would be 
good PR especially the comments about the GC.
Nov 26 2015
next sibling parent Andre Polykanine via Digitalmars-d-announce writes:
GWvDda> Awesome. Please write a blog post detailing your experiences with
GWvDda> D while writing this software and share on reddit. It would be 
GWvDda> good PR especially the comments about the GC.

+1. And I would translate your article into Russian :)

Andre.
Nov 26 2015
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 26 November 2015 at 17:14:34 UTC, Gary Willoughby 
wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
 wrote:

 I'm happy to release my first commercial software, it's a 
 voice effect designed for singers, follows the VST 2.x format, 
 and is made entirely with D (LDC 0.16.0 for OSX 64-bit, DMD 
 2.069.0 for the rest).


 Awesome. Please write a blog post detailing your experiences 
 with D while writing this software and share on reddit. It 
 would be good PR especially the comments about the GC.


Everybody like to think what they do is so real time sensitive 
they can't possibly afford a GC. Really, that is just self 
importance getting into the way of good judgement.

Yet, some can't afford a GC. But the set of people that can't 
afford a GC is significantly smaller than the set of people that 
think/say they can't afford a GC.
Nov 26 2015
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 27 November 2015 at 04:45:18 UTC, deadalnix wrote:

 Everybody like to think what they do is so real time sensitive 
 they can't possibly afford a GC. Really, that is just self 
 importance getting into the way of good judgement.

 Yet, some can't afford a GC. But the set of people that can't 
 afford a GC is significantly smaller than the set of people 
 that think/say they can't afford a GC.


Exactly, that's like all the talk about "scaling" or "big data" 
on the Internet. Problems we wish we had.
Nov 27 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 16:54:11 UTC, Guillaume Piolat 
wrote:

 Exactly, that's like all the talk about "scaling" or "big data" 
 on the Internet. Problems we wish we had.


All commercial websites can benefit from automatic scaling, load 
balancing and fully managed systems:

1. You get rid of the maintenance cost.

2. You can survive a DoS attack, or diminish impact of it.

3. You don't have to redesign the entire infrastructure as an 
emergency operation when you cross what you can run on a single 
server/database.

4. Solutions for scaling usually also includes reliability and 
data replication.

"big data" is often about being able to do things you could not 
do before.  Like log analysis. Which is relevant in some trivial 
domains, like multi-user games, where a single participant can 
generate a lot of data... I.e. try to figure out what game 
mechanics/levels works/don't work quantitatively. But yes, "big 
data" is probably overrated, although it can allow new ways of 
figuring out how to improve a system.

Your application looks cool, but I don't quite understand what 
kind of dynamic allocations you need after init?

Seems like you can afford to run all the audio on a OS-level real 
time thread. That is way different than a very computationally 
expensive application where you stream from a regular thread to a 
hard real time thread.
Nov 27 2015
prev sibling next sibling parent reply tired_eyes <pastuhov85 gmail.com> writes:
On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
wrote:


I've just checked demo songs and want to say that the sound is 
amazing! This is an excellent debunking of "GC is slow" myth. And 
it definitely worth a blog post, as mentioned above.



 Nov 26 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Thursday, 26 November 2015 at 18:47:29 UTC, tired_eyes wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
 wrote:


 I've just checked demo songs and want to say that the sound is 
 amazing! This is an excellent debunking of "GC is slow" myth. 
 And it definitely worth a blog post, as mentioned above.


Ahem. No time to do this properly.

Here the content of that blog post:

"I just used  nogc, unregistered threads, also ensured no 
allocation in UI hot loops.  nogc has become a worthy attribute 
in my views, I used to believe it was not necessary but it is. 
Also a bit of -profile=gc"

If blog post there must be, they should probably be targeted at 
musicians.



 Nov 26 2015



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Thursday, 26 November 2015 at 22:04:18 UTC, Guillaume Piolat 
wrote:

 On Thursday, 26 November 2015 at 18:47:29 UTC, tired_eyes wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume 
 Piolat wrote:


 I've just checked demo songs and want to say that the sound is 
 amazing! This is an excellent debunking of "GC is slow" myth. 
 And it definitely worth a blog post, as mentioned above.


 Ahem. No time to do this properly.

 Here the content of that blog post:

 "I just used  nogc, unregistered threads, also ensured no 
 allocation in UI hot loops.  nogc has become a worthy attribute 
 in my views, I used to believe it was not necessary but it is. 
 Also a bit of -profile=gc"


I think that would be great. Just expand on what these features 
do and how they helped you, as if the reader is not familiar with 
D. I think such a blog post would be great for people who are 
skeptical about D because of the GC.

I took this approach with my image processing blog post and it 
got quite popular.



 Nov 27 2015



 next sibling parent reply Andre Polykanine via Digitalmars-d-announce  writes:


VPvDda> I took this approach with my image processing blog post and it
VPvDda> got quite popular.

Could you post a link to it, please?


Andre.



 Nov 27 2015



  parent  Nemanja Boric <4burgos gmail.com>  writes:


On Friday, 27 November 2015 at 14:25:42 UTC, Andre Polykanine 
wrote:

 VPvDda> I took this approach with my image processing blog post 
 and it VPvDda> got quite popular.

 Could you post a link to it, please?


 Andre.


http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/



 Nov 27 2015



prev sibling  parent  Guillaume Piolat <first.last gmail.com>  writes:


On Friday, 27 November 2015 at 12:12:42 UTC, Vladimir Panteleev 
wrote:

 I took this approach with my image processing blog post and it 
 got quite popular.


It's one of my favourite blog post because it works as a 
introduction to ae.utils.graphics, covers interesting material, 
and tells why the building blocks are like they are. it's also 
sort-of DbI.
Much like Andrei's "std::allocator is to allocation", fascinating 
stuff.



 Nov 27 2015



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-11-26 16:48, Guillaume Piolat wrote:


 If you want to make audio effects with D too, this one uses "dplug"
 which was announced already: https://github.com/p0nce/dplug


I see that you mention Mac OS X 10.6 as the supported version. LDC only 
supports 10.7 and later. The reason is that's the first version that has 
native TLS in OS X. For DMD I wouldn't go below 10.6. I don't think 
there's an official lowest version that is supported but I know that 
there has been some bugs reported specifically for 10.5. 10.4 was never 
properly supported, If I recall correctly.

-- 
/Jacob Carlborg



 Nov 26 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Thursday, 26 November 2015 at 19:48:15 UTC, Jacob Carlborg 
wrote:

 On 2015-11-26 16:48, Guillaume Piolat wrote:


 If you want to make audio effects with D too, this one uses 
 "dplug"
 which was announced already: https://github.com/p0nce/dplug


 I see that you mention Mac OS X 10.6 as the supported version. 
 LDC only supports 10.7 and later. The reason is that's the 
 first version that has native TLS in OS X. For DMD I wouldn't 
 go below 10.6. I don't think there's an official lowest version 
 that is supported but I know that there has been some bugs 
 reported specifically for 10.5. 10.4 was never properly 
 supported, If I recall correctly.


People on OS X 10.6 don't use 64-bit audio plugins, so this 
combination is indeed missing but shouldn't be a problem. The 
transition to 64-bit occured starting with 10.7 if I understand 
correctly.

With the 64-bit binary I only support 10.7+ through LDC.

The big surprise was that DMD can produce OSX shared libraries at 
all. For good measure I've removed TLS usage I know in the 32-bit 
binaries. I haven't seem a change in behaviour.

LDC makes approximatively 2x faster code on vanilla D.
DMD forced me to write some assembly, that made the LDC binary 
slower.



 Nov 26 2015



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-11-26 23:09, Guillaume Piolat wrote:


 People on OS X 10.6 don't use 64-bit audio plugins, so this combination
 is indeed missing but shouldn't be a problem. The transition to 64-bit
 occured starting with 10.7 if I understand correctly.


I don't know what the audio industry is using but the 10.4 was the first 
version to get limited support for 64bit. I would say that 10.6 is a 
fully 64bit compatible OS [1]. Even if the kernel is running in 32bit 
mode you can run applications in 64bit, if the CPU supports that.


 With the 64-bit binary I only support 10.7+ through LDC.


Ah, ok, I see.


 The big surprise was that DMD can produce OSX shared libraries at all.
 For good measure I've removed TLS usage I know in the 32-bit binaries. I
 haven't seem a change in behaviour.


Is anyone still using 32bit on OS X?

[1] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard#64-bit_architecture

-- 
/Jacob Carlborg



 Nov 26 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Friday, 27 November 2015 at 07:47:08 UTC, Jacob Carlborg wrote:

 I don't know what the audio industry is using but the 10.4 was 
 the first version to get limited support for 64bit. I would say 
 that 10.6 is a fully 64bit compatible OS [1]. Even if the 
 kernel is running in 32bit mode you can run applications in 
 64bit, if the CPU supports that.


Interesting thanks. That means I should either be using DMD for 
everything, or not support OS X 10.6.



 Nov 27 2015



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-11-27 10:53, Guillaume Piolat wrote:


 Interesting thanks. That means I should either be using DMD for
 everything, or not support OS X 10.6.


I would go with not supporting 10.6. It's a really old version now. BTW, 
would there be a problem of using both DMD and LDC?

-- 
/Jacob Carlborg



 Nov 27 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Friday, 27 November 2015 at 16:29:54 UTC, Jacob Carlborg wrote:

 On 2015-11-27 10:53, Guillaume Piolat wrote:


 Interesting thanks. That means I should either be using DMD for
 everything, or not support OS X 10.6.


 I would go with not supporting 10.6. It's a really old version 
 now. BTW, would there be a problem of using both DMD and LDC?


Not sure what do you mean.
Past 10.7, you can use any (provided you avoid TLS).
Currently I use LDC for 64-bit, DMD for 32-bit, also because LDC 
used to have a bug in 32-bit codegen (fixed since then).



 Nov 27 2015



  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-11-27 17:52, Guillaume Piolat wrote:


 Not sure what do you mean.


Personally I would only support 10.7+.


 Past 10.7, you can use any (provided you avoid TLS).
 Currently I use LDC for 64-bit, DMD for 32-bit, also because LDC used to
 have a bug in 32-bit codegen (fixed since then).


Ok.

-- 
/Jacob Carlborg



 Nov 28 2015



prev sibling next sibling parent reply Jonny <Jonny nomail.com>  writes:


On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
wrote:

 OT: Readers of this NG probably know me under the name "ponce", 
 however over the year I was made aware that it's an english 
 swear word so I'll post under my IRL name from now on.

 I'm happy to release my first commercial software, it's a voice 
 effect designed for singers, follows the VST 2.x format, and is 
 made entirely with D (LDC 0.16.0 for OSX 64-bit, DMD 2.069.0 
 for the rest).

 http://www.auburnsounds.com/products/Graillon.html

 Using D has been an interesting ride, even for a long-time 
 user, but it went better than expected.

 I don't really have a point to prove, but I'm really tired with 
 people arguing that a language with GC can't possibly do 
 real-time. It's not like you are unallowed to optimize.

 I've only ever worked in real-time systems. All of those, 
 except for one with 32kB of RAM, could have afforded a GC.
 Actually very, very few development time was allocated to deal 
 with the GC, if any.

 If you want to make audio effects with D too, this one uses 
 "dplug" which was announced already: 
 https://github.com/p0nce/dplug

 Thanks for reading.


You have no idea what you are talking about! It is mentalities 
like yours that cause headaches for musicians and engineers who 
work with RT audio.

Do you realize that even 5 ms of jitter can be felt by the 
listener and musician as being off? 5 ms of latency can be felt 
and 20ms is unacceptable.

Now lets say you have 10 plugins being used, all with independent 
GC's doing their thing. You think it doesn't matter because you 
did some test in some controlled environment and it "worked" 
given your set of assumptions and hypothesis.

Yet, when your product gets out in the real world, you will cause 
enough grief that instead of helping the community you will hurt 
it.

What if someone wants to use your plugin live? You think it is 
acceptable to have latency and jitter? What about glitches 
because your GC decides to run at the same time as all the other 
GC's?

But keep on dictating how great GC's are for real time audio!

I do commend you for doing a plugin in D, but basically your 
logic is "It's ok to point a gun at people and pull the trigger 
as long as it's not loaded"(and we all know that it turns out in 
the long run).

If you spend 10 hrs a day working in a DAW with thousands of 
VST's you'd have more of an appreciation of RT audio and design.



 Nov 27 2015



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat

 I don't really have a point to prove, but I'm really tired 
 with people arguing that a language with GC can't possibly do 
 real-time. It's not like you are unallowed to optimize.


 What if someone wants to use your plugin live? You think it is 
 acceptable to have latency and jitter? What about glitches 
 because your GC decides to run at the same time as all the 
 other GC's?


I quoted both things because I think you missed the important 
part that he did, in fact, optimize the real time parts to avoid 
latency.



 Nov 27 2015



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Friday, 27 November 2015 at 18:09:08 UTC, Adam D. Ruppe wrote:

 On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat

 I don't really have a point to prove, but I'm really tired 
 with people arguing that a language with GC can't possibly do 
 real-time. It's not like you are unallowed to optimize.


 What if someone wants to use your plugin live? You think it is 
 acceptable to have latency and jitter? What about glitches 
 because your GC decides to run at the same time as all the 
 other GC's?


 I quoted both things because I think you missed the important 
 part that he did, in fact, optimize the real time parts to 
 avoid latency.


He did not miss it. He simply wanted to do the internet 
equivalent of putting his balls on the table to show how much of 
a dominant male he is.



 Nov 28 2015



  parent reply Jonny <Jonny nomail.com>  writes:


On Saturday, 28 November 2015 at 20:56:28 UTC, deadalnix wrote:

 On Friday, 27 November 2015 at 18:09:08 UTC, Adam D. Ruppe 
 wrote:

 On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume 
 Piolat

 I don't really have a point to prove, but I'm really tired 
 with people arguing that a language with GC can't possibly 
 do real-time. It's not like you are unallowed to optimize.


 What if someone wants to use your plugin live? You think it 
 is acceptable to have latency and jitter? What about glitches 
 because your GC decides to run at the same time as all the 
 other GC's?


 I quoted both things because I think you missed the important 
 part that he did, in fact, optimize the real time parts to 
 avoid latency.


 He did not miss it. He simply wanted to do the internet 
 equivalent of putting his balls on the table to show how much 
 of a dominant male he is.



I feel sorry for you. You are filled with hatred. I'm sorry if 
your life sucks, but no reason to blame me, put the blame 
squarely where it goes... on yourself.

If you actually did any RT music for a living, it would be a big 
issue, instead, you cowardly make your pathetic remarks behind a 
keyboard and have no clue about the real issues involved.

I hope you get things figured out before you die, else you've 
wasted your life ;/



 Nov 28 2015



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Sunday, 29 November 2015 at 05:59:19 UTC, Jonny wrote:

 I feel sorry for you. You are filled with hatred. I'm sorry if 
 your life sucks, but no reason to blame me, put the blame 
 squarely where it goes... on yourself.

 If you actually did any RT music for a living, it would be a 
 big issue, instead, you cowardly make your pathetic remarks 
 behind a keyboard and have no clue about the real issues 
 involved.

 I hope you get things figured out before you die, else you've 
 wasted your life ;/


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.



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


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.).



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


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.



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


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



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


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.



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


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).



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Sunday, 29 November 2015 at 13:21:53 UTC, Ola Fosheim Grøstad 
wrote:

 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.


The hard thing about live pitch-tracking is getting the minimal 
latency keeping reliability. It's not that simple. You also want 
"voicedness", which is more challenging than pitch.


 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.


Thought about it but a singer could usually cover a range of 3 
octaves, even if very few song mandate it: 
https://www.youtube.com/watch?v=cveoHrMyUDs&t=41s.

A man voice could go as low as say 40hz.
Only if you would need only one period to guess the pitch 
(unlikely), that's already 25ms latency guaranteed, and that's 
before you introduce FFT overlap! (if you want eg. to track 
harmonics, get formants through linear prediction, etc).

I've not tried the multiple FFT, I was worried pitch would lag 
oddly when changing FFT size. Perhaps it could work.



 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).


I have trouble to imagine the reconstruction so don't use them 
(well, I did once, but didn't _get_ it).



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 29 November 2015 at 15:13:41 UTC, Guillaume Piolat 
wrote:

 The hard thing about live pitch-tracking is getting the minimal 
 latency keeping reliability. It's not that simple. You also 
 want "voicedness", which is more challenging than pitch.


I think they developed it for a specific work, but IIRC it was 
challenging to get it accurate.

I don't now much about current pitch trackers, but I think you 
can do a high quality one for voice using filterbanks. Some 
people do resynthesis that way (and well, that is just an 
alternative to FFT after all). That's pretty much how cochlea 
works, I think, by having overlapping frequency bands. But it 
probably is hard to get right. I assume you can make a better 
pitch tracker that is specialized for voice by thinking about FoF 
synthesis, the sound of the voice is really a sequence of bursts 
of roughly the same shape (like granular synthesis in a way) and 
you should be able to figure out some statistical relationship 
between formants and how they change with pitch. I'm not saying 
it is easy. Probably a lot published on this though.

I don't know what "voicedness" is? You mean things like vibrato?


 I've not tried the multiple FFT, I was worried pitch would lag 
 oddly when changing FFT size. Perhaps it could work.


I think it should work in theory, but you'll probably get some of 
complications due to the distortions that comes with the 
windowing function etc? And making a real time phase vocoder is 
more work than it looks like on paper... Obviously doable, but 
there are some "missing bits" in the theoretical descriptions. I 
guess that's why IRCAM can sell licenses to superVP. :)


 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).


 I have trouble to imagine the reconstruction so don't use them 
 (well, I did once, but didn't _get_ it).


Yeah, I don't know. Still, in the past few years it has been 
popular with distorted and glitchy sounds, so maybe one could do 
some cool distorted effects with it.



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Sunday, 29 November 2015 at 15:34:34 UTC, Ola Fosheim Grøstad 
wrote:

 I don't now much about current pitch trackers, but I think you 
 can do a high quality one for voice using filterbanks. Some 
 people do resynthesis that way (and well, that is just an 
 alternative to FFT after all).


You are precisely right, if you don't need reconstruction nothing 
forces you to use the FFT!
There is also a sample-wise FFT I've came across, which is 
expensive but avoids chunking.



 I assume you can make a better pitch tracker that is 
 specialized for voice by thinking about FoF synthesis, the 
 sound of the voice is really a sequence of bursts of roughly 
 the same shape (like granular synthesis in a way) and you 
 should be able to figure out some statistical relationship 
 between formants and how they change with pitch.


Looking for similar grains is the idea behind the popular 
auto-correlation pitch detection methods. Require two periods 
else no autocorrelation peak though. The rumor says that the 
non-realtime Autotune works with that, along with many modern 
pitch detection methods.



 I'm not saying it is easy. Probably a lot published on this 
 though.

 I don't know what "voicedness" is? You mean things like vibrato?


vibrato is the pitch variation that occur when the larynx is well 
relaxed.

voicedness is the difference between sssssss(unvoiced) and zzzzzz 
(voiced).
A phonem is voiced when there is periodic glottal closure and 
openings.

When the sound isn't voiced, there is no period. There isn't a 
"pitch" there. So pitch detection tend to come with a confidence 
measure.

The devil in that is that voicedness itself is half a lie, or let 
say a leaky abstraction, it breaks down for distorted vocals.


 I guess that's why IRCAM can sell licenses to superVP. :)


Their paper on that topic are interesting, they group spectral 
peaks by formants and move them together.



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 29 November 2015 at 16:15:32 UTC, Guillaume Piolat 
wrote:

 There is also a sample-wise FFT I've came across, which is 
 expensive but avoids chunking.


Hm, I don't know what that is :).


 Looking for similar grains is the idea behind the popular 
 auto-correlation pitch detection methods. Require two periods 
 else no autocorrelation peak though. The rumor says that the 
 non-realtime Autotune works with that, along with many modern 
 pitch detection methods.


I thought they used Laroche and Dolson's FFT based one combined 
with a peak detector, but maybe that was the real time version.

There are other full spectral resynthesis methods that throw away 
phase information and represent each spectral components as a 
bandpass filter of noise. That is rather expressive since you can 
do morphing with it. (Like you can do with images). But since you 
throw away phase information I guess some attacks suffer, so you 
have to special case the attacks as "residue" samples that are 
left in the time domain (the difference between what you can 
represent as spectral components and the left over bits).


 I don't know what "voicedness" is? You mean things like 
 vibrato?


 vibrato is the pitch variation that occur when the larynx is 
 well relaxed.


Yes, so that will generate sidebands in the frequency spectrum, 
like FM synthesis, right? So in order to pick up fast vibrato I 
would assume you would also need to do analysis of the spectrum, 
or?


 voicedness is the difference between sssssss(unvoiced) and 
 zzzzzz (voiced).
 A phonem is voiced when there is periodic glottal closure and 
 openings.


Ah! In the 90s I read a paper in Computer Music journal where 
they did song synthesis by emulating the vocal tract as a 
"physical" filter-model. I'm not sure if they used FoF for 
generating the sound. I think there was a vinyl flexi disc with 
it too. :-) I have it somewhere...

You might find it interesting.


 When the sound isn't voiced, there is no period. There isn't a 
 "pitch" there. So pitch detection tend to come with a 
 confidence measure.


So it is a problem for real time, but in non-real time you can 
work your way backwards and fill in the missing parts before 
doing resynthesis? I guess?


 The devil in that is that voicedness itself is half a lie, or 
 let say a leaky abstraction, it breaks down for distorted 
 vocals.


Right. You have a lot of these problems in sound analysis. Like 
sound separation. The brain is so impressive. I still have 
problem understanding how we can hear 3D with two ears. Like 
distinguishing above and below. I understand the basics of it, 
but it is still impressive when you try to figure out _how_.


 I guess that's why IRCAM can sell licenses to superVP. :)


 Their paper on that topic are interesting, they group spectral 
 peaks by formants and move them together.


I've read the Laroche and Dowson paper in detail, and more or 
less know it by heart now, but maybe you are thinking about some 
other paper? Their paper was good on the science part, but they 
leave the artistic engineering part open to the reader... ;-) 
More insight on the artistic engineering part is most welcome!!



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Sunday, 29 November 2015 at 17:23:20 UTC, Ola Fosheim Grøstad 
wrote:



 Yes, so that will generate sidebands in the frequency spectrum, 
 like FM synthesis, right?


It won't because the vibrato frequency is too low, around 10hz.


 So in order to pick up fast vibrato I would assume you would 
 also need to do analysis of the spectrum, or?


Or just be fast to react, else this vibrato amplitude would be 
smoothed out.



 So it is a problem for real time, but in non-real time you can 
 work your way backwards and fill in the missing parts before 
 doing resynthesis? I guess?


In non-realtime, everything is possible, you can have a bigger 
analysis window and much less problems.
For example, some use dynamic programming for pitch detection.


 I've read the Laroche and Dowson paper in detail, and more or 
 less know it by heart now, but maybe you are thinking about 
 some other paper? Their paper was good on the science part, but 
 they leave the artistic engineering part open to the reader... 
 ;-) More insight on the artistic engineering part is most 
 welcome!!


Whatever the method, it's important to spend a lot of time in 
tuning.



 Nov 29 2015



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 29 November 2015 at 17:36:47 UTC, Guillaume Piolat 
wrote:

 On Sunday, 29 November 2015 at 17:23:20 UTC, Ola Fosheim 
 Grøstad wrote:



 Yes, so that will generate sidebands in the frequency 
 spectrum, like FM synthesis, right?


 It won't because the vibrato frequency is too low, around 10hz.


Right, so it will only be a serious problem if one went beyond 
2048 samples FFT, which isn't really necessary.

This is an interesting swedish paper on vibrato btw:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.436.4888&rep=rep1&type=pdf



 Nov 29 2015



prev sibling next sibling parent  Radu <radu void.null>  writes:


On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
 wrote:

 [...]


 You have no idea what you are talking about! It is mentalities 
 like yours that cause headaches for musicians and engineers who 
 work with RT audio.

 [...]


Dude, you missed the point completely. He did all RT stuff 
without a GC, he said that the GC can be made irelevant by using 
some clever optimizations and using the tools the language 
provides.

I also suspect you don't really know how D's GC works.



 Nov 27 2015



prev sibling  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 You have no idea what you are talking about! It is mentalities 
 like yours that cause headaches for musicians and engineers who 
 work with RT audio.

 Do you realize that even 5 ms of jitter can be felt by the 
 listener and musician as being off? 5 ms of latency can be felt 
 and 20ms is unacceptable.


"jitter" is not "latency", you don't have "5 ms" of jitter.


 What if someone wants to use your plugin live? You think it is 
 acceptable to have latency and jitter?


https://yourlogicalfallacyis.com/strawman

Besides, noone reported anything like that, because there is no 
reason for it to happen (see below).



 What about glitches because your GC decides to run at the same 
 time as all the other GC's?


Actually the GC never triggers, and if it triggers:
- the heap size is so small it would get scanned super fast
- the audio thread isn't blocked since unregistered

Tell me more how I can bring harm to this world.



 If you spend 10 hrs a day working in a DAW with thousands of 
 VST's you'd have more of an appreciation of RT audio and design.


But you have that understanding, I guess?



 Nov 27 2015



 next sibling parent reply Marco Leise <Marco.Leise gmx.de>  writes:


We can probably agree that we don't know about the impact on a
large multimedia application written in D. What you can
communicate is: Create a  nogc thread routine and don't
register it with the GC to write real-time VSTs.

Guillaume did a good job, taking the GC out of the real-time
thread. It's D, it is a bit of a hack, it's the correct way to
do it and works. But I don't see it debunking any myths about
GC and real time...
A) It doesn't mix them to begin with.
B) "Realtime GCs" are a thing. D's GC is not optimized for
   such a use case.
C) With a small heap it doesn't matter. (We need more complex
   multimedia projects.)

What I've seen is a program, a non-linear video editor, called
PowerDirector that pauses for seconds every now and then.
These pauses reminded me a lot of GC pauses, but I can't be
sure. Although memory use is less after the pause, it could
also be a cleaning of caches. In any case quite a few of these
applications try to make "good use" of available RAM, causing
constant memory pressure.

Now there has been so much talk about the GC that I don't even
know what the filter does!

-- 
Marco



 Nov 27 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise wrote:

 We can probably agree that we don't know about the impact on a 
 large multimedia application written in D. What you can 
 communicate is: Create a  nogc thread routine and don't 
 register it with the GC to write real-time VSTs.

 Guillaume did a good job, taking the GC out of the real-time
 thread. It's D, it is a bit of a hack, it's the correct way to
 do it and works. But I don't see it debunking any myths about
 GC and real time...
 A) It doesn't mix them to begin with.
 B) "Realtime GCs" are a thing. D's GC is not optimized for
    such a use case.
 C) With a small heap it doesn't matter. (We need more complex
    multimedia projects.)


But the claim we hear on Internet forums is:

- "can't do realtime with a GC language" (wat)
- "GC leads to GC pauses" (only if you let them happen)

Which is imho a shortcut.



 What I've seen is a program, a non-linear video editor, called 
 PowerDirector that pauses for seconds every now and then. These 
 pauses reminded me a lot of GC pauses, but I can't be sure. 
 Although memory use is less after the pause, it could also be a 
 cleaning of caches. In any case quite a few of these 
 applications try to make "good use" of available RAM, causing 
 constant memory pressure.


I've seen my share of GC pauses and they did annoy me.
In some language like Javascript they are very hard to avoid.

However here I'd say it's a PowerDirector problem, not a GC 
problem.


 Now there has been so much talk about the GC that I don't even 
 know what the filter does!


Reason enough not to write a blog post for me :). I'm not in a 
crusade.



 Nov 28 2015



  parent reply Warwick <warwick warwick.com>  writes:


On Saturday, 28 November 2015 at 11:35:56 UTC, Guillaume Piolat 
wrote:

 On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise 
 wrote:

 We can probably agree that we don't know about the impact on a 
 large multimedia application written in D. What you can 
 communicate is: Create a  nogc thread routine and don't 
 register it with the GC to write real-time VSTs.

 Guillaume did a good job, taking the GC out of the real-time
 thread. It's D, it is a bit of a hack, it's the correct way to
 do it and works. But I don't see it debunking any myths about
 GC and real time...
 A) It doesn't mix them to begin with.
 B) "Realtime GCs" are a thing. D's GC is not optimized for
    such a use case.
 C) With a small heap it doesn't matter. (We need more complex
    multimedia projects.)


 But the claim we hear on Internet forums is:

 - "can't do realtime with a GC language" (wat)
 - "GC leads to GC pauses" (only if you let them happen)

 Which is imho a shortcut.


Just to play devils advocate... you haven't proved GC can do real 
time if you achieve it by quarantining the real time code from 
the GC.

It's kind of like saying you can climb a mountain on a bycicle if 
you get of an carry it on the bits that are too steep.

That said, the basic idea is that you shouldn't do anything that 
might take too long or use any mutex / locks. That is the same 
whether you use C++, Pascal, or D.

The real story is how easy D makes it to achieve that.



 Nov 28 2015



 next sibling parent  deadalnix <deadalnix gmail.com>  writes:


On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote:

 Just to play devils advocate... you haven't proved GC can do 
 real time if you achieve it by quarantining the real time code 
 from the GC.


Well I think it is a fair thing to do. GC is a tradeoff, and 
while not usable in all situations, makes thing way simpler when 
it is usable. The usual story is my ho so important real time 
thing can't possibly tolerate a GC, while, really, most of the 
code is going to do mundane tasks like UI and only a small 
portion of it really needs not to have the GC in its way.

It just good engineering to use the tools available when 
appropriate.


 It's kind of like saying you can climb a mountain on a bycicle 
 if you get of an carry it on the bits that are too steep.


As opposed to "you can't climb a mountain with a bike, so you 
must not go to the shop buying climbing equipment with a bike 
either".



 Nov 28 2015



prev sibling  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote:

 It's kind of like saying you can climb a mountain on a bycicle 
 if you get of an carry it on the bits that are too steep.
 *snip*
 The real story is how easy D makes it to achieve that.


Indeed... the beauty of a bike is you can get off and walk with 
it. It is a lot easier to push a bike up a mountain than a car!



 Nov 28 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Saturday, 28 November 2015 at 21:05:24 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote:

 It's kind of like saying you can climb a mountain on a bycicle 
 if you get of an carry it on the bits that are too steep.
 *snip*
 The real story is how easy D makes it to achieve that.


 Indeed... the beauty of a bike is you can get off and walk with 
 it. It is a lot easier to push a bike up a mountain than a car!


What is the better tool to bring to the top of a mountain?

https://www.youtube.com/watch?v=Yan1SekLB5k

https://www.youtube.com/watch?v=rnvvsjstveM



 Nov 28 2015



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Saturday, 28 November 2015 at 21:30:38 UTC, Ola Fosheim 
Grøstad wrote:

 What is the better tool to bring to the top of a mountain?


Only maniacs go down mountains. The fun part is the ascent... the 
descent is an exceedingly painful journey through the ultimate 
experience in grueling terror, no matter how you try to do it. 
Even *walking* down a mountain yields knee pain...



 Nov 28 2015



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Saturday, 28 November 2015 at 21:39:06 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 28 November 2015 at 21:30:38 UTC, Ola Fosheim 
 Grøstad wrote:

 What is the better tool to bring to the top of a mountain?


 Only maniacs go down mountains. The fun part is the ascent... 
 the descent is an exceedingly painful journey through the 
 ultimate experience in grueling terror, no matter how you try 
 to do it. Even *walking* down a mountain yields knee pain...


Right, and at that point you really wish you didn't bring the 
bike along and had spent some money on linear typed footwear 
instead.



 Nov 28 2015



prev sibling  parent reply Jonny <Jonny nomail.com>  writes:


On Saturday, 28 November 2015 at 01:31:22 UTC, Guillaume Piolat 
wrote:

 On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:

 You have no idea what you are talking about! It is mentalities 
 like yours that cause headaches for musicians and engineers 
 who work with RT audio.

 Do you realize that even 5 ms of jitter can be felt by the 
 listener and musician as being off? 5 ms of latency can be 
 felt and 20ms is unacceptable.


 "jitter" is not "latency", you don't have "5 ms" of jitter.


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...

Now, if you are so intelligent as you think you are, you can see 
by simple dimensional analysis that you get the same unit as what 
you measured with.

While, this doesn't prove you don't have a clue about jitter, my 
guess is, you don't.

Believe me, jitter is a big deal. If you spent as much time doing 
music as you did programming, you'd realize that. Go spend 5 
years learning to play the drums properly then come back and 
we'll do some tests and see if you believe the same thing.


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.

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?

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.

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... regardless if it 
behaves like RT 99.99% percent. (there is something about 
guaranteed *maximum* latency that you have to deal with)



 Nov 28 2015



 next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


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. It is 
unfortunately common in these forums to overstate what D features 
are good for. It's just the usual fanboism superiority complex, 
it is an annoying aspect of the D culture, I agree. Just don't 
let it get to you, it is present in just about every thread. :-)



 Nov 29 2015



  parent reply Guillaume Piolat <first.last gmail.com>  writes:


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).



 Nov 29 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


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).



 Nov 29 2015



  parent  Guillaume Piolat <first.last gmail.com>  writes:


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.



 Nov 29 2015



prev sibling next sibling parent reply Any <hot_katjans hotmail.com>  writes:


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.



 Nov 29 2015



  parent reply Warwick <warwick warwick.com>  writes:


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".



 Nov 29 2015



  parent  Guillaume Piolat <first.last gmail.com>  writes:


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.



 Nov 29 2015



prev sibling  parent  Guillaume Piolat <first.last gmail.com>  writes:


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?



 Nov 29 2015



prev sibling  parent reply Thomas <ThomasJefferson gmail.com>  writes:


On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
wrote:

 OT: Readers of this NG probably know me under the name "ponce", 
 however over the year I was made aware that it's an english 
 swear word so I'll post under my IRL name from now on.

 [...]


Hi, Is there a tutorial on how to design VST's using D? I would 
like to get into vst programming using D but I've found little 
useful information.

Thanks



 Dec 17 2015



 next sibling parent  Guillaume Piolat <first.last gmail.com>  writes:


On Thursday, 17 December 2015 at 18:17:41 UTC, Thomas wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
 wrote:

 OT: Readers of this NG probably know me under the name 
 "ponce", however over the year I was made aware that it's an 
 english swear word so I'll post under my IRL name from now on.

 [...]


 Hi, Is there a tutorial on how to design VST's using D? I would 
 like to get into vst programming using D but I've found little 
 useful information.

 Thanks


- checkout the dplug repositery
- make sure you have DUB and DMD
   * On Windows, build the example in examples/distort with DUB by 
typing "dub"
   * For Mac VST bundles, you will need to build the "release" 
tool in tools/release
     then type "release"
- to make a new VST, copy-paste the examples/distort directory



 Dec 17 2015



prev sibling  parent  Guillaume Piolat <contact gam3sfrommars.fr>  writes:


On Thursday, 17 December 2015 at 18:17:41 UTC, Thomas wrote:

 On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat 
 wrote:

 OT: Readers of this NG probably know me under the name 
 "ponce", however over the year I was made aware that it's an 
 english swear word so I'll post under my IRL name from now on.

 [...]


 Hi, Is there a tutorial on how to design VST's using D? I would 
 like to get into vst programming using D but I've found little 
 useful information.

 Thanks


I've written a tutorial to hopefully make it easier.

http://www.auburnsounds.com/blog/2016-02-08_Making-a-Windows-VST-plugin-with-D.html



 Feb 09 2016