Click for focus


#1

A friend who is helping me beta test Peggy 2000: Total Peggination is reporting that in Cubase SX, the instrument window does not pop to the front when you click it like other VST instruments.

Anyone know what that is about?

(Side note: Cubase SX is by far the trickiest host to please. After I got the plug working fine in every host known to man except Cubase, there was still 3 hrs of cubase specific cludgeing to be done.)


#2

Another cubase related question:
When running two instances of the plug it crackles initially. I see two potential reasons:

The only part that is static or global in the plug is the raw waveforms created by binarybuilder. They get read into a table when a waveform is selected. Should the reading mechanism be put into a critical section?

The second reason could be that the buffer size is not the one passed to the prepareToPlay() call. Can that block size be trusted, or can it change?


#3

[quote=“Rock Hardbuns”]Another cubase related question:
When running two instances of the plug it crackles initially. I see two potential reasons:
The only part that is static or global in the plug is the raw waveforms created by binarybuilder. They get read into a table when a waveform is selected. Should the reading mechanism be put into a critical section?[/quote]

no it doesn’t need locking when accessing that global table, abviously if you are recreating the shared waveform even when the second instance come up, and the first instance is playing, maybe the crackles are there because you are reading when you are writing. just write the first time when it’s empty and avoid rewriting it a second time.

[quote=“Rock Hardbuns”]
The second reason could be that the buffer size is not the one passed to the prepareToPlay() call. Can that block size be trusted, or can it change?[/quote]
in vst, you should rely on the size of the input/output buffers in the process function, not the buffersize that get passed to prepareToPlay: in fact the host could change that if it needs to.


#4

[quote=“kraken”]
in vst, you should rely on the size of the input/output buffers in the process function, not the buffersize that get passed to prepareToPlay: in fact the host could change that if it needs to.[/quote]

That might be it then. I allocate a temporary buffer in preparetoplay, which is copied to the output when it’s done. Does it ever become larger? Now that I think about it I seem to recall it can only shrink relative to what you’re given in preparetoplay?

Any thoughts on the focus thing?


#5

Yes, the buffer can become larger or smaller, and may be different every time the callback happens. Basically the prepareToPlay value is nothing more than a hint about the typical size to expect.

(I thought I’d explained this in the juce audio plugin docs, but it seems I hadn’t - I’ll add some more better comments about it for the next version)


#6

Hmpf, that’s disturbing. I guess I have to do something like this:

 if (output.getNumSamples() != MyBuffer->getNumSamples()){
      MyBuffer->setSize(2, output.getNumSamples(),false,false,true);
 }

Might be heavy though.

So what about the click for focus thing. Would the “editorRequiresKeyboardFocus” parameter influence this in any way?


#7

Yes, sorry, meant to answer that one. It does try to pop the window to the front, as you can see in juce_VSTWrapper.cpp, line 205ish. You might need to turn on the editorRequiresKeyboardFocus setting for that to work, though, I guess. I’m doing some plugin work at the moment, and will take a look.


#8

Ok, give this a whirl and see if it helps (I’ve not got cubase here to try it myself)…

[code]class EditorCompWrapper : public Component,
public AsyncUpdater
{
JuceVSTWrapper* wrapper;

public:
EditorCompWrapper (JuceVSTWrapper* const wrapper_)
: wrapper (wrapper_)
{
setOpaque (true);
}

~EditorCompWrapper()
{
    deleteAllChildren();
}

void paint (Graphics& g)
{
}

void paintOverChildren (Graphics& g)
{
    // this causes an async call to masterIdle() to help
    // creaky old DAWs like Nuendo repaint themselves while we're
    // repainting. Otherwise they just seem to give up and sit there
    // waiting.
    triggerAsyncUpdate();
}

AudioFilterEditor* getEditorComp() const
{
    return dynamic_cast <AudioFilterEditor*> (getChildComponent (0));
}

void resized()
{
    Component* const c = getChildComponent (0);
    
    if (c != 0)
    {
        c->setBounds (0, 0, getWidth(), getHeight());

#ifdef JUCE_WIN32
c->addMouseListener (this, true);
#endif
}
}

void childBoundsChanged (Component* child);
void handleAsyncUpdate();

#ifdef JUCE_WIN32
void mouseDown (const MouseEvent&)
{
broughtToFront();
}

void broughtToFront()
{
    // for hosts like nuendo, need to also pop the MDI container to the
    // front when our comp is clicked on.
    HWND parent = findMDIParentOf ((HWND) getWindowHandle());

    if (parent != 0)
    {
        SetWindowPos (parent, 
                      HWND_TOP, 
                      0, 0, 0, 0,
                      SWP_NOMOVE | SWP_NOSIZE);
    }
}

#endif

//==============================================================================
juce_UseDebuggingNewOperator

};
[/code]


#9

Oh, that was fast. I dont have cubase either. But I’ll make a build and call my buddy, to see if he’s up for some beta testing.


#10

Well, buddy is home and don’t mind testing… the change did nothing though. He also reports that Roid (my first sorry excuse of a synth) does move to the front as one would expect, so it’s either something I’ve done differently or something you’ve changed since then.

I’m going to put an alert box in that method to see if we actually get a handle on that parent at all.


#11

Clicking the gui does not fire the alert box, which indicates mouseDown doesn’t get called at all.

Cubase apparently has a button for bringing a VST to the front, and that works, and the alertbox presents a nice important-looking number.

 void broughtToFront()
    {
        // for hosts like nuendo, need to also pop the MDI container to the
        // front when our comp is clicked on.
        HWND parent = findMDIParentOf ((HWND) getWindowHandle());

        AlertWindow::showMessageBox(AlertWindow::NoIcon, T("Whopeee"), String((int)parent));
        
        if (parent != 0)
        {
            SetWindowPos (parent,
                          HWND_TOP,
                          0, 0, 0, 0,
                          SWP_NOMOVE | SWP_NOSIZE);
        }
    }

#12

Oh, I think I might have messed that up a bit. Try moving the addMouseListener into the constructor, like this:

[code] EditorCompWrapper (JuceVSTWrapper* const wrapper_)
: wrapper (wrapper_)
{
setOpaque (true);

#ifdef JUCE_WIN32
addMouseListener (this, true);
#endif
}
[/code]

And remove it from the resized() method. The code I’ve got here is actually not quite the same, as I’ve been hacking it around a bit.


#13

Bingo. Thanks for the help.

In retrospect, it seems quite obvious, doesn’t it. :smiley: I should have spotted it myself even.


#14

maybe that explains the mousewheel thing too?


#15

…it’s possible, I guess - have you tried it?


#16

just did, and no! :slight_smile: but then i’ve not done a whole fresh test to check that it’s not a problem with my code yet :oops:


#17