[L2Ork-dev] [PD] pd-l2ork git updates -- looking for testers

[Jonathan Wilkes]

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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20151209/e1fc1859/attachment-0001.html>