Numeric input problem in vst demo Ableton 6.0.10 win

Hi All,

I’ve just compiled the relese juce_vst demo plugin using vs8 on win, juce 1.45, and it loads and runs just fine. I single click the number box and the text of the number is selected in full ready for keyboard input, but no keys work. I have checked the flag:

#define JucePlugin_EditorRequiresKeyboardFocus 1

which seems to me that keyboard input should be active. Is there something I’m missing?

The are a couple of other small issues as well:

  • in ableton the dsp cpu measure increases by 1% when the gui is open and nothing is happening, not even a mouse over over the gui, perhaps a priority inversion due to locking out the dsp thread by the gui?

  • while the mouse is still down during resizing the window quickly to the left and right a note on the keyboard gets turned yellow, which is what happens when the mouse is over it, but the resize control still has focus. Is this normal?

I look forward to using Juce in future products, it’s a fantastic collection of classes. Well done Jules!

Thanks,

aspy

Thanks. Ableton is well-known for being dodgy when it comes to keystrokes - I think if you do a search on this forum you’ll find some other threads about this subject…

Sorry, I just noticed that I didn’t finish reading all your questions…

In the demo plugin it does a very inefficient job of constantly sending lots of timecode info to the GUI, which locks a critical section. I guess the cpu is just the extra time taken to do this, rather than anything sinister.

Not sure about the mouse thing, I’ll have to investigate that - is this on mac or PC?

Hi Jules,

The mouse thing is win, as are all of the other things. You push the button down and hold it down on the resize icon, then drag quickly from left to right so that the resize of the window trails the mouse being over the keyboard. I am not really worried about this in practical use, but thought you might be interested in knowing it happens.

I did notice in the demo project that you lock the dsp thread, which can cause a priority inversion and chew dsp cpu. I am considering writing some lockfree algorithms to overcome this sort of thing. Are there any lockfree classes in Juce? Would you be interested in me contributing to Juce if there aren’t any?

aspy

(Ah - I just noticed your email address! Welcome!)

Yes, the demo’s just blasting away with a mutex, and I’ve not got any lock-free classes so yes, it’d be appreciated if you want to contribute some. There are some atomic inc/dec operators and stuff, but I’ve never got round to doing a lock-free fifo.

I took a look at the mouse-drag thing, as that did sound a bit odd, but it’s just down to the way the keyboard comp works - it needed a tiny tweak, which I’ve checked-in now. But nothing serious.

I checked out the atomic inc and dec, all looks good there so I’ll be able to extend that section of code in the same way to add atomic compare and exchange for windows, which is all that is needed for a simple templated fifo. I’ll have to leave it to you to write the mac and linux parts since I don’t have those resources, but the fifo should work just fine once the os wrapping up of the compare and exchange is done.

Thanks for the fix to the keyboard component, I have updated from the trunk (do you call it tip?) and confirmed all is working here, not a spurious highlight to be seen.

I still need to read up a bit more about the keyboard input issue, but I have a quick question. Hopefully I will get away with popping up a tiny juce window on the edit position and allowing text input to that before returning focus to the app.

aspy

yes - popping up a temporary window for a text editor is exactly the workaround that someone else was using for this issue.