<div dir="ltr"><div>Would it be difficult to retain the old behavior with -legacy? That's how we usually deal with compatibility issues like this, don't we?</div><div><br></div><div>Also, I don't think that this warrants a major release bump. We didn't do that either, e.g., with the bendin fix, which IMHO is a similar case.<br></div><div><br></div><div>Albert</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 8:27 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, May 27, 2020 at 1:41 PM Ivica Bukvic <<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>> wrote:<br>
><br>
> Thank you, Jonathan. I'm curious as to the reason for removing bang from the selected object? I imagine this may break a number of older patches. Is this something that maintains parity with the vanilla?<br>
<br>
It was because the change introduced an ambiguity where argument<br>
"bang" could match<br>
both a "bang" message and "symbol bang" message. Since [route] already<br>
handles bang<br>
unambiguously and since the feature was never documented it seemed<br>
safe to remove it.<br>
<br>
I could make a branch of code in the select class to support that<br>
feature and couple it with a<br>
certain compatibility level. But that would require the user to a)<br>
know ahead of time which<br>
version number will unlock that branch and b) manually send a message<br>
to Pd to turn<br>
on that particular compatibility level.<br>
<br>
I started an issue related to the problems with the compatibility method:<br>
<br>
<a href="https://git.purrdata.net/jwilkes/purr-data/-/issues/636" rel="noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/issues/636</a><br>
<br>
-Jonathan<br>
<br>
><br>
> Best,<br>
><br>
> Ico<br>
><br>
> --<br>
> Ivica Ico Bukvic, D.M.A.<br>
> Director, Creativity + Innovation<br>
> Institute for Creativity, Arts, and Technology<br>
><br>
> Virginia Tech<br>
> Creative Technologies in Music<br>
> School of Performing Arts – 0141<br>
> Blacksburg, VA 24061<br>
> (540) 231-6139<br>
> <a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br>
><br>
> <a href="http://www.icat.vt.edu" rel="noreferrer" target="_blank">www.icat.vt.edu</a><br>
> <a href="http://www.performingarts.vt.edu" rel="noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
> <a href="http://l2ork.icat.vt.edu" rel="noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
> <a href="http://ico.bukvic.net" rel="noreferrer" target="_blank">ico.bukvic.net</a><br>
><br>
> On Wed, May 27, 2020, 12:52 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> We're gearing up for the official coding period to begin for Purr Data<br>
>> GSoC. Exciting!<br>
>><br>
>> A few orders of business:<br>
>><br>
>> 1. I've got a 3.0.0 version coming up. Since it removes "bang" method<br>
>> from [select] (thanks Zack) I incremented the major version to signify<br>
>> a breaking change.<br>
>><br>
>> 2. I'd like to update the nw.js toolkit to the most recent version for<br>
>> the next version 3.0.1. Is anyone willing to help test and report<br>
>> bugs? Unfortunately we have no regression test for the front-end so it<br>
>> will probably require some time and effort to do this right.<br>
>><br>
>> -Jonathan<br>
>> _______________________________________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div>