Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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 sss(unvoiced) and zz (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!!
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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=rep1=pdf
Re: Graillon 1.0, VST effect fully made with D
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=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).
Re: Graillon 1.0, VST effect fully made with D
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. :-)
Re: Graillon 1.0, VST effect fully made with D
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.).
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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".
Re: Graillon 1.0, VST effect fully made with D
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).
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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).
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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?
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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).
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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 sss(unvoiced) and zz (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.
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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...
Re: Graillon 1.0, VST effect fully made with D
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".
Re: Graillon 1.0, VST effect fully made with D
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!
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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)
Re: Graillon 1.0, VST effect fully made with D
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 ;/
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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).
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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/
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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?
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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.
Re: Graillon 1.0, VST effect fully made with D
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
