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

[Albert Graef]

On Thu, Jul 30, 2020 at 9:23 PM Jonathan Wilkes <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. 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>
> 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
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> >
> >
> > --
> > Dr. Albert Gr"af
> > Computer Music Research Group, JGU Mainz, Germany
> > Email: 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
> _______________________________________________
> L2Ork-dev mailing list
> 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, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200731/67214d87/attachment.html>