[L2Ork-dev] dynamic patching and undo/redo system

Ivica Ico Bukvic ico at vt.edu
Fri Jul 31 00:04:18 EDT 2020


There are canvas_undo_free and canvas_undo_init that may be of help.

Best,

Ico

On 7/30/2020 6:02 PM, Albert Graef wrote:
> On Thu, Jul 30, 2020 at 9:23 PM Jonathan Wilkes 
> <jon.w.wilkes at gmail.com <mailto:jon.w.wilkes at gmail.com>> wrote:
>
>     Is there already a clear method for the undo/redo system?
>
>
> I don't remember, I haven't looked at that code recently. But Ico 
> should be able to answer that question.
>
>     Also, what is a maintainable way to clear on, say, dynamic patching?
>
>
> Well, dynamic patching happens by sending a bunch of special messages 
> representing objects, connections and the like to the pd-name 
> receiver, where name is the name of a (sub)patch, or a declared canvas 
> name. Clearing the history would have to be done in the corresponding 
> patch (or canvas?) message handlers. I think that there should be a 
> page on dynamic patching with documentation of the available messages 
> along with some examples somewhere on puredata.info 
> <http://puredata.info>. A quick search turned up this: 
> http://puredata.info/docs/tutorials/TipsAndTricks#patch-messages
>
> Albert
>
>     > On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes
>     <jon.w.wilkes at gmail.com <mailto:jon.w.wilkes at gmail.com>> wrote:
>     >>
>     >> Hi all,
>     >>
>     >> It appears that dynamic patching nnd the undo system are
>     irreconcilable.
>     >>
>     >> For example-- Suppose you do this:
>     >>
>     >> [namecanvas foo]
>     >>
>     >> [obj 20 20 clip(
>     >> |
>     >> [send foo]
>     >>
>     >> Whenever you click the message box, a new object will be
>     created but
>     >> without any undo history.
>     >>
>     >> That's probably desirable behavior, as we don't want a bunch of
>     >> dynamically created gumming up the undo system.
>     >>
>     >> However, the undo system is based off object indices. So by
>     inserting
>     >> "[clip]" into a glist we corrupt that system. You can see this if
>     >> dynamic patching in the middle of other editing actions. Doing undo
>     >> then redo will put the patch in a corrupt state because the indices
>     >> will be off by one due to the "[clip]" object that the undo system
>     >> didn't expect.
>     >>
>     >> I don't know any clean way to deal with this. But it affects
>     more than
>     >> dynamic patching:
>     >>
>     >> [pointer(
>     >> |
>     >> [canvasinfo]
>     >> |
>     >> [20 20 $1(
>     >> |
>     >> [append some_scalar x y]
>     >>
>     >> Same problem there, as well as:
>     >>
>     >> [pointer(
>     >> |
>     >> [canvasinfo]
>     >> |
>     >> [next, delete(
>     >> |
>     >> [pointer some-scalar]
>     >>
>     >> Each one breaks the assumptions of the undo system and undo/redo
>     >> actions can have wrong indices.
>     >>
>     >> Even more pressing-- now that we've got pointer delete method, the
>     >> undo system can have an out-of-bounds index and crash when it
>     tries to
>     >> deference a null pointer.
>     >>
>     >> Any ideas on how to approach this?
>     >>
>     >> -Jonathan
>     >> _______________________________________________
>     >> L2Ork-dev mailing list
>     >> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>     >> https://disis.music.vt.edu/listinfo/l2ork-dev
>     >
>     >
>     >
>     > --
>     > Dr. Albert Gr"af
>     > Computer Music Research Group, JGU Mainz, Germany
>     > Email: aggraef at gmail.com <mailto:aggraef at gmail.com>, web:
>     https://agraef.github.io/
>     > _______________________________________________
>     > L2Ork-dev mailing list
>     > L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>     > https://disis.music.vt.edu/listinfo/l2ork-dev
>     _______________________________________________
>     L2Ork-dev mailing list
>     L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>     https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
> -- 
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com <mailto:aggraef at gmail.com>, web: 
> https://agraef.github.io/
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Director, Human Centered Design iPhD
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200731/51ca55d3/attachment.html>


More information about the L2Ork-dev mailing list