<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 10:58 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">
1. When loading a Vanilla patch in Purr Data, what is the optimal UX<br>
so that the user gets something as close as possible to Vanilla<br>
behavior/display with the least amount of work/knowledge?<br>
[...]<br>
Albert has a current merge request wrt #1 here:<br>
<br>
<a href="https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/561" rel="noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/561</a></blockquote><div><br></div><div>That's not entirely true. Jonathan wants to address all (or most) legacy issues we encounter when exchanging patches between Purr Data and Vanilla in a completely (or mostly) automatic way, by keeping track of the Pd version a (sub)patch was created with (Purr or Vanilla).</div><div><br></div><div>My MR is much more modest (and presumably simpler). It's about enabling some canvas-local flags (maintained with `declare`) for some specific global options. Currently I'm concerned solely with the "legacy-bendin" and "save/restore zoom level" flags, which are causing me woes because at present they can only be set globally and not locally in a patch.</div><div><br></div><div>So the two approaches are really different (although not completely orthogonal), and also aimed at different audiences.<br></div><div><br> </div><div>But I don't want to rehash the entire discussion here, please go to <a href="https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/561">https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/561</a> for more details.</div><div><br></div><div>Thanks,</div><div>Albert</div><div><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">
Just writing out these points, I'm not wondering if #2 could be solved<br>
with some kind of menu button that analyzes the current patch's binbuf<br>
and prints out a series of "compatibility errors" so that the user can<br>
click the link and visit the relevant object.<br>
<br>
Best,<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></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>