[PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)

Jonathan Wilkes jancsika at yahoo.com
Mon Nov 29 09:21:45 CET 2010



--- On Mon, 11/29/10, Ivica Ico Bukvic <ico at vt.edu> wrote:

> From: Ivica Ico Bukvic <ico at vt.edu>
> Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: "András Murányi" <muranyia at gmail.com>, "PD List" <pd-list at 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
> 
> 
> 


      



More information about the Pd-list mailing list