And by "test it out", I mean I'll implement it and see if it works.

-Jonathan



On Tuesday, December 8, 2015 11:44 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote:


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,

--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Creative Technologies in Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list