UI bugs and problems in 0.4.3

[ludnny]

Hi!

A few bugs and UI problems found in the 4.0.3 win64 Standalone version.

• When opening a patch in Pure data previously saved in PlugData, all the subatches are automatically opened (visible), and show a comment "plugdatainfo" I guess this is to remember the patch parameters, like background colors. Is it possible to hide that better? Or to put it in an additionnal external file, not interfering with the original file? It would be nice to have a totally transparent exchange between the two programs.

• It converts automatically Vradio and Hradio to 9 cells buttons, whatever the number of cells of the original patch in PureData

• some properties (e.g. colors) are not implemented:

• The Toggle buttons are very confusing! Why not using the standard "not-checked" when off?

• Object boxes and message boxes are too similar. (symbol boxes are ok) Maybe using the same shape as in PureData?

• It would be amazing to have the zoom focusing on the mouse position, not on the position top-left of the patch, especially with the middle mouse scrolling zoom.

• There is a delay in number box results displaying. When changing a value manually, the display is real-time, but the others number boxes in the chain are a bit delayed by a few ms (can be annoying for music)

• Some Vsliders don't work very well. To reproduce, try opening percussion.pd in Automatonism. In Lock mode, try to move the slider P-DECAY. In comparaison, the slider DECAY1 works well. I guess this is an issue when multiple objects overlap slightly, but unfortunately that can happens very often when importing patches from PureData.

Thank you again for your amazing work, it's very impressive! The interface in general is super convenient, fluid... I especially like the difference of colors between audio and data inputs.

[ludnny]

Another one:

• Missing "Canvas Properties" for subpatches and abstractions

[timothyschoen]

Thanks for reporting!

The comment that's automatically added is unfortunately needed mostly to store the connection paths if you modify them. I agree it's not a perfect system, but I couldn't think of any better way to save extra info. The worse news is that, if I want to have correct undo behaviour on those connections, I'll need to add another comment for that... So if anyone has a suggestion on how to handle this, let me know! I tried to create a special object and store it in the state of that object, but unfortunately pd removes all state info when it doesn't recognize the object. I guess the good news is, you can put the comment anywhere you like.

Colour setting, wrong number of hradio options and the message box design are some nice catches, I'll take care of those very soon. The numbox delay and differing quality with slider are also something I'll investigate, that definitely shouldn't happen.

I actually copied the toggle design from Max and Kiwi:

I could make the X less highlighted to show clearly it's not currently toggled on? But I think (for new users) that a non-highlighted X invites clicking more so than an empty box does.

I'll check out those canvas settings as well, but I have to admit that I've never used those, so first I'll investigate what they actually do ;)

Again thanks for testing, it helps a lot to make the experience smoother!

[ludnny]

The comment that's automatically added is unfortunately needed mostly to store the connection paths if you modify them. I agree it's not a perfect system, but I couldn't think of any better way to save extra info. The worse news is that, if I want to have correct undo behaviour on those connections, I'll need to add another comment for that... So if anyone has a suggestion on how to handle this, let me know! I tried to create a special object and store it in the state of that object, but unfortunately pd removes all state info when it doesn't recognize the object. I guess the good news is, you can put the comment anywhere you like.

