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

[Jonathan Wilkes]

On Thu, Jul 30, 2020 at 6:03 PM Albert Graef <aggraef at gmail.com> wrote:
>
> 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

What I mean is how do we differentiate between dynamic patching and a)
loading a patch or b) regular patching through
the g_editor.c event callbacks?

For example, there are no breadcrumbs left in canvas_obj to tell the
difference. And I'd hate to add a bunch more globals
to track "is_loading_stuff", "is_editing_stuff", "is_dynamically_patching", etc.

-Jonathan

>
> 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/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev