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

Sun Jun 7 18:06:05 EDT 2020

On Sun, Jun 7, 2020 at 2:13 PM Ivica Bukvic <ico at vt.edu> wrote:
>
> So, I just fixed this on my branch and created what I am hoping will be a clean merge request together with an example patch  https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/357

Yeah, this looks like a straight up bug. Same behavior in Pd Vanilla.
I can't believe it's gone unnoticed
for this long.

Unless someone can think of a reason why an unmatched "bang" shouldn't
get send to the rejection outlet,
I'll make some regression tests for this and merge it.

-Jonathan

>
> --
> 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
>
> ci.icat.vt.edu
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
>
>
> On Sun, Jun 7, 2020 at 1:06 PM Ivica Bukvic <ico at vt.edu> wrote:
>>
>> So, another issue that has cropped up from this. I just found one spot inside my L2Ork Tweeter code where I can receive either a 0 or a bang. I used to do [sel 0] and then have bang come out of the second inlet. This is not possible anymore. Interestingly, replacing it with [route 0] does not output anything for bang. The route ignores it entirely instead of outputting it through the right outlet since it does not match 0. OTOH route bang does work and while that "fixes" the issue, it is definitely not something that is intuitive from a beginner's perspective. So, if we are to keep select as-is with the new improvement, then route needs to intelligently output bang through the second outlet when it does not match any of the route arguments.
>>
>> 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
>>
>> ci.icat.vt.edu
>> www.icat.vt.edu
>> www.performingarts.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>>
>>
>>
>> On Wed, Jun 3, 2020 at 12:11 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>>
>>> On Tue, Jun 2, 2020 at 10:07 PM Ivica Bukvic <ico at vt.edu> wrote:
>>> >
>>> > This is possible, but also precarious. While I like this potentially more universal solution, doing so may introduce a cascading set of incompatibilities and as such needs to have some thorough regression testing before being committed.
>>>
>>> Since pd_defaultanything only errors out it should be a dead end.
>>>
>>> > Further, with this universal fix allow select to once again support bang as a potential filter?
>>>
>>> It doesn't.
>>>
>>> -Jonathan
>>>
>>> >
>>> > 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 Tue, Jun 2, 2020, 19:43 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>> >>
>>> >> On Tue, Jun 2, 2020 at 5:58 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
>>> >> >
>>> >> > So, I just tested the 2.11 and my findings regarding the changes in the select object are that this is worse than the previous implementation because now the select outputs cryptic error that no beginner will understand. Even for advanced users it provides misleading info as the select object treats bang message as a list (which it is not). Try the attached patch.
>>> >>
>>> >> That horrible error appears to originate in pd_defaultanything which
>>> >> AFAICT is just an error-handling branch for non-existent methods.
>>> >>
>>> >> Unfortunately, a list with no arguments is handled by pd_defaultlist
>>> >> and a bona fide "bang" message is handled by pd_defaultbang. So for an
>>> >> object like [select], "bang"--[select] will take the pd_defaultbang
>>> >> path to error with the "s"
>>> >> argument set to "bang". Meanwhile, "list"---[select] ("list" is what
>>> >> [route] outputs) will take the pd_defaultlist path to the same error
>>> >> with "s" argument set to "list". Bleh.
>>> >>
>>> >> Fortunately, pd_defaultanything also has argc and argv. So we could
>>> >> just check there when s is "list" and argc is 0, and in that
>>> >> case use "bang" as the method that caused the error.
>>> >>
>>> >> That would fix this error not only for select but also for any other
>>> >> situation where zero length lists get sent around
>>> >> Pd. (Both [route] and the [list] objects will output zero-length
>>> >> "list" to mean "bang".)
>>> >>
>>> >> How about that?
>>> >>
>>> >> -Jonathan
>>> >>
>>> >> >
>>> >> > I recommend that we reinstate the original select behavior and on top of that ensure that both the bang and symbol bang are treated as one and the same. I understand this kind of patch is not going to be common or useful, yet one cannot predict architectural choices a beginner may make (for better or for worse) and I am of the opinion that we should do all we can (without breaking the core purr-data behavior) to make things as easy as possible.
>>> >> >
>>> >> > Best,
>>> >> >
>>> >> > Ico
>>> >> >
>>> >> > On 5/29/2020 3:50 PM, Albert Graef wrote:
>>> >> >
>>> >> > On Fri, May 29, 2020 at 3:07 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>> >> >>
>>> >> >> I bumped the minor version so it will be 2.11.0
>>> >> >
>>> >> >
>>> >> > Great, thanks!
>>> >> >
>>> >> > --
>>> >> > 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
>>> >> >
>>> >> > --
>>> >> > 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
>>> >> >
>>> >> > _______________________________________________
>>> >> > 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
>>> > 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
> https://disis.music.vt.edu/listinfo/l2ork-dev