I tried to find some ideas in the PdFileFormat specs, but this file format has a lot of limitations :( There is no way to hide an object (with scale 0, alpha 0...) or to add a comment in the text version of the file itself (I tried with /... /, //...) Everything that is not starting with #N or #X will make PD crash.

I'll let you know if I find a clean way to store extra info!

[ludnny]

I'll let you know if I find a clean way to store extra info!

I may have find a cleaner approach. Using a "text define -k" object allows you to store the equivalent of a text file in the pd file.

https://www.dropbox.com/s/pdsmq5es898xhgg/plugdatainfo.pd?dl=1

It's less annoying visually (the content is hidden to the user), and it allows for multiple comments in the same object using semicolon.

The problem with this approach is that you will have conflicts of names when multiple subpatches use the same name argument for the text define objects (e.g. if every subpatch uses the name "text define -k plugdatainfo"). You will have to assign different names for different subpatches. A better approach would be to use only one "text define" for all the subpatches.

Still not the perfect solution, as it add an unwanted object in the patch. I tried to "hide it" putting it at negative coordinates (-194 0), but it's not the best.

[ludnny]

I actually copied the toggle design from Max and Kiwi:

I could make the X less highlighted to show clearly it's not currently toggled on? But I think (for new users) that a non-highlighted X invites clicking more so than an empty box does.

I understand the point for new users, but in that case it should be almost transparent, so there is absolutely no confusion between the two.

[timothyschoen]

That's a pretty nice solution! I'm also considering creating a 1x1 GraphOnParent, which is basically a dot in pd. Then I can store whatever I want in there, only problem here is that I'll have to figure out how to make the undoable actions work relative to the parent canvas instead of the graph canvas.

And I'll make the untoggled state a bit darker for sure!

[timothyschoen]

This system works, but I'll have to test it a lot more because it's a bit complicated. No undo yet, but at least the comment is completely invisible in pd:

#N canvas 827 239 527 327 12;
#N canvas 0 22 450 278 (subpatch) 0;
#X text 0 0 plugdatainfo PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCg0KPFBsdWdEYXRhSW5mbz4NCiAgPENvbm5lY3Rpb24gSUQ9IkJhY2tncm91bmRDb2xvdXIiIEluZm89IjkubFlsTHZIQ0x4LkMuIi8+DQogIDxDb25uZWN0aW9uIElEPSJjMTAwMCIgSW5mbz0iMzMueGZTTXBEU016dmhMM1RpSnpEaUxyVENNMG5CTXdIQ0swUFNNcEhDTnd2Qi4iLz4NCjwvUGx1Z0RhdGFJbmZvPg0K
;
#X coords 0 1 100 -1 1 1 1 0 0;
#X restore 0 0 graph;

[timothyschoen]

Working undo actions on connection paths 😎

Basically it adds a dummy undo message to pd whenever the connection path changes. When the user clicks undo/redo and it sees the dummy event, it will trigger an undo/redo on a JUCE UndoManager attached to a valueTree containing the connection paths.

Hiding it in a GOP works great too, the only small problem is that you can easily accidentally delete it because you can hardly see it.

[FlachyJoe]

Hi, I don't understand why undo/redo info have to survive document close, it's not a standard implementation of such feature.

[timothyschoen]

That's not what this does, the reason I wanted to use a comment for undo/redo initially is so I could use pd's undo system to revert changes to that comment, and in that way get undo/redo behaviour. Then there'd be a second comment (with no undo/redo) that is an 'index' so there entries can be linked to a connection even when the indexing changes.

I decided to do it a different way now, which is imo much nicer and doesn't fill the patch with junk so much.

[ludnny]

I'm also considering creating a 1x1 GraphOnParent, which is basically a dot in pd.

1x1 pixel, it sounds like the best way to hide that!

[timothyschoen]

Yeah it works pretty well, but I'm also considering to size it so only the works plugdatainfo is visible, to prevent accidental deletion. Still not sure what is better...

Also, strange that zooming goes to the top-left, I remember implementing this correctly once... But now it doesn't work!

[60-hz]

Yeah it works pretty well, but I'm also considering to size it so only the works plugdatainfo is visible, to prevent accidental deletion. Still not sure what is better...

Wouldn't it be preferable to have an external "name.pdsettings" file next to the "name.pd" patch for that?

[timothyschoen]

That's something I've considered, the reasons I did it this way are the following:

• Now that I can hide it pretty well, it doesn't really get in the way in pd-vanilla.
• Implementation wise, putting everything in a single file is very convenient, especially for things like storing the state to the DAW
• If people want to share patches (with connection paths or background colours), they'll need to remember to share two files, which will also confuse pd-vanilla users.
• If you (accidentally) move or rename one of the files, PlugData won't be able to find it.
• It will fill up your patches folder. I don't know if this is true for everyone, but I usually have a pretty big folder with patches, and another big folder with abstractions. Having twice as many files in those folders is not helpful.

There is still one problem now though: the existence of an invisible object offsets connection cord indices by 1, which is not good when you want to do things like create connections dynamically with [connect 1 2 1 1]. Dynamic patching isn't supported right now anyways (PlugData updates its state based on user interaction, but this might change in the future), so for now the current solution will suffice. I might switch over to using two files, or preferably, a different way of storing text into a pd patch that will not mess with indices if I'm able to find a way...

[ludnny]

• When opening a patch in Pure data previously saved in PlugData, all the subatches are automatically opened (visible), and show a comment "plugdatainfo" It would be nice to have a totally transparent exchange between the two programs.

It's better in 0.5, but it still automatically opens all the subpatches when opening a patch back in PureData. Not very convenient to have to manually close dozens of subpatches to see the main patch!

• It converts automatically Vradio and Hradio to 9 cells buttons, whatever the number of cells of the original patch in PureData

Works perfectly in 0.5!

• The Toggle buttons are very confusing!

It's better in 0.5 :)

• Object boxes and message boxes are too similar. (symbol boxes are ok)

No confusion anymore in 0.5!

• It would be amazing to have the zoom focusing on the mouse position, not on the position top-left of the patch, especially with the middle mouse scrolling zoom.

Works perfectly in 0.5. But the pan (long middleclick + scroll) works only in Edit mode, not in Lock mode. (in Win64 standalone)

• There is a delay in number box results displaying.

This one is still here in 0.5

• Some Vsliders don't work very well. I guess this is an issue when multiple objects overlap slightly, but unfortunately that can happens very often when importing patches from PureData.

Still here in 0.5

Thank you very much for this new release!

[timothyschoen]

Thanks for the update on these issues!

I think most of these will be fixed by the next release. I'm working on a smaller version (0.5.1) right now, where I'm planing to fix many issues like these, fix issues with ELSE integration, add support for multiple opened projects and add a documentation browser.

[timothyschoen]

The overlapping objects issue is fixed, the number box delay not yet. New release coming up soon, improving the responsiveness of numboxes and other gui elements is planned for next release. I also wanna improve the "number dragging" generally.

Canvas properties are also planned for 0.6, but not yet for v0.5.1

[timothyschoen]

I think I also fixed the delay for number box?

[ludnny]

I think I also fixed the delay for number box?

It looks better in PlugData v0.5.2 Win64, but still some delays compared to Vanilla

[ludnny]

• Some Vsliders don't work very well. To reproduce, try opening percussion.pd in Automatonism. In Lock mode, try to move the slider P-DECAY. In comparaison, the slider DECAY1 works well. I guess this is an issue when multiple objects overlap slightly, but unfortunately that can happens very often when importing patches from PureData.

Works perfectly in PlugData v0.5.2 Win64, thanks! Even in very small size (zoom 50%)

[timothyschoen]

I think I also fixed the delay for number box?

It looks better in PlugData v0.5.2 Win64, but still some delays compared to Vanilla

I see what you mean now, it's not nearly as bad on my Mac. It doesn't look like it has latency, and more like it's causing a lot more processor load than it should. Do you mind sharing your PC's specs? That might help me determine if it's Windows related or not.

[timothyschoen]

• Some Vsliders don't work very well. To reproduce, try opening percussion.pd in Automatonism. In Lock mode, try to move the slider P-DECAY. In comparaison, the slider DECAY1 works well. I guess this is an issue when multiple objects overlap slightly, but unfortunately that can happens very often when importing patches from PureData.

Works perfectly in PlugData v0.5.2 Win64, thanks! Even in very small size (zoom 50%)

Great!! The hitboxes for objects were previously bigger than the object itself, causing them to block adjacent objects... If you hadn't reported it, I would've taken me a while to find out!

[ludnny]

Do you mind sharing your PC's specs? That might help me determine if it's Windows related or not.

Laptop Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz 2.20 GHz RAM 32.0 GB NVIDIA GeForce RTX 2080 with Max-Q Design Windows10 64bits

[timothyschoen]

Oh that should be able to handle such a load with ease, so it's definitely something suboptimal in PlugData, possibly exclusive to Windows as well. This is on my M1 MacBook:

[timothyschoen]

How does the performance of sliders compare btw?

[ludnny]

How does the performance of sliders compare btw?

A bit of delay as well with sliders The GIF is not showing it perfectly, but you have some little pauses, like stop-motion animation (like a low framerate, like 8fps rather than the expected 60fps)

[timothyschoen]

I found that color properties are already somewhat working, but the parameters in the panel don't update yet. Should be fully implemented soon!

[timothyschoen]

Setting properties with messages works now, settings main canvas properties should also work.