[PD] enhance pd-extended with pd-l2ork featues ?

[Jonathan Wilkes]

----- Original Message -----
> From: Ivica Ico Bukvic <ico at vt.edu>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: 'Roman Haefeli' <reduzent at gmail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Monday, January 21, 2013 1:16 AM
> Subject: Re: [PD] enhance pd-extended with pd-l2ork featues ?
> 
> On 01/21/2013 12:15 AM, Jonathan Wilkes wrote:
>>  Also see the end of:
>>  http://www.youtube.com/watch?v=wTPZxcgWoI0
>> 
>>  When undoing the creation of an object or objects, at some point Pd-l2ork 
> will move
>>  the object to the place where the mouse happened to be hovering when the 
> user clicked
>>  <ctrl-1> to get an empty box dangling from the mouse.  But the user 
> never actually
>>  anchored the object there-- they only anchored it somewhere once they 
> clicked the
>>  mouse button.  Thus, your undo history erroneously adds an object placement 
> event
>>  that was never performed by the user in the first place.
>> 
>>  Theoretically the corresponding undo event should make the object dangle 
> from the
>>  mouse again, but that's of very little practical value and would just 
> bloat the undo
>>  history with an extra step for every object in the chain.  Instead this 
> event should
>>  simply not be added to the undo history.  I don't know the innards of 
> pd well, but those
>>  "dangle" events should all have a single "0" as a 
> coordinate so maybe you can check
>>  for that.
>> 
>>  -Jonathan
>> 
>> 
> That is not a bug. That is how pd instantiates objects. As soon as your cursor 
> touches canvas, it will instantiate an object at the last known cursor position 
> (if the cursor is off-canvas) or next to mouse cursor and then enable motion for 
> the object to follow the cursor until a mouse clicks (there is an exception when 
> autopatching in which case motion is not enabled, but that is not relevant to 
> this example). So, if you create an object without having a mouse on canvas, 
> then move mouse onto it, the object will instantiate where you had your cursor 
> the last time and then immediately move (since the startmotion was triggered) 
> next to your cursor once you've positioned it back over the canvas. So, in 
> essence there are 2 steps undo is keeping track of. Yes, this addition adds 
> extra step but is a lot easier to manage than coming up with yet another 
> exception on how the editing works. Doing what you suggest could easily 
> obliterate undo and annoy user when they do series of undos and then suddently 
> the object is back hooked onto mouse and the next thing you know, the undo has 
> rebranched since it assumes that the user is now wanting to do something new 
> from that spot onwards making them lose forward undo history. This is all 
> because pd first instantiates objects, then asks question where the object 
> should go. While ideally this one step could be skipped, it would require a 
> fairly hefty rewrite for a mere skip of one undo step...
>

For each object the user instantiates through the "Put" menu or keyboard shortcut,
they end up with an entry in the undo history they are guaranteed _never_ to
use and which they almost certainly understood as a transient patch state since the
object had a _blue_ outline and was dangling from the mouse in the same way it dangles
from the mouse when they left click and drag (which itself is a transient patch state).
That means when making a new patch, for every n object that is not autopatched the
user must view n patch states on their way to the beginning of the history that never
actually existed by the rules of the graphical interface.  I'd call that a recurring nuisance
that is not unlike an insect sporadically greeting different parts of your head by buzzing
around it.

More practically: when the user is one step away from the history to which he/she
wants to return, he she has a $n/$undo_count*100 chance of being two steps away.

-Jonathan