Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Hi,
Here are some scrolling observations:
In the attached patch, drag the [pd] object far down into the
bottom right-hand corner, so that you get some scrollbars to appear.
Now, on the current pd-extended, you can scroll down to that object,
and when you drag it back to its original location, the scrollbars
respond in realtime so that the object swoops back up the patch
until, finally, the scrollbars disappear. In your version the
scrollbars don't react until you stop dragging and release the mouse
button. Just an observation-- I suppose both methods have their
strengths and weaknesses. I prefer the current Pd-ext behavior--
for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up.
But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning.
-Jonathan
On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote:
Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear.
Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up.But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning.
-Jonathan
Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense.
The reason canvas is displaced in l2ork version is because our philosophy is "if a patch can fit in a window, it should." Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to "lock-in" patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that.
NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support.
Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object.
Cheers!
Ico
--- On Mon, 11/29/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "András Murányi" muranyia@gmail.com, "PD List" pd-list@iem.at Date: Monday, November 29, 2010, 8:34 AM On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote:
Hi, Here are some scrolling
observations:
In the attached patch, drag the [pd] object far down
into the
bottom right-hand corner, so that you get some
scrollbars to appear.
Now, on the current pd-extended, you can scroll down
to that object,
and when you drag it back to its original location,
the scrollbars
respond in realtime so that the object swoops back up
the patch
until, finally, the scrollbars disappear. In
your version the
scrollbars don't react until you stop dragging and
release the mouse
button. Just an observation-- I suppose both
methods have their
strengths and weaknesses. I prefer the current
Pd-ext behavior--
for example, if I happen to paste an object into
another patch with a smaller window size, it makes it quick to drag it back up.
But notice that once you drag the [pd] object back
near its original
position, the [f] object looks as if it's at (0,0),
when it's really
at (10,10). However, if you save the patch and
reopen it the [f]
will appear at its proper, original position--
(10,10). I think this
is a bug, because it means any time one adds or takes
away the
scrollbars the absolute positioning of the objects on
the canvas is
temporarily lost, forcing the user to close and open
to see the
real positioning.
-Jonathan
Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense.
That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference.
The reason canvas is displaced in l2ork version is because our philosophy is "if a patch can fit in a window, it should." Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to "lock-in" patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that.
NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support.
Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object.
Cheers!
Ico
Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense.
That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference.
Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments:
*changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion).
As usual feedback is most appreciated.
http://l2ork.music.vt.edu/main/?page_id=56
Best wishes,
Ico
On Nov 29, 2010, at 2:47 PM, Ivica Ico Bukvic wrote:
Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense.
That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference.
Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments:
*changed paste action so that it pastes where the current mouse
position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new
scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality
of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging
of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion).As usual feedback is most appreciated.
Ctrl-R raises the Pd window on Pd 0.43 and Pd-extended 0.42. How
about making the cord inspector Ctrl-I?
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jonathan Wilkes