Site navigation

Vst wrapper for linux

Audio Plugins
#1

jules, i’ve sent you the modified files for making the vst wrapper available for linux. if you remember i was driving a background thread to dispatch message manager messages to components:

EditorCompWrapper:

    void run ()
    {
        int maxNumberOfMessagesToDispatch;

        while (! threadShouldExit())
        {
            maxNumberOfMessagesToDispatch = 10000;

            while (--maxNumberOfMessagesToDispatch >= 0)
            {
                bool carryOn = false;
                JUCE_TRY
                {
                    carryOn = juce_dispatchNextMessageOnSystemQueue (true);
                }
                JUCE_CATCH_EXCEPTION

                if (! carryOn)
                    break;
            }

            Thread::sleep (10);
        }
    }

actually i’m a bit stumped cause everything works except things like popup-menus and combo-boxes (which open up modal components,
typically added to the desktop): when i try to open a popup menu or click on a combobox everything freeze, both my plugin and the host…

i’ve looked at Component::runModalLoop() to see what is going on here,
and i see that there are some lines that filter out things when we are not in the message thread…

    if (! MessageManager::getInstance()->isThisTheMessageThread())
    {
        // use a callback so this can be called from non-gui threads
        return (int) (pointer_sized_int)
                    MessageManager::getInstance()
                       ->callFunctionOnMessageThread (&runModalLoopCallback, (void*) this);
    }

where do you think i have to stick to make things work ?

#2

Hmm. You’d need to tell the message manager which thread is doing the dispatch loop. That means setting the MessageManager::messageThreadId value, which is private at the moment. I’d suggest adding a method like MessageManager::thisIsTheMessageThread() to set it to the caller thread, and you could call that at the start of your thread.

#3

ok the problem is related to the addToDesktop and the message thread dispatch with modal components, actually when i add to dsktop a modal component, the message thread blocks. i’ve tried modifying the ComboBox code, that instead of opening the popup on the Desktop, it add to the owner.getComponentParent(). now that works smoothly.

could be a good thing to have an option that selects if popups components should be added to the desktop or the parent component (popups, comboboxes, alertwindows) ? would be ideal in the case you cannot rely on the desktop and must use the main parent component.
something like mdi (that is adding windows to an internal component instead that on the desktop), but available globally… what do you think ?

#4

oops… you replied too fast :wink:

#5

i’ve followed your dogma… but then it is failing assert when reaching

mmmh…

#6

now it’s working !

this is the external message thread processing that is working:

    void run ()
    {
        MessageManager* messageManager = MessageManager::getInstance();

        int oldThreadId = messageManager->getCurrentMessageThreadId();

        messageManager->setCurrentMessageThreadId (Thread::getCurrentThreadId());

        int maxNumberOfMessagesToDispatch;

        while (! threadShouldExit())
        {
            maxNumberOfMessagesToDispatch = 10000;

            while (--maxNumberOfMessagesToDispatch >= 0)
            {
                bool carryOn = false;
                JUCE_TRY
                {
                    carryOn = juce_dispatchNextMessageOnSystemQueue (true);
                }
                JUCE_CATCH_EXCEPTION

                if (! carryOn)
                    break;
            }

            Thread::sleep (10);
        }

        messageManager->setCurrentMessageThreadId (oldThreadId);
    }

if i don’t reset back the old message thread before returning… then the plugin window got stuck !
why this ? no more message manager functions are called after that run method…

i really would like to understand more on message managers and multiple thread calling for messages being dispatched correctly (i’m a bit stunned about it) !

#7