Standalone v0.3/v0.3.1 bug report

[60-hz]

Here is some report with v0.3 (tested under OSX)

(edited by @timothyschoen)

• [x] Array should have default name "array1". If create an array without filling a name, click on it = app crash
• [x] - canvas gui object "foreground" is useless. But width / height fields would be convinient.
• [x] - Label and their color/position/font are missing in every GUI (I understand they would conflict with the "object name" displayed on mouseover, but this design needs some thought)
• [x] - when an object is below another one but is connected from above, the segmented path is confusing and repositionning the horizontal segment with mouse is reversed.
• [x] - last bottom line of print is not visible, might be under the bottom bar?
• [x] - zoom with Action + mousewheel would be nice
• [ ] - single click (or double clic) on object name should create object and close the completion menu (now only fill empty object name, then need extra clic outside to create) (note: currently not a priority because Max does the same. I do like the behaviour you suggested, so maybe next release -TS)
• [ ] - "Create object" menu add object in the middle of canvas... could be under last mouse position and already selected to save the extra effort to search for it and select it. (note: currently not a priority because Max does the same -TS) -> The best behavior should be like puredata then: the object "stick" (follow) to mouse position until you click somewhere to validate the final object position in the patch. This way is more natural and handy. Also adding object using shortcut might have the same behavior.
• [x] - resizing graph on parent is nice, works only on width and is reseted to default during a GUI interaction. (note: disabled resizing while it doesn't work - TS)
• [x] - keyboard ui object keys does not extend when resizing
• [x] - the highlighted inlets/outlets are almost invisible, might be white color and maybe bigger size / zone like in PurrData which is very confortable (this is the key in a data flow environment ;) ).

[timothyschoen]

Thanks! These reports have been super helpful!

• Oh I overlooked that, I'll fix it immediately

• Noted, I'll remove the property, I was planning to add height/width properties to more components because it's nice to have anyways

• I implemented labels pretty shortly before the release (just to make pd patches look nice), I haven't gotten to making them modifiable yet. Should be coming soon! I'm still considering whether the mouse-over idea is really the best way. I could ditch the idea and add an "Edit" option on right-click so you can still change the type of every object if you want to. I like the mouse-over, but I also realise that it's inconvenient in certain cases, and on top of that most people aren't used to it.

• I think that this should be better if I make it so it always starts with a small vertical segment? There are still some limitations to this system, like how you can't move the segment outside of the rectangle from inlet to outlet.

• Oops that message is under the bottom bar, I'll fix it

• I noticed this, but I saw that Max/MSP handles it the same way. Locking the patch solves it

• Good idea, I'll also check if I can add a pinch-zoom for trackpads and touchscreens!

• I'm not sure what you mean with "label like click selection"

• The reason for this is that you might want to type arguments after the object name, this behaviour is also identical to Max/MSP

• I used to have it at last mouse-position, and I found that was confusing because it always gets created close to the create object menu. Selecting new objects it is a great idea tho!

• I'm probably ditching the mouse-over concept anyways :)

• Figuring out the resizing of graphs was a struggle, I'll check it out to see what's going wrong.

• They should extend, and there should also be a keyboard range property

• I like this idea, I recently noticed myself that the hitboxes for inlets/outlets are still a bit small...

I'm going to create a v0.3.1 pretty soon just to fix all the issues the are already being found in v0.3.

[60-hz]

I'm not sure what you mean with "label like click selection"

It was about displaying label of all selected object when drawing a rectangle to select multiple object but it's not important since the mouse-over concept might be ditched as you said ;)

The reason for this is that you might want to type arguments after the object name, this behaviour is also identical to Max/MSP

Yes, that makes sense. But still a little remark to optimize the workflow: When user select an object name in the list, the box get filled with name and remaining letters are highlighted. So if user want to add arguments, hitting space key will replace the remaining objects letters with a space and object name will be cut in the middle. So user need to type Right arrow key (to place cursor after name), then space key, then argument. This scenario behavior could be shortened by placing the cursor at the end of object name after selection (hope it won't conflict with the object filling process...).

Example to create a "print test" object:

• type N to create new object
• type "pr"
• select print in the list -> the remaining "nt" get highlighted... the cursor should go to the end of object name at this step and maybe add a space so argument could be filled right away.
• If user don't need arguments, he simply hit enter or click outside (Note: pure data remove extra space after object name without argument, but not plug data.

I used to have it at last mouse-position, and I found that was confusing because it always gets created close to the create object menu. Selecting new objects it is a great idea tho!

Ok, I understand. The best behavior should be like puredata then: the object "stick" (follow) to mouse position until you click somewhere to validate the final object position in the patch. This way is more natural and handy. Also adding object using shortcut might have the same behavior.

[timothyschoen]

I've uploaded a new release that has regular pd/max locking behaviour, and fixes most (though not all) of your issues, and generally should be a lot more stable, I think you'll like it :)

