[L2Ork-dev] Getting ready for GSoC coding to begin

Ivica Bukvic ico at vt.edu
Thu May 28 08:46:02 EDT 2020


I recommend doing a minor version bump and saving the major for when we do
something major, e.g. merging k12 and/or this summer work. Don't worry
about me and the use of the bang signal with the [select] object in my
code. I believe I only have one of those that I know of so far and am happy
to fix them, so no legacy flags are necessary as far as I am concerned (I
have no interest in legacy features anyhow, and vanilla legacy would break
a bunch of stuff for L2Ork).

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Thu, May 28, 2020, 03:44 Albert Graef <aggraef at gmail.com> wrote:

> On Thu, May 28, 2020 at 8:00 AM Albert Graef <aggraef at gmail.com> wrote:
>
>> While we're at it, there's yet another problem: I doubt that rev.
>> 779f31dc entirely fixes the issue reported in #299.
>>
>
> False alarm, please ignore that comment. I just installed the very latest
> revision and it properly prints an error message with plain bang on the
> first inlet now. Seems that I was still running an older version built from
> the fix-graph-label-position branch which didn't have commit 779f31dc yet.
>
> So where does this leave us now? For me rev. 779f31dc fixes a bug and an
> incompatibility with present vanilla. So it doesn't make any sense to use
> -legacy in this case. OTOH, obviously this change may break some patches
> employing the "plain bang on select's first inlet" (mis)feature, which is
> completely at odds with how select behaves in all other symbol cases.
>
> Heck, apparently even Miller decided to fix this at some point, and he
> usually rejects *anything* which breaks backward compatibility in vanilla.
>
> So it's certainly the right thing(TM) to fix this bug IMHO, and if it's
> not a breaking change for Miller, then should it be a breaking change for
> us? I don't think so. I know that this won't make Ico happy (sorry, Ico!),
> but I really think that patches exploiting this (old and undocumented)
> misfeature need to be fixed, simple as that. :)
>
> Just my 0.02 cents...
>
> Albert
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200528/0e29139f/attachment.html>


More information about the L2Ork-dev mailing list