You make it sound like C++ modules are actually a usable thing now? That’d be news to me. The commonly used compilers now actually support it?
I mean don’t take my word on anything x) I just got the impression to use them when I first started researching cpp. How they hold up in a real world scenario, no idea. I know clang++ 18.1.3 supports it and CMake 3.30 as well (since 3.28 I believe), I been using it all along. If anyone is curious how to build with them I can share a doc I have. I’ll spare dumping it here for now, but will on request 
edit :
For Clang, install LLVM/Clang 16.0 or newer.
For GCC, install GCC 14 and GCC 14 2023-09-20 daily bump or newer.
Well, maybe I will take a look some day soon. But I feel like the modules are still way too new to invest much time and effort in. Once they work properly across all the common compilers and platforms, they will no doubt be great. Working with C++ for almost 20 years has taught me to be relatively conservative about new things. 
1 Like
I seee… and cautious you should be, your probably doing real production work. By the time I have any real projects that would make me cautious of using the new shiny thing, they will probably be more trusted. Glad I could bump your interest tho 
looking forward to them throwing a wrench in all my study projects
I pushed the doc to the readme of my practice repo for the record, might spare someone the dig :
1 Like
lol you were right…thats a wrap on modules if you want to use Qt. no big deal I guess
Hi,
This might be one of those annoying responses, but why not just use Juce for your UI instead of Qml? From skimming over this thread, it seems to me that you are trying to solve a lot of low-level problems that would simply vanish if you just used Juce and started with a standard template. That’s the beauty of having an integrated library. Is there something specific that you want to accomplish with your UI that you’re worried Juce can’t handle?
BTW, you’re way ahead of where I was after 3 months of software development 
Ehh i dunno really, I never really gave JUCE a decent shot for gui. I’m sure its well capable of what I would want to do…I got annoyed with it early on tryin to make layout or somthing and just assumed Qt would be better in the long term since it’s the global standard for interfaces and has alot of bells and whistles. I figure it would pay off in the long run…obviously comes with a price to pay. Gives you a broader scope for employment also so kinda two birds one stone thing. not tryin to dump on juce in any way, but theres no turin back now x) and its given me a reason to dig into juce guts
and thanks I been laid off so been going hard on it lol its been rough
This may not be the case. I can’t tell you how much time I have invested into learning a new library and integrating it into my project, only to pry it out months (or years) later when I finally realized it was the wrong tool for the job. As you mentioned, it’s all about trying to figure out what will pay off in the long run. Sometimes you invest time in something that ends up paying 10x as soon as you get the hang of it. Other times it turns out to be a complete dead end. If only we could tell before-hand!
Keep us updated with how its going.
2 Likes
I just want to say I am writing these kinds of post as like a solilquy (a note to self), just to share and for anyone that comes after me… not tryin to act like I’m informing anyone, I’m the nublet here
About this, from my long post. I knew by looking at the code this is the only method that could return the samples, but couldn’t see how it was called. I attached a debugger to getNextAudioBlock(), trying to understand what was running on my audio thread and accidentally found this :
So there it is. There is a subclass of juce::Thread that calls AudioDeviceManager::CallbackHandler::audioDeviceIOCallbackWithContext and then
AudioDeviceManager::audioDeviceIOCallbackInt
From there, you can follow the smaller diagram from my previous post to see the path to the samples.
juce::ALSAThread::run juce_ALSA_linux.cpp:726
So I think, this method is literally your audio thread. If you look into juce::Thread(), inside the run() method is what gets executed on the new thread. It created a ALSAThread because I’m on linux. When you ran AudioDeviceManager.initialise(), it probably created this in that chain reaction. My first guess would be when it hits currentAudioDevice->open, or somewhere around there.
Anyways I’m putting a flag in the ground on this train of thought. I have alot of other stuff to get to, and this can’t be a priority (and those threadEntryPoint() calls is like looking over the edge of a cliff). Wayyy over my head here, but this might come into play like a year from now