Let me know if you find any new problems, there's so much you can do with pd that it's tough for me to test everything before each release. There's always some blind spots you have when testing thing you wrote yourself. This ticket can stay open because I haven't fixed everything yet.

[60-hz]

As usual, great work! The interface is getting smoother and smoother and that’s nice that you choose to duplicate the regular pd/max locking behavior. After some tests, here is my report (as usual I am focusing on interface interaction rather than on object testing to stabilize the base):

• lock / unlock mode: should be visually noticeable. Pd use minimalist default cursor look change from hand cursor to arrow for instance, max or purr data use a dashed background. Can be the horizontal top blue line turn to grey (I still think about the use of the blue horizontal line above cursor… blue color remind of a slider bars so simple grey or black would be more elegant?)

• Note: I understand now what top blue bar use is: highlight icons hovering. but it is a at least not noticable. The top icon should simply turn blue while hover like other icons are.

• holding temporary action key (temporary lock) should change lock icon and also change mouse cursor accordingly to reflect the temporary runmode to user.

• when dragging atom boxes in run mode: interface should automatically switch from property to print console because user might want to see the print panel.

• Text edition in object boxes when unlocking / locking is wrong: -> for message: text edition is possible in unlock (edit) mode: correct ;) -> for object: text edition is possible in lock (run) mode : wrong! -> for atom boxes: text edition is in lock (un) run mode : correct because it edition of a variable in runmode...

• text edition in object/comment boxes when unlocking (edit mode ) should be accessible with a simple click instead of a double click to be more understandable. Like pd behavior in unlock (edit mode): click+drag a box = move , a simple click inside boxes allow text entry.

• cursor should change on mouse over on any gui / messages objects in run mode (when lock) to notice users that there is a possible action (messages & gui but not objects…)

• turn to lock mode (run) then: drag float in atom box = disabled add icon (?)… (move box to re-enable)

• symbol atom box: should have same grey background color than float atom box, to remain noticeably different from black objet boxes. Could have default "symbol" name inside? (pd recently removed "default symbol" inside symbol box but I think it's a useful information, like float have a default "0" value)

• gui bang: missing hold time property

• all gui’s: Missing label, size, init and font properties

• array: cannot resize height with mouse.

• array: selection give an empty properties panel...

• array: mouse drag refresh create « gaps » when draw fast

• strange bug when editing comment after array creation: -> create an array -> create a comment -> rename comment -> array will move few pixel top left

• keyboard gui’s height cannot be resized and has annormal init size

• boxes and patchcoord's color highlighting when doing a selection is a bit difficult to notice, even on my MacBook screen (stronger color?)

• missing useful list box from 0.52

• comment text box entry should not propose completion of object's names

• hovering comment boxes in edit mode doesn't clear grey rectange (also shouldn't the selection color be blue ?)

[timothyschoen]

Thanks for the list! It's great that you focus on interface interaction, the base of PlugData just runs pd, so that means that as long as the interface behaves correctly, it should just do exactly what pd-vanilla does. And oh man, the keyboard looks whacked...

I agree with all your points as well, I find myself forgetting if I'm in run/edit mode all the time because the lack of visual feedback.

[timothyschoen]

@8ouble-r also reported some crucial problems, I think I'll create a quick release today just fixing those issues, the keyboard size and the array position bug. I'll take care of the rest in the release after that, but I feel like just these changes make the experience much better.

[60-hz]

Ok, I am updating my comment a little bit sometimes to be more clear as english is not my mother language.

[timothyschoen]

Thanks! And you English is fine, don't worry!

The blue bar is kinda useless and more there for aesthetics. I know someone who does GUI design for audio apps, and also has experience with Max/Pd so I was planning to ask him to do a nicer design pretty soon.

[timothyschoen]

I wonder about your opinion on the default bang interrupt time, which is 250 ms in Pd. That feels very long to me, it means that you basically can't see 16th notes on a bng... Do you agree that we can change the default to something like 100 ms?

