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

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.

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.

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.

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/

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.

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

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

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.

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.