Thanks for doing all that boring legacy work. I'll bring it into the GUI port and see how it works.
Would this work as a canvas flag? That is, we'd set a bit in Pd-l2ork for new canvases that means, "this is a Pd-l2ork canvas." The bit would get saved in the canvas flag argument when you save the patch. Then when you load a canvas, you check to see if that bit is set-- Vanilla patches won't have it set, and Pd-l2ork will.[1] Then just set a canvas member (gl_legacy or whatever) for access later. Eyeballing the diff, it looks like the only thing that would change is that you'd multiply by x->gl_legacy instead of the sys_legacy flag. Does that make sense? If it does, I'll go ahead and test it out in the port. The benefit is that the user can then mix and match legacy canvases and gops with new ones, and 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.) -Jonathan
[1] keep in mind that Vanilla still has the flag argument itself, so we can safely 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 askew.
On Tuesday, December 8, 2015 10:36 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:
A couple of recent updates to pd-l2ork beg for more testing and we could really use your help in vetting these before making a next official release. Most notably, the new git version includes:
*new legacy mode (invoked using the -legacy flag at pd-l2ork startup) that repositiones all iemgui objects to match their old (albeit inconsistent) locations. This should make it effectively possible to open old patches and make them look nearly identical on pd-l2ork. The remaining caveat is that pd-l2ork includes object labels when calculating their bounding box and therefore there are still inconsistencies in the way how for instance gatoms and iemgui objects are rendered (or not rendered) inside graph-on-parent (GOP) subpatcher based on whether they truly fit inside GOP or not.
*Ability to use $0 in messages and having those automatically converted into canvas instance (mixed messages including $0 are also possible).
*Ability to use $n and #n anywhere in the labels, sends, and receives in gatoms and iemgui objects, including ability to use multiple instances of them (e.g. $0-blah-$1 or #0#1a etc.). Also ability to use # as a character inside these same entries (e.g. # alone or followed by a non-digit will remain unchanged, whereas #0 will be resolved into canvas instance and #1 into first patcher creation argument)
All of these should be implemented retaining backwards compatibility. So, at this point I am looking for any possible regressions or observed major performance impact due to newly added features. Your assistance in this effort is most appreciated.
NB: We are working on a 64-bit build for Ubuntu 14.04 which we will share with those interested in providing feedback. Given this is a development version, we will not provide 32-bit builds or debs for other distros and would prefer not to widely publicize its availability as we are not sure yet if the newly implemented features are regression free. Ideally, those interested in testing should build their own version, which should be a simple 3-step process, including installing the new version.
If all goes well, a new version with this and other additions should go live sometime later this month.
Best,