The message-handler is used a lot in JUCE to facilitate callbacks, send messages between threads etc. but if the GUI of an audio-plugin is not open, then these messages are not delivered, thus callbacks aren’t called etc.
Would it be possible to have a timer running that regularly checks for undelivered messages and then calls
The timer would be started with plugin instantiation but paused while the GUI is open, so the MessageManager can do it’s “normal” job.
The purpose here is to facilitate downloads that happen in a separate thread and still get the callbacks on the main-thread. Or to use functionality which requires a working message-pump, like the gin::FileSystemWatcher.
The MessageManager is afaik not only present while the GUI is open. It is in fact used when the AudioPluginFormat is created, which is the base class for the wrappers.
So it should work independently from the GUI being open.
Also using a Timer to pump the MessageManager cannot work, since a timer callback is just a message in the MessageManager’s queue, which is only delivered when the MessageManager is running.
How did you come to the conclusion, that the MessageManager is not running?
(I didn’t test myself, but I am pretty confident, that it is independent from the GUI)
Should? I’m sorry, I’m not making this stuff up. I’m having this exact issue, that’s why I created this topic in the first place.
The object gets created, but it’s not being run. An audio-plugin is a black-box. It’s basically just a bunch of functions being called by the host. There is not function the host can call that says “make sure the plugins message-handler can handle its evens”.
Damn, didn’t think of that.
By writing code that depends on it (an async-updater) and the callback never being called.
Pretty confidend is not good enough. This is the second time now that you try to help (which is generally appreciated), but you actually don’t know. This doesn’t help. It actually harms, because now the Juce team will see this question as answered and not look at it anymore.
I would really appreciate, in the future, that if you don’t know for a fact something to be true, not to reply at all.
Daniel’s reply is pretty much what I’d have written…
I’ve not heard of this happening before, and the host should indeed always be pumping the message thread regardless of what plugins have UIs.
If you’re seeing it fail to do that then I’d guess it’s only going to be in a particular OS, and perhaps a particular plugin format and host…? Given that you’ve obviously not tested every combination of host/OS/format it’s always sensible to tell us which ones you actually have tried.
And even if you could get the host to call something on the event thread, pumping the event loop manually is very unsafe in a plugin. An event that it invokes could cause the host to unload the plugin that’s calling it. So basically, nope.
OK. Maybe I’m being dense here, maybe I’m missing something very obvious here.
For a Windows message-loop to work, you need to create a window (I know that Juce creates a hidden one) and then you have to wait for incoming messages via “GetMessage” as described here:
I’ve done this myself for my own Windows applications and it’s pretty standard.
Now, this loop is blocking, so it doesn’t return until the application is quit.
In the context of a VST2 plugin, how does Juce achieve to keep a working message-loop without blocking? A VST2 plugin is only a selection of a few important function-calls within a simple class. You only need a constructor, setSampleRate, setBlockSize, suspend, resume, setChunk, getChunk, processEvents and processReplacing for a fully functional VST2 instrument plugin.
All of these functions have to return as soon as possible. They can’t just block until the next message is received. So how does Juce achieve the message-loop giving the constraints of a VST2 plugin? I’ve looked at the relevant sources (MessageManager, application init, VST2 wrapper etc.) and I can’t figure out how this works.
The messages not working was in our own test-host (based on Juce plugin-hosting) that was waiting for the license to be downloaded in a background-thread, but the callback that the download was finished never arrived. This got us thinking about similar scenarios and after looking at everything, we came to the conclusion that it wouldn’t work.
Now again, my apologies if we missed something obvious here, but we can’t seem to figure out how it would work.
The reason we’re so concerned about this is that our licensing system is based on the idea that a license is only valid for a limited time (let’s say 35 days from the time it was downloaded last) but that each time the plugin gets loaded, it “refreshes” the license, thus if the plugin gets loaded at least once every 35 days, it would “just work” without any user interaction whatsoever, forever. Now if a user hasn’t used our plugin for a while and the user now loads a project with several instances of our plugin in it, without having ANY of their GUIs open, the license download would still happen in the background, but the plugin would never be informed about the finished download and the plugin wouldn’t work.
We’ve been working for over a year under the assumption that this is how we can do the licensing for our plugin, and finding out this late that there is a good chance it might not work at all gave us a small panic attack. So we yearned for some clarification and it was really frustrating reading “afaik”, “should” and “I’m pretty confident” instead of authoritative information.
We can’t find any evidence of Juce spinning up it’s own background thread to handle the messages or something similar. Again: maybe I’m being dense?
I beg of you: please assuaged my fears about our licensing scheme not working.
The juce event system has a hidden HWND behind the scenes (grep “HiddenMessageWindow”) which is where it sends/receives its messages. A plugin can’t run its own message loop, so it has to rely on the host to actually do the dispatching, but I don’t know of any that don’t, because any app with a GUI needs to do this. You said this fails in your own test host, but not whether it fails in real ones? Before you start getting into a panic about it not working, maybe make sure it’s not just a silly mistake in your test app (like e.g. running it as a console app without a message loop)
It was a silly mistake of our test app which is indeed hosting VST-plugins despite being a console-app without a message-loop. It’s running our plugin with various different presets, rendering out audio and then comparing it to “reference” versions of the same audio, to detect subtle (and sometimes not so subtle) changes that shouldn’t happen, to maintain 100% compatibility in output between versions.
I feel like you’ve approached this thread all wrong. When people tried to help you’ve shut them down for making useful suggestions saying those suggestions are “not good enough” and then constantly demanding answers.
Remember, people on the forums can’t see your code (unless of course you share it) so there’s always going to be some element of guesswork. As your last reply proves, you can’t make assumptions about anything and often the probing, suggestions and even questions not directly related to your initial query, is what gets you to your solution.
For me at least, the JUCE forums should be a welcoming place where everyone should feel confident of sharing advice and experience so we can all progress. I can’t begin to count the amount of things I’ve learnt by discussions around topics.
I understand you’ve had a bit of a tough day at the office and maybe didn’t mean to come off as rude, we all know that can happen, but a bit of humility goes a long way and may lead you to your answers more quickly rather than alienating forum members.
You are 100% right. This is 100% on me for not being patient enough. I’m sorry.
I would like to propose a (semi) private sub-forum in which “pro” users can ask questions that can only be answered by the juce-developers. Indie and free users can read, but not post there. It would be strictly for technical questions that are simple enough to answer by the developers as not to qualify for the extremely pricey “premium support” option.
The “premium” support would still work for more complicated, more involved problems that need a custom solution. But I feel that for the “simpler” technical problems, a forum where the replies are only posted by Juce developers with the knowledge required, would be the best way.
Or maybe a “semi premium support” program. I wouldn’t mind paying $50 to have my questions answered directly by @jules, @ed95 or @t0m. Jules reply to how a hidden window basically piggy-backs on the hosts message-pump would have completely sufficed, giving me peace of mind.
Heck, if @jules, @ed95 or @t0m are up for it, I would even send them beer money directly via PayPal for answering these more challenging questions.
I’m not mad at that idea, but only if it includes Juce 4 pro license holders too. A pro license is a pro license, regardless of if it has the badge or not.
But what about pro GPL users? How do they fit into the mix?
However, my 2 pence is this doesn’t really sound viable. Firstly, it’s not very “community” spirited, secondly, I’d think you’ll be shooting yourself in the foot deliberately rejecting help from others. There are some extremely experienced people in this forum and often complex discussions over problems are hashed out without any intervention from the JUCE team.
The JUCE team do an incredible job with the maintenance of the library and support of the forum, this suggestion feels like you’re saying that’s not good enough and you want a place to demand immediate and direct attention.
To be honest if feels like “premium” support but without the “premium”.
If you’re willing to pay for additional support, why not contact the JUCE team and actually engage some premium support?
But to me it feels like you’re seriously undervaluing the community support offord here.
Imagine if someone had actually done the exact thing you’re asking about (because a huge number of members here have completed a wide range of commercial projects over multiple decades) but they couldn’t help you because you’ve posted in a special locked forum.
In my personal experience over the past 18 months here, I haven’t found this to be true. Whenever I’m looking for a specific piece of information and search via google or these forums, the only times I’ve found viable and working solutions, it was from the Juce developers themselves.
Maybe I don’t have the same problems most other users have?
Do you realize that you’re not going to make friends on a largely community-driven forum by saying how the community, which is there to help others in their free time, doesn’t know shit?
Speaking of the community, please keep this conversation civil and refrain from antagonising one another! Having moderated this forum for a few years I’ve gotten a sense of when a topic might get derailed…
Even though this forum feels very welcoming, particularly in comparison to other equivalent ones, we regularly get feedback from people that they’re hesitant to post because they fear being belittled or otherwise embarrassed.
I have learned an enormous amount about JUCE, and programming best practices, by following the forum discussions as often as possible. Even when the discussion is not directly relevant to something I am working on, I find that I often learn something useful. And I would be willing to bet there are many here that will say the same!
And…that is how we become pro…by learning.
Thank you to all the JUCE devs for actively participating in this forum, and providing accurate information, and responding to requests rapidly. And thank you to forum members who generously provide help, often within minutes of asking a question.
I look forward each day to checking the forum…to see what I can learn!
Did you get into plugin and application development to do things the easy way or not? You are coming across as really entitled here and everyone should bow down because you or your team made nexus2. All of us are/were producers/musicians/engineers before we started dabbling in code, so don’t forget that we are or were probably a customer of yours. You’re not doing yourself any favors coming across in this thread in terms of “customer relations”…
