<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1449615057379_53523">And by "test it out", I mean I'll implement it and see if it works.</div><div id="yui_3_16_0_1_1449615057379_53521"><br></div><div id="yui_3_16_0_1_1449615057379_53519">-Jonathan<br></div><div id="yui_3_16_0_1_1449615057379_53487"><span></span></div> <br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Tuesday, December 8, 2015 11:44 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div id="yiv8132155181"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv8132155181"><div id="yiv8132155181yui_3_16_0_1_1449615057379_47166"><div id="yiv8132155181yui_3_16_0_1_1449615057379_47165" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div dir="ltr">Thanks for doing all that boring legacy work. I'll bring it into the GUI port and <br clear="none"></div><div dir="ltr">see how it works.<br clear="none"></div><div dir="ltr"><br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47890">Would this work as a canvas flag? That is, we'd set a bit in Pd-l2ork for new <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47888">canvases that means, "this is a Pd-l2ork canvas." The bit would get saved in <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47886">the canvas flag argument when you save the patch. Then when you load a <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47884">canvas, you check to see if that bit is set-- Vanilla patches won't have it set, <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47882">and Pd-l2ork will.[1] Then just set a canvas member (gl_legacy or whatever) for <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47880">access later.</div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47898"><br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47878">Eyeballing the diff, it looks like the only thing that would change is that you'd <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47876">multiply by x->gl_legacy instead of the sys_legacy flag. Does that make <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47874">sense?</div><div id="yiv8132155181yui_3_16_0_1_1449615057379_47858"><br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47860">If it does, I'll go ahead and test it out in the port. The benefit is that the user <br clear="none"></div><div dir="ltr">can then mix and match legacy canvases and gops with new ones, and <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47862">everything will "just work". (Well, I guess I'll have to "flip" the bit for the current Pd-l2ork gop abstractions, but that's not a big deal.)</div><div id="yiv8132155181yui_3_16_0_1_1449615057379_47864"><br clear="none"></div><div id="yiv8132155181yui_3_16_0_1_1449615057379_47866">-Jonathan<br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_47868"><br clear="none"></div><div id="yiv8132155181yui_3_16_0_1_1449615057379_43788"><span></span></div><div id="yiv8132155181yui_3_16_0_1_1449615057379_48020"> [1] keep in mind that Vanilla still has the flag argument itself, so we can safely <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_48174">query it using bitwise math. Furthermore, Vanilla can still read patches where the pd-l2ork bit has been set-- it will just ignore it and display the iemguis <br clear="none"></div><div dir="ltr" id="yiv8132155181yui_3_16_0_1_1449615057379_48303">askew.<br clear="none"></div><br clear="none"><div class="yiv8132155181qtdSeparateBR"><br clear="none"><br clear="none"></div><div class="yiv8132155181yqt1187834052" id="yiv8132155181yqt35670"></div></div></div></div><div class="yiv8132155181yqt2760874781" id="yiv8132155181yqt89430"><div> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div dir="ltr"><font face="Arial" size="2"> On Tuesday, December 8, 2015 10:36 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv8132155181y_msg_container">A couple of recent updates to pd-l2ork beg for more testing and we could <br clear="none">really use your help in vetting these before making a next official <br clear="none">release. Most notably, the new git version includes:<br clear="none"><br clear="none">*new legacy mode (invoked using the -legacy flag at pd-l2ork startup) <br clear="none">that repositiones all iemgui objects to match their old (albeit <br clear="none">inconsistent) locations. This should make it effectively possible to <br clear="none">open old patches and make them look nearly identical on pd-l2ork. The <br clear="none">remaining caveat is that pd-l2ork includes object labels when <br clear="none">calculating their bounding box and therefore there are still <br clear="none">inconsistencies in the way how for instance gatoms and iemgui objects <br clear="none">are rendered (or not rendered) inside graph-on-parent (GOP) subpatcher <br clear="none">based on whether they truly fit inside GOP or not.<br clear="none"><br clear="none">*Ability to use $0 in messages and having those automatically converted <br clear="none">into canvas instance (mixed messages including $0 are also possible).<br clear="none"><br clear="none">*Ability to use $n and #n anywhere in the labels, sends, and receives in <br clear="none">gatoms and iemgui objects, including ability to use multiple instances <br clear="none">of them (e.g. $0-blah-$1 or #0#1a etc.). Also ability to use # as a <br clear="none">character inside these same entries (e.g. # alone or followed by a <br clear="none">non-digit will remain unchanged, whereas #0 will be resolved into canvas <br clear="none">instance and #1 into first patcher creation argument)<br clear="none"><br clear="none">All of these should be implemented retaining backwards compatibility. <br clear="none">So, at this point I am looking for any possible regressions or observed <br clear="none">major performance impact due to newly added features. Your assistance in <br clear="none">this effort is most appreciated.<br clear="none"><br clear="none">NB: We are working on a 64-bit build for Ubuntu 14.04 which we will <br clear="none">share with those interested in providing feedback. Given this is a <br clear="none">development version, we will not provide 32-bit builds or debs for other <br clear="none">distros and would prefer not to widely publicize its availability as we <br clear="none">are not sure yet if the newly implemented features are regression free. <br clear="none">Ideally, those interested in testing should build their own version, <br clear="none">which should be a simple 3-step process, including installing the new <br clear="none">version.<br clear="none"><br clear="none">If all goes well, a new version with this and other additions should go <br clear="none">live sometime later this month.<br clear="none"><br clear="none">Best,<br clear="none"><br clear="none">-- <br clear="none">Ivica Ico Bukvic, D.M.A.<br clear="none">Associate Professor<br clear="none">Creative Technologies in Music<br clear="none">ICAT Senior Fellow<br clear="none">Director -- DISIS, L2Ork<br clear="none">Virginia Tech<br clear="none">School of Performing Arts – 0141<br clear="none">Blacksburg, VA 24061<br clear="none">(540) 231-6139<br clear="none">www.performingarts.vt.edu<br clear="none">disis.music.vt.edu<br clear="none">l2ork.music.vt.edu<br clear="none">ico.bukvic.net<br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"><br clear="none"><br clear="none"></div> </div> </div> </div></div></div></div></div><br><div class="yqt2760874781" id="yqt15191">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>