[60-hz]

I know someone who does GUI design for audio apps, and also has experience with Max/Pd so I was planning to ask him to do a nicer design pretty soon.

Thats nice. One simple word: if something has no specific signification, then get rid of it :) Minimalism is always nice. Rules is no bevel, no drop shadow, no gradient if possible of course :)

I wonder about your opinion on the default bang interrupt time, which is 250 ms in Pd. That feels very long to me, it means that you basically can't see 16th notes on a bng... Do you agree that we can change the default to something like 100 ms?

I totally agree with that, but do you mean hold time or interrupt? because hold time is at 250 by default and interrupt at 50... I usually change interrupt to 30 and hold at 100 (because I am working with frames with ofelia / gem often and I need to display about 25fps which is 40ms) during some workshops. If the GUI has no performances issues, then why not lower the default values.

[alfonso73]

hi all! thanks @timothyschoen for your ongoin' great work and thanks everybody helping. To keep things compact i'll make here some more report for 0.3.2

1. Can't type tilde or any other ASCII character accessible with ALT+(ASCII code on numpad). I'm on Windows with italian keyboard and that's the only one way AFAIK to type a tilde.
2. When i load multiple instances it takes four tries to actually instantiate any object (See attachments). Everything works fine with one PlugData instance only
3. When i load multiple instances after goin' through point 2. i have PlugData working but all audio of both instances goes out from the first instance only (See attachments)

[timothyschoen]

I believe the tilde problem is a problem with reaper. Make sure you select "FX->Send all keyboard input to plugin". This works for me but maybe it won't work for you, I don't have an Italian keyboard.

That other issue looks bad, I'm going to rewrite a part of the patch/instance code for the next version, I'll make sure to test this. Thanks for reporting!

[timothyschoen]

I can reproduce this problem, so it should be fixable

[alfonso73]

I can reproduce this problem, so it should be fixable

do you mean the tilde problem or the multi-instance ones?

[timothyschoen]

I can reproduce the multi-instance problem, ~ works fine for me, did you try it with the "send all keyboard to plugin"? If that doesn't work I'll try it with an Italian screen keyboard.

[alfonso73]

@timothyschoen yeah ~ works with "send all keyboard to plugin"

[timothyschoen]

@alfonso73 I think I've fixed these problems now, but I'm going to have to test this for a while to make sure everything works.

The problem is pretty complicated, pd has support for multiple instances, but it stores the current instance it in a global variable, which is shared between instances of PlugData. When two instances are running simultaneously, one instance can make itself the current instance while the other instance is busy with, for example, creating an object.

[alfonso73]

@timothyschoen that's great. Let's see how the tests go and tell me if i can help.

[timothyschoen]

PlugData-Win64-2.zip

Here's a windows version with the fixed multi-instance support, if you could try it and let me know if it works, it would help me a lot!

[alfonso73]

@timothyschoen object instantiation in multiple PlugData instances seems to work fine. But audio out of both PlugData instances still come out from first instance only. PS...would you think it's a good idea to open an "issue" or a discussion topic with future feature request for PlugData?

[alfonso73]

oh..and even if i toggle dsp off in the second instance, it still reamains on and its audio still come out from first instance

[timothyschoen]

I've opened an issue for feature requests!

I've never had the audio problem myself, so I was afraid that it wouldn't be fixed yet... It's a very strange bug, especially because Camomile doesn't have this problem AFAIK, and we use the same system for this.

[alfonso73]

Camomile doesn't suffer of the same thing. I did another test and with custom patches works ok...for some reason with the [osc~] help things about instances are strange...this time i have audio output "inverted" so instance on track 1 goes to instance on track 2 audio out and viceversa....probably there's some strange thing in the messages in those help patches? try this to little examples on two different instances and then open osc~ help file on both and check tests.zip

[timothyschoen]

Thanks, I'm able to reproduce it now! Knowing that it doesn't happen in Camomile also helps a lot!

[timothyschoen]

It's fixed! Turns out it wasn't that hard.

I do get a lot of crashes still when using PlugData in a DAW, I have to admit I tested the standalone a bit more thoroughly at this point, because debugging in the DAW is a bit of a hassle. I'll make sure it's better by the next release!

[timothyschoen]

I'm closing this issue, the only thing not implemented is the "object sticks to mouse" thing, I'll keep that one in my mind ;)