On 06/14/2013 12:07 PM, Jonathan Wilkes wrote:
>The real problem is: having the feature forces every pd flavor to
>understand them at the file format level, even if not rendering it.
If the "connect" method took A_GIMME you could just follow its
initial four floats with a list of coordinates.
-Jonathan
Indeed. This is how pd-l2ork maintains backwards compatibility for a
number of features. That said, storing coordinates in the existing file
format and/or drawing the cord are not the problem. The problem is what
happens when you translate the object the cord is connected to?
Uncovering logic whether all the coordinates need to be translated (as
opposed to only last one) is something that even Max fails to do
gracefully despite the fact it has been capable of this for over 10
years, perhaps in part because there is no perfect/graceful way to deal
with this that does not require some fairly evolved logic.
Another challenge is cord selection. What needs to be checked is if the
existing cord selection logic is indeed robust to handle new segmented
cords. Although my memory is not what it used to be, as far as I
remember, the hitbox detection is fairly primitive when it comes to
cords and in its current form is not capable of gracefully handling
this. Please correct me if I am wrong.
Perhaps more pressing matter IMO is ability to multiselect cords so that
you can erase many of them at once without having to resort to hack-ish
ways of cutting and pasting objects.
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
