[L2Ork-dev] Getting ready for GSoC coding to begin
jon.w.wilkes at gmail.com
Wed May 27 16:55:43 EDT 2020
On Wed, May 27, 2020 at 3:34 PM Albert Graef <aggraef at gmail.com> wrote:
> 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?
I was going to mention that, except that it appears Ico is the main user of this
feature. So shifting to legacy mode would fix [select] for him while breaking
all his GOP interfaces!
> 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.
Somehow I missed that one.
On this one we have one reported case from Ico. As I understand it,
removing a public method like
this is a breaking change and thus warrants the version bump.
We should probably all figure out a consistent approach. But for this
particular version bump there aren't
any practical consequences, are there? I mean there's no automated
tooling wrapped around Purr Data
that is going to break one million in-dash entertainment systems or anything...
> On Wed, May 27, 2020 at 8:27 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> On Wed, May 27, 2020 at 1:41 PM Ivica Bukvic <ico at vt.edu> wrote:
>> > 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?
>> It was because the change introduced an ambiguity where argument
>> "bang" could match
>> both a "bang" message and "symbol bang" message. Since [route] already
>> handles bang
>> unambiguously and since the feature was never documented it seemed
>> safe to remove it.
>> I could make a branch of code in the select class to support that
>> feature and couple it with a
>> certain compatibility level. But that would require the user to a)
>> know ahead of time which
>> version number will unlock that branch and b) manually send a message
>> to Pd to turn
>> on that particular compatibility level.
>> I started an issue related to the problems with the compatibility method:
>> > 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 Wed, May 27, 2020, 12:52 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >> Hi all,
>> >> We're gearing up for the official coding period to begin for Purr Data
>> >> GSoC. Exciting!
>> >> A few orders of business:
>> >> 1. I've got a 3.0.0 version coming up. Since it removes "bang" method
>> >> from [select] (thanks Zack) I incremented the major version to signify
>> >> a breaking change.
>> >> 2. I'd like to update the nw.js toolkit to the most recent version for
>> >> the next version 3.0.1. Is anyone willing to help test and report
>> >> bugs? Unfortunately we have no regression test for the front-end so it
>> >> will probably require some time and effort to do this right.
>> >> -Jonathan
>> >> _______________________________________________
>> >> L2Ork-dev mailing list
>> >> L2Ork-dev at disis.music.vt.edu
>> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> > _______________________________________________
>> > L2Ork-dev mailing list
>> > L2Ork-dev at disis.music.vt.edu
>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
> 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
More information about the L2Ork-dev