Off topic bit from mosaic thread

System

This discussion was created from comments split from: MOZAIC - Create your own AU MIDI plugins - OUT NOW!.

[Deleted User]

@brambos said:
What are you guys doing running into those limits??

Realtime environments do not allow dynamic memory

This is actually a MYTH that is desperately and blindly repeated by many developers.

Probably some parts of the Apple development documentations are not well understood by them.

Its surely a bad idea to continuously allocate memory inside an audio processing loop. but memory allocation is so essential in general for any programming, that it cannot be generalized to this conclusion.

And also the praxis of developing audio units should actually show, that this myth is just not true. You surely can allocate memory, but you should do it smartly and not inside a core processing loop. Infact, many audio units would not be possible if that ‚limitation‘ relly would apply.

Actually there is also a strict separation of core audio process and the UI process, which are b.t.w. in complete different threads of the so-called „realtime environment“. Especially the UI thread is continuously allocating and deallocating resources, also the intermediating processes.

The core MIDI (realtime) processes would not be possible without allocating memory in realtime at all, also not the entire audio engine of any powerful system, which is by design optimized for real time memory allocations/deallocations. Even the entire audio unit system is based of dynamically allocated resources and processing. There are no static limitations, except the developer decided to implement such.

Excessive memory allocations may block the audio process, yes this is true. But this applies to ANY performant programming technique, as memory is a thing that should be used with some care.

Mod edit for posterity: This post contains factually incorrect information. See Four Common Mistaken in Audio Development for a discussion on this topic.

brambos

@JG_digister_com said:
This is actually a MYTH that is desperately and blindly repeated by many developers.

No, it's not a myth, and it's a definite no-no.

Dynamic memory allocation uses locks. There is no way of predicting how long the process will take. Hence you should never do it on a real-time thread.

[Deleted User]

@brambos said:

@JG_digister_com said:
This is actually a MYTH that is desperately and blindly repeated by many developers.

No, it's not a myth, and it's a definite no-no.

Dynamic memory allocation uses locks. There is no way of predicting how long the process will take. Hence you should never do it on a real-time thread.

Well, as I already explained. The UI of an audio unit for instance is continuously and exessively allocating memory. You can actually watch this with the Instruments profiler app inside XCode. Then you also will discover that the audio thread itself is continuously allocating resources. Its a myth.

Of course you should not allocate inside the core dsp loop. but the things your plugin is doing, actually does not process audio. the allocations can be made securely outside a processing loop, even at initialization after parsing the parameters.

You may say us that you limited the resource usage, but pleas do not come again with this old „memory locations forbidden“ paradigm. it is just not true. it is in fact a thoughtless claim to flash the users, and by the way, shows missing knowledge to anyone, who actually can understand how computer systems work.

brambos

@JG_digister_com said:

@brambos said:

@JG_digister_com said:
This is actually a MYTH that is desperately and blindly repeated by many developers.

No, it's not a myth, and it's a definite no-no.

Dynamic memory allocation uses locks. There is no way of predicting how long the process will take. Hence you should never do it on a real-time thread.

Well, as I already explained. The UI of an audio unit for instance is continuously and exessively allocating memory. You can actually watch this with the Instruments profiler app inside XCode. Then you also will discover that the audio thread itself is continuously allocating resources. Its a myth.

Of course you should not allocate inside the core dsp loop. but the things your plugin is doing, actually does not process audio. the allocations can be made securely outside a processing loop, even at initialization after parsing the parameters.

The UI is not on the real-time thread, so that's a completely different story. I allocate stuff in the GUI all the time. It's the sloppiest place in the galaxy.

My Mozaic virtual machine obviously runs inside the realtime-thread so it has to live by the rules. No dynamic memory allocation, no ObjC/Swift/unsafe C++, no locks.

You're free to do things differently. Your code will happily compile and in the real world you'll probably get away with it, until you don't. And then you will get reports about mysterious phantom issues from your users. Or worse, people will blame the host for the things that the plugin does wrong.

I really recommend sticking to the rules.

[Deleted User]

Well, this is misunderstanding of roles.
You can always establish a thread for instance that allocates the desired resources and waiting until it has finished. A very basic aproach. The real time thread would not break this way.

By the way, most audio units and audio hosts are using C++ exessively, with NO issues. this is just another ridiculous MYTH.

