Can't create objects in the vst running in BitwigStudio on Linux..

[ensonic]

Can't create objects in the vst running in BitwigStudio on Linux..

[timothyschoen]

I can't reproduce this in Bitwig or Reaper on Ubuntu 20.04, or on Bitwig on Mac. Does creating new objects with shortcuts work? ("n" for empty object, make sure canvas has keyboard focus)

[ensonic]

'n' works! Is there is a list of shortcuts?

[timothyschoen]

n = empty
b = bang
t = toggle
m = message
s = vertical slider
i = number box
f = floatatom
c = comment

These are Max/MSP like instead of Pd-like because I find them much easier to memorise, but not every object has a shortcut right now. You can also create any GUI object by just typing its name, like "msg", "tgl", "bng", "hsl", "cnv".

The fact that it works like this and not when clicked from the callout menu suggests that there is somehow no event triggered when the callout menu closes, I'll see if I can find something.

[timothyschoen]

@ensonic I think this was a bug in JUCE, I've updated JUCE to the latest version so it might be fixed now

[ensonic]

Thanks, I've updated my checkout and rebuild everything, but it does not help. You might have also introduced a bug. When I save a patch, it break it (there is some garbage appended to the pure data file).

[timothyschoen]

Oh no, I'll try that out, thanks for reporting. Unfortunate that the JUCE update doesn't help. Did you update the submodules? I've changed the submodule structure quite a lot so I'd recommend cloning it from scratch.

The new version does add a comment to the pd file, to store extra information to the patch. I've also seen that it sometimes adds a newline at the end of a patch...

Does it completely break, or does it just show an error in the console?

edit: Found and solved the problem, by calling pd's save functions directly instead of getting the canvas content and saving that manually.

[timothyschoen]

@ensonic I wonder if this is still happening?

[ensonic]

I did not rebuild recently and I am using my distros package (0.3.2+git.13.b8ab75a-7.11). With that one the problem still exists.

[timothyschoen]

Very likely that it's still an issue then... Problem is, it works fine on all my linux installations, making it very hard to solve.

[ensonic]

I'll rebuild from git. Can you point me to the code for the menu an for the keyboard handling. I can add some log statements to figure what's different from the event to the object creation.

[timothyschoen]

Thanks, that might help!

It happens here:

https://github.com/timothyschoen/PlugData/blob/main/Source/Dialogs/Dialogs.cpp

in "Dialogs::showObjectMenu", the last line spawns the menu. You could place a log statement in the callback function it passes in, I'm curious if that gets called. And if it does, what is the "result" value it passes in?

Then you could add a second log statement here:

https://github.com/timothyschoen/PlugData/blob/main/Source/PluginEditor.cpp

in function "perform", case "CommandIDs::NewObject"

I assume that it never gets to that point, but it'd be nice to confirm that.

[ensonic]

Done. This is my patch for reference:

diff --git a/Source/Dialogs/Dialogs.cpp b/Source/Dialogs/Dialogs.cpp
index 174dd20..349e3a8 100644
--- a/Source/Dialogs/Dialogs.cpp
+++ b/Source/Dialogs/Dialogs.cpp
@@ -110,11 +110,15 @@ void Dialogs::showObjectMenu(PlugDataPluginEditor* parent, Component* target)
     menu.showMenuAsync(PopupMenu::Options().withMinimumWidth(100).withMaximumNumColumns(1).withTargetComponent(target).withParentComponent(parent),
                        [parent](int result)
                        {
+                           parent->pd.logMessage(String(__FILE__) + ":" + String(__LINE__) + ":" + String(__FUNCTION__) + ":  popup result=" + String(result));
+
                            if (result != 0)
                            {
                                if (auto* cnv = parent->getCurrentCanvas())
                                {
                                    cnv->attachNextObjectToMouse = true;
+                               } else {
+                                   parent->pd.logMessage(String(__FILE__) + ":" + String(__LINE__) + ":" + String(__FUNCTION__) + ": Can't get canvas");
                                }
                            }
                        });
diff --git a/Source/PluginEditor.cpp b/Source/PluginEditor.cpp
index 9f707db..b29e0ad 100644
--- a/Source/PluginEditor.cpp
+++ b/Source/PluginEditor.cpp
@@ -781,6 +781,8 @@ void PlugDataPluginEditor::getCommandInfo(const CommandID commandID, Application
 
         case CommandIDs::NewObject:
         {
+            pd.logMessage(String(__FILE__) + ":" + String(__LINE__) + ":" + String(__FUNCTION__) + ":  CommandIDs::NewObject");
+        
             result.setInfo("New Object", "Create new object", "Objects", 0);
             result.addDefaultKeypress(78, ModifierKeys::noModifiers);
             result.setActive(pd.locked == var(false));
@@ -795,6 +797,8 @@ void PlugDataPluginEditor::getCommandInfo(const CommandID commandID, Application
         }
         case CommandIDs::NewBang:
         {
+            pd.logMessage(String(__FILE__) + ":" + String(__LINE__) + ":" + String(__FUNCTION__) + ":  CommandIDs::NewBang");
+
             result.setInfo("New Bang", "Create new bang", "Objects", 0);
             result.addDefaultKeypress(66, ModifierKeys::noModifiers);
             result.setActive(pd.locked == var(false));

When I open the menu, by left or right clicking the +, I see invocations for

• Source/PluginEditor.cpp:781
• Source/PluginEditor.cpp:800
• (and probably all the other rmenu items)

followed by Source/Dialogs/Dialogs.cpp:113 with a popup result of=0 after I left or right clocked the menu item.

I also added some logging to createCommandItem() in Dialogs.cpp and there I get non-zero itemIDs. So I am not sure where the menu item id is lost.

FYI: https://github.com/timothyschoen/PlugData/blob/main/Source/Dialogs/Dialogs.cpp#L72 looks fishy, the if and else branch are the same.

[timothyschoen]

Thanks Stefan!

Nice catch about the if-statement btw, it's a bit of modified JUCE code, I think I changed the thing that made the branches unique at first ;)

createCommandItem is not actually performing the action, it only registers the action and updates the state of the action.
I'd be interesting to see if "pd.locked == var(false)" returns true here, if it doesn't that's obviously a problem.

In function "perform", Source/PluginEditor.cpp:903, the action will get performed. I wonder if you get a log message there, but I assume not.

The fact that it returns 0 in the callback is telling though: almost like clicking the popupmenu makes it lose focus instead of triggering it.

[ensonic]

I added a

        if (parent->pd.locked == var(false))
        {
          parent->pd.logMessage(String(__FILE__) + ":" + String(__LINE__) + ":" + String(__FUNCTION__) + ": not locked?");
        }

to createCommandItem() in Dialogs.cpp and no warning shows up, which I take as a good sign. I have been searching the net a bit, but can't find anything obvious why result would always be 0. I think your hunch could be right that for some reasons the focus has been lost and juce believes I clicked outside of the menu.

Any idea how we can verify this?

[timothyschoen]

But the the right-click menu on canvas does work right? Odd, because it's the same thing. I could try to make all these menus non-modal, that might help.

What distro are you on btw? I'll install it in a VM to see if I can reproduce it like that.

[ensonic]

Good point, just tested. I created an object using 'n' key and then used the context menu to try to copy and paste and this does not work either (ctrl-c, ctrl-v works though).

I am using opensuse tumbleweed (https://get.opensuse.org/tumbleweed/) using the default gnome desktop (on wayland). I just tried under X11 and there it works, so it looks like there is a JUCE incompatibility with wayland :/

[timothyschoen]

Thanks for figuring that out, looks like I won't be able to fix this :(