<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 30, 2020 at 9:23 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there already a clear method for the undo/redo system?<br></blockquote><div><br></div><div>I don't remember, I haven't looked at that code recently. But Ico should be able to answer that question.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Also, what is a maintainable way to clear on, say, dynamic patching?<br></blockquote><div><br></div><div>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 <a href="http://puredata.info">puredata.info</a>. A quick search turned up this: <a href="http://puredata.info/docs/tutorials/TipsAndTricks#patch-messages">http://puredata.info/docs/tutorials/TipsAndTricks#patch-messages</a></div><div><br></div><div>Albert<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> It appears that dynamic patching nnd the undo system are irreconcilable.<br>
>><br>
>> For example-- Suppose you do this:<br>
>><br>
>> [namecanvas foo]<br>
>><br>
>> [obj 20 20 clip(<br>
>> |<br>
>> [send foo]<br>
>><br>
>> Whenever you click the message box, a new object will be created but<br>
>> without any undo history.<br>
>><br>
>> That's probably desirable behavior, as we don't want a bunch of<br>
>> dynamically created gumming up the undo system.<br>
>><br>
>> However, the undo system is based off object indices. So by inserting<br>
>> "[clip]" into a glist we corrupt that system. You can see this if<br>
>> dynamic patching in the middle of other editing actions. Doing undo<br>
>> then redo will put the patch in a corrupt state because the indices<br>
>> will be off by one due to the "[clip]" object that the undo system<br>
>> didn't expect.<br>
>><br>
>> I don't know any clean way to deal with this. But it affects more than<br>
>> dynamic patching:<br>
>><br>
>> [pointer(<br>
>> |<br>
>> [canvasinfo]<br>
>> |<br>
>> [20 20 $1(<br>
>> |<br>
>> [append some_scalar x y]<br>
>><br>
>> Same problem there, as well as:<br>
>><br>
>> [pointer(<br>
>> |<br>
>> [canvasinfo]<br>
>> |<br>
>> [next, delete(<br>
>> |<br>
>> [pointer some-scalar]<br>
>><br>
>> Each one breaks the assumptions of the undo system and undo/redo<br>
>> actions can have wrong indices.<br>
>><br>
>> Even more pressing-- now that we've got pointer delete method, the<br>
>> undo system can have an out-of-bounds index and crash when it tries to<br>
>> deference a null pointer.<br>
>><br>
>> Any ideas on how to approach this?<br>
>><br>
>> -Jonathan<br>
>> _______________________________________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
><br>
><br>
> --<br>
> Dr. Albert Gr"af<br>
> Computer Music Research Group, JGU Mainz, Germany<br>
> Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div></div>