What has C++ that locks audio realtime processes??? Please explain. This is by the way : pure nonsense. I’ve seen ppl talking this kind of shit at other places too. Just repeating this, is not a prove of knowledge. it is just mythological nonsense.

The official Apple example code for the Audio Unit framework actually uses plain C++ in the core audio processing. You are proved wrong. I am asking now how your units are coded. ^^ probably assembler. 😤

brambos

@JG_digister_com said:
Well, this is misunderstanding of roles.
You can alwas establish a thread for instance that allocates the desired resources and waiting until it has finished. A very basic aproach. The real time thread would not break this way.

By the way, most audio units and audio hosts are using C++ exessively, with NO issues. this is just another ridiculous MYTH.

What has C++ that locks audio realtime processes??? This is by the way : pure nonsense. I’ve seen ppl talking this kind of shit at other places. Just repeating this, is not a prove of knowledge.

I'm sorry, but you're incorrect and these are not myths. You're free to take this to PM, because it is cluttering up the Mozaic thread.

Also, I don't think your tone is necessary at all.

[Deleted User]

Ok. but the answers are just missing.

kin

And the award for the worlds rudest person goes to.....
I know nothing about coding But apparently good manners and basic social etiquette are not essential for it.
Thanks for your continued good work @brambos

gsm909

Seems a bit strange for a dev to come in and argue with GOD himself

@JG_digister_com love the filters. Excellent sound.
@brambos , carry on as before. Lead the way sir.

DCJ

I don’t think I can give this JAF dev any more of my money. His tone absolutely stinks.

Finally bought mozaic yesterday though. Thank you to all the script makers here and to Bram for being brilliant.

[Deleted User]

please excuse me. but I can”t see if users are scammed with nonsense and repeated false “myths”, instead of just being honest and saying the truth.

mojozart

@JG_digister_com if you have a beef with Michael Tyson's 4 cardinal rules of audio programming, or Bram's version of the same, I suggest you start your own thread to discuss. Honestly, I think it could be an enlightening discussion:

http://atastypixel.com/blog/four-common-mistakes-in-audio-development/

1. Don’t hold locks on the audio thread. Like pthread_mutex_lock or @synchronized.
2. Don’t use Objective-C/Swift on the audio thread. Like [myInstance doAThing] or myInstance.something.
3. Don’t allocate memory on the audio thread. Like malloc(), or new Abcd or [MyClass alloc].
4. Don’t do file or network IO on the audio thread. Like read, write or sendto.

[Deleted User]

sound just a little better. but “don”t use C++ is just plain wrong and stupid information.

Look at the AudioUnit examples from Apple:

`import "DSPKernel.hpp"
import "ParameterRamper.hpp"
import <vector>`

...

this is just a snipped from the header of these files.

There”s everything ! written in C++.

Even vector is an highly dynamical approach for coding in C++. Period.
I am coding audio stuff in C++ since 20 years.

So my appologies if someone is feeling attacked.

brambos

@JG_digister_com said:
sound just a little better. but “don”t use C++ is just plain wrong and stupid information.

Read carefully what I wrote: don't use unsafe C++.

Things like resizing vectors and malloc are not safe. Now please take this to the dev-section of Audiobus or to PM. It doesn't belong in the Mozaic thread.

Thanks.

gusgranite

@JG_digister_com using terms like ‘scammed’ and calling the other developers’ honesty into question? And we should take the rest of what you say seriously?

Why not just spend a few nights installing @brambos’ and @j_liljedahl’s apps and get a feel for how they sound and how slick the UIs are. It might help you improve your own code and grow as a developer. I expect they will will even share some advice with you if you change your tone and apologize. They have helped so many other developers over the years.

brambos

Always happy to help anyone out. I'm standing on the shoulders of giants too, and I've learned and discussed tons of this stuff with colleagues like @Michael and @j_liljedahl . There's a bunch of developer-places where we hang out and question all these things. We're not making these things up and we happily point out where things can be improved.

Just as an example: Michael even made a tool to test where in your code unsafe shenanigans are going on. So we're talking hard, real-world evidence.

The end-goal is to provide reliable software; peddling arcance developer mantras is not the point for anyone.

Michael

Oh, dear.

brambos

@Michael said:
Oh, dear.

Thanks for the thread-split, Michael.

Michael