So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes like 5
minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
Thanks for the update.
I will investigate the popup and mknob. Ive just started cleaning up externals so things like these may crop up depending whether Ive used them or not.
Undo redraws the patch due to the way how pd draws things so on a huge patch it may take a while. 5 seconds (needles to say 5 minutes?) is way too long, however, and I wonder if the problem lies elsewhere as Ive never had such problems on a measly atom netbook.
Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldnt they?
From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of András Murányi Sent: Friday, February 22, 2013 3:34 PM To: pd-list Subject: [PD] pd-l2ork feedback
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds
of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes like 5
minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes
like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, I hunted down some problems within the gop redrawing which should streamline things even further. That said, flatgui objects like knob are chronically broken. I also tested them in the latest version of pd-extended. Try creating one knob, then another in the same window. Now delete one and crash... Tons of problems with it on other levels as well... I am really thinking about getting rid of flatgui altogether.
On 02/22/2013 04:37 PM, Ivica Ico Bukvic wrote:
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because
some kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes
like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Popup is similar in that respect--terribly inefficient when it comes it drawing it...
On 02/22/2013 08:34 PM, Ivica Ico Bukvic wrote:
OK, I hunted down some problems within the gop redrawing which should streamline things even further. That said, flatgui objects like knob are chronically broken. I also tested them in the latest version of pd-extended. Try creating one knob, then another in the same window. Now delete one and crash... Tons of problems with it on other levels as well... I am really thinking about getting rid of flatgui altogether.
On 02/22/2013 04:37 PM, Ivica Ico Bukvic wrote:
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because
some kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error
when clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes
like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended.
Nested gop subpatches should show their outlines and xlets (just like
number2 or toggle does as well), shouldn’t they?
Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches ("Cut" and "Res"; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch.
András
On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic ico@vt.edu wrote:
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes like 5
minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width.
Regarding slow redraw, can you try latest version? I fixed one major inefficiency. On Feb 26, 2013 6:22 PM, "András Murányi" muranyia@gmail.com wrote:
Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended.
Nested gop subpatches should show their outlines and xlets (just like
number2 or toggle does as well), shouldn’t they?
Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches ("Cut" and "Res"; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch.
András
On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic ico@vt.edu wrote:
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes like
5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic ico@vt.edu wrote:
This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width.
Yes this is indeed the case. I noticed, however, that there was no title
to be displayed, meaning that with "hide GOP title" unchecked, the rectangle was bigger but there was no title (see attachment). And it shows the frame when it's embedded in another GOP.
Regarding slow redraw, can you try latest version? I fixed one major inefficiency.
I'll try it as soon as I get to it. I noticed meanwhile that during the hangup, this error is thrown to the command line a few times: tcl/tk error: unknown encoding "yahoo"
András
On Feb 26, 2013 6:22 PM, "András Murányi" muranyia@gmail.com wrote:
Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended.
Nested gop subpatches should show their outlines and xlets (just like
number2 or toggle does as well), shouldn’t they?
Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches ("Cut" and "Res"; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch.
András
On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic ico@vt.edu wrote:
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes?
Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way...
Is the same slowness perceived on regular pd when moving the said abstraction?
On 02/22/2013 03:34 PM, András Murányi wrote:
So, I've played around with the last git, here are some things I've noticed:
- miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
kinds of [widget] work while others not.
- [flatgui/popup] is installed by default but it throws an error when
clicked on: Invalid command name "pdtk_canvas_mouse".
- moving a simple GOP abstraction with a single [mknob] in it takes like
5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec).
- nested GOP subpatches show off their outlines and xlets.
-- Murányi András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/26/2013 09:07 PM, András Murányi wrote:
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic <ico@vt.edu mailto:ico@vt.edu> wrote:
This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width.Yes this is indeed the case. I noticed, however, that there was no title to be displayed, meaning that with "hide GOP title" unchecked, the rectangle was bigger but there was no title (see attachment). And it shows the frame when it's embedded in another GOP.
AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those.
As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate.
Regarding slow redraw, can you try latest version? I fixed one major inefficiency.I'll try it as soon as I get to it. I noticed meanwhile that during the hangup, this error is thrown to the command line a few times: tcl/tk error: unknown encoding "yahoo"
This likely refers to text encoding if you use something unusual/setup-specific.
HTH
András
On Feb 26, 2013 6:22 PM, "András Murányi" <muranyia@gmail.com <mailto:muranyia@gmail.com>> wrote: Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they? Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches ("Cut" and "Res"; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch. András On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic <ico@vt.edu <mailto:ico@vt.edu>> wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote:So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name "pdtk_canvas_mouse". - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András_______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/26/2013 09:48 PM, Ivica Ico Bukvic wrote:
AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those.
As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate.
BTW, I just checked on pd-l2ork and everything draws just as it should even with multiply embedded GOPs (ones with text enabled show text and ones with it disabled don't.
Best wishes,
Ico
On Wed, Feb 27, 2013 at 4:31 AM, Ivica Ico Bukvic ico@vt.edu wrote:
On 02/26/2013 09:48 PM, Ivica Ico Bukvic wrote:
AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those.
As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate.
BTW, I just checked on pd-l2ork and everything draws just as it should even with multiply embedded GOPs (ones with text enabled show text and ones with it disabled don't.
Best wishes,
Ico
Oh, i see now... It's just that in l2ork the frame and the xlets are the foremost while in extended they are in the background so anything on the top of them can effectively cover them up. Thanks for bearing with me! I'll try dragging in a few days.
András
Ico
Oh, i see now... It's just that in l2ork the frame and the xlets are the foremost while in extended they are in the background so anything on the top of them can effectively cover them up. Thanks for bearing with me! I'll try dragging in a few days.
András
If youre looking to make cool looking GOP elements in Pd-l2Ork you can cover the frame with a custom version of ggee/image which supports png/transparency (see K-12 mode) and whose area is not indicative of the image itself so it can spill outside the GOP.
Best wishes,
Ico
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic ico@vt.edu wrote:
[...]
Regarding slow redraw, can you try latest version? I fixed one major inefficiency.
I've just compiled the latest git and the slowness is still there. I have the vague impression though, that dragging the ominous abstraction got faster (2 minutes vs previous 5), but again, this is just an impression.
András
Can you forward patch(es)? Does the abstraction use any non-default gui objects? On Mar 3, 2013 11:34 AM, "András Murányi" muranyia@gmail.com wrote:
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic ico@vt.edu wrote:
[...]
Regarding slow redraw, can you try latest version? I fixed one major inefficiency.
I've just compiled the latest git and the slowness is still there. I have the vague impression though, that dragging the ominous abstraction got faster (2 minutes vs previous 5), but again, this is just an impression.
András
-
András Murányi -
Ivica Bukvic -
Ivica Ico Bukvic