[L2Ork-dev] Current HEAD of Purr Data is broken

Ivica Bukvic ico at vt.edu
Wed Jul 1 13:26:07 EDT 2020


This is what I get when opening the patch:

https://drive.google.com/file/d/1Rp_0Vya5pSkwcAA5yomKiEwL_w9U7UBI/view?usp=sharing

Is that expected behavior or is something else supposed to happen?

(please disregard the excessive printouts to the console--I haven't yet
merged the other fix while filming this excerpt)

-- 
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.eduwww.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Wed, Jul 1, 2020 at 12:35 AM Albert Graef <aggraef at gmail.com> wrote:

> Ok, that improved things *a lot*. The about dialog is working again, as
> does doc/4.data.structures/07.sequencer.pd. But I'm still having trouble
> with some (array-related?) pd-l2ork scalar examples, specifically
> doc/4.data.structures/pd-l2ork/ds-tutorials/00.under.construction.pd gives
> me this when launched (and the animation of the construction sign fails to
> work):
>
> [image: image.png]
>
> Do you have a fix for that as well? It seems that we're getting really
> close...
>
> Albert
>
>
> On Wed, Jul 1, 2020 at 4:14 AM Ivica Ico Bukvic <ico at vt.edu> wrote:
>
>> Just submitted a merge request that does 2 things:
>>
>> 1) fixes the scalar issue and
>>
>> 2) included as a separate commit in the same merge request items that
>> were for some reason omitted during the mergefest
>>
>> This should now solve most issues with the exception of the 0.47 features
>> whose status I did not explore in detail since they have not been
>> completely merged.
>>
>> The new scrollbars do work here but please note I am using 0.47.
>>
>> Best,
>>
>> Ico
>> On 6/30/2020 9:32 PM, Ivica Ico Bukvic wrote:
>>
>> Never mind, this should apply onto your branch fine. I am curious why my
>> "git checkout -b <new_branch> upstream/master" does not get me the most
>> up-to-date content from your branch. Plot thickens...
>>
>> Once I figure out this, I will send you a merge request.
>>
>> Best,
>>
>> Ico
>> On 6/30/2020 9:29 PM, Ivica Ico Bukvic wrote:
>>
>> So, I cannot issue a merge request since the main branch still has the
>> older version of gui_scalar_new that does not have the plot_style option
>> which is meant to fine-tune plot positioning (and may be tied to the 0.4x
>> nw.js). While this fixes it on my branch, I will have to dig through yours
>> to see what you may have not been merged (as is the case with the
>> previously mentioned merge) to have caused this regression.
>>
>> I really wish that we moved forward with the 0.4x transition...
>>
>> Best,
>>
>> Ico
>> On 6/30/2020 9:22 PM, Ivica Ico Bukvic wrote:
>>
>> OK, I got the fix. This was definitely my doing--in fixing the plots I
>> completely forgot that a non-plot scalar may not have a valid plot type and
>> therefore will have matrix left undefined. Below is a diff. Also, I will
>> send out a merge request shortly.
>>
>> Best,
>>
>> Ico
>>
>> index 6d85631a..1a0ea4bc 100644
>> --- a/pd/nw/pdgui.js
>> +++ b/pd/nw/pdgui.js
>> @@ -3514,7 +3514,11 @@ function gui_scalar_new(cid, tag, isselected, t1,
>> t2, t3, t4, t5, t6,
>>                      transform_string = "translate(" + 0 +
>>                          "," + (t6+1) + ") scale(" + t1 + "," + t4 + ")";
>>                      //post("transform_string = " + transform_string);
>> -                    break;
>> +                    break;
>> +                default:
>> +                    // we are a non-plot scalar
>> +                    matrix = [t1,t2,t3,t4,t5,t6];
>> +                    break;
>>              }
>>          }
>>          else {
>> @@ -3535,6 +3539,10 @@ function gui_scalar_new(cid, tag, isselected, t1,
>> t2, t3, t4, t5, t6,
>>                          "," + (t6+1.5) + ") scale(" + t1 + "," + t4 +
>> ")";
>>                      //post("transform_string = " + transform_string);
>>                      break;
>> +                default:
>> +                    // we are a non-plot scalar
>> +                    matrix = [t1,t2,t3,t4,t5,t6];
>> +                    break;
>>              }
>>          }
>>
>>
>>
>>
>> On 6/30/2020 9:13 PM, Ivica Ico Bukvic wrote:
>>
>> It appears my branch is affected, as well, so it is either something I
>> did or something that was merged from the main branch. The error is as
>> follows (on Windows, at least):
>>
>> C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542 Uncaught TypeError:
>> Cannot read property 'join' of undefined
>>     at C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542:51
>>     at get (C:\Program Files (x86)\Purr Data\bin\pdgui.js:2057:21)
>>     at Object.get_elem (C:\Program Files (x86)\Purr
>> Data\bin\pdgui.js:2073:24)
>>     at gui_scalar_new (C:\Program Files (x86)\Purr
>> Data\bin\pdgui.js:3491:14)
>>     at eval (eval at perfect_parser (C:\Program Files (x86)\Purr
>> Data\bin\pdgui.js:1885:21), <anonymous>:1:1)
>>     at perfect_parser (C:\Program Files (x86)\Purr
>> Data\bin\pdgui.js:1885:21)
>>     at Socket.<anonymous> (C:\Program Files (x86)\Purr
>> Data\bin\pdgui.js:1903:9)
>>     at Socket.emit (events.js:315)
>>     at addChunk (_stream_readable.js:302)
>>     at readableAddChunk (_stream_readable.js:278)
>>
>> Best,
>>
>> Ico
>> On 6/30/2020 8:08 PM, Ivica Bukvic wrote:
>>
>> Before we do that, allow me to take a stab at this to see what may have
>> broke. I will also test to see if my branch exhibits the same problem. What
>> about the plot drawing optimizations you introduced, could they be also
>> somehow involved? I don't have those yet on my branch and have not
>> experienced any known problems yet, although I need to test the about page.
>>
>> 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 30, 2020, 19:23 Jonathan Wilkes <jon.w.wilkes at gmail.com>
>> wrote:
>>
>>> Albert-- now that HEAD is what it is, what would the process be of
>>> rolling it back while putting all those merges
>>> into a separate nwjs-update branch?
>>>
>>> -Jonathan
>>>
>>> On Tue, Jun 30, 2020 at 5:57 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
>>> wrote:
>>> >
>>> > On Tue, Jun 30, 2020 at 3:20 PM Ivica Bukvic <ico at vt.edu> wrote:
>>> > >
>>> > > The fix that may have triggered the regression you describe was
>>> supposed to fix a regression :-)
>>> > >
>>> > > Namely the code removed that deletes data structures during a redraw
>>> also tends to delete all the other objects on a subpatch when an undo
>>> action is triggered, leaving only patch cords visible. This was true
>>> regardless of the nw.js version. I suspect that the fix that Jonathan
>>> originally introduced there may have been because of drawing of the data
>>> structures alongside the regular objects on the same canvas, which is what
>>> the about page has with the animated cat.
>>> >
>>> > Unfortunately, I can't create a scalar on a canvas at all. This is a
>>> > bug even if there are no gop subpatches in existence.
>>> >
>>> > Also-- I tried reverting the code you're referring to, Ico. Even with
>>> > that code path present, a simple scalar will fail to
>>> > be displayed. Even worse-- nothing gets created on the GUI side. So
>>> > either the problem is something you introduced to
>>> > gui_scalar_new, or in the backend preventing that from every being
>>> called.
>>> >
>>> > -Jonathan
>>> >
>>> > >
>>> > > My originally proposed merge request offered deleting only scalars
>>> in a situation that the code seemed to address. I also indicated that it
>>> needed to be tested further given I was unsure under which circumstances
>>> this code would be necessary. The final merge was Jonathan's where he
>>> erased that part entirely suggesting it was not necessary anymore.
>>> > >
>>> > > What may be helpful, as the code complexity continues to grow, is to
>>> carefully annotate each of these calls in the code so that we can better
>>> understand why they are placed there in the first place and what needs to
>>> be done to check for regressions.
>>> > >
>>> > > 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 30, 2020, 14:16 Albert Graef <aggraef at gmail.com> wrote:
>>> > >>
>>> > >> Sorry, I missed these remarks earlier.
>>> > >>
>>> > >> On Tue, Jun 30, 2020 at 2:14 PM Jonathan Wilkes <
>>> jon.w.wilkes at gmail.com> wrote:
>>> > >>>
>>> > >>> I can confirm running HEAD against a local 0.46.3 nw.js on aarch64
>>> > >>> does indeed work to load and display patches.
>>> > >>
>>> > >>
>>> > >> Have you tried  the Help - About Pd-L2ork menu entry?
>>> > >>
>>> > >>> What do I need to add to the contributor's guide to make it clear
>>> what
>>> > >>> a desirable merge request branch should look like?
>>> > >>
>>> > >>
>>> > >> I guess you're talking about workflow here? That is, rebasing and
>>> squashing commits so that you present your feature branch a.k.a. merge
>>> request as simple and comprehensible as possible, with a clean and logical
>>> commit history. There's a lot that goes into that  process and much of it
>>> is common sense -- but you'd probably have to replicate half the Git Book
>>> to explain these things really thoroughly.
>>> > >>
>>> > >> However, the main failure in this case IMHO was that there weren't
>>> enough eyeballs looking at this "patchset from hell", before the changes
>>> were merged into master. A call for help on the mailing list goes a long
>>> way there, explaining what the new set of changes is about, what parts of
>>> the program might be affected, and what needs to be tested. I did notice
>>> the flurry of commits, but I wasn't sure what they were about and didn't
>>> have the time to look into them. I would certainly have tried to give a
>>> helping hand in testing, though, when asked about it in the manner
>>> described. ;-) (Or maybe I missed that call, then I have to apologize.)
>>> > >>
>>> > >> Albert
>>> > >>
>>> > >>> > On Tue, Jun 30, 2020 at 11:42 AM Sam Thursfield <
>>> ssssam at gmail.com> wrote:
>>> > >>> >>
>>> > >>> >> Hi Albert,
>>> > >>> >>
>>> > >>> >> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef <aggraef at gmail.com>
>>> wrote:
>>> > >>> >> > The program still builds fine, launches and I can still open
>>> new patch windows (^n), but "About Pd-L2ork" doesn't work any more and I
>>> can't open existing patches either (apparently the patches do get opened in
>>> the engine, but no window is mapped).
>>> > >>> >>
>>> > >>> >> Is it possible that you are using a version of nw.js >= 0.42.3 ?
>>> > >>> >> This issue sounds a bit like
>>> > >>> >> https://git.purrdata.net/jwilkes/purr-data/-/issues/572
>>> > >>> >> Sam
>>> > >>> >> _______________________________________________
>>> > >>> >> L2Ork-dev mailing list
>>> > >>> >> L2Ork-dev at disis.music.vt.edu
>>> > >>> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>>> > >>> >
>>> > >>> >
>>> > >>> >
>>> > >>> > --
>>> > >>> > 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
>>> > >>> _______________________________________________
>>> > >>> L2Ork-dev mailing list
>>> > >>> L2Ork-dev at disis.music.vt.edu
>>> > >>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>> > >>
>>> > >>
>>> > >>
>>> > >> --
>>> > >> 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
>>> > >
>>> > > _______________________________________________
>>> > > 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
>>
>> --
>> 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-6139ico at vt.edu
>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>
>> --
>> 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-6139ico at vt.edu
>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>
>> --
>> 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-6139ico at vt.edu
>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>
>> --
>> 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-6139ico at vt.edu
>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>
>> --
>> 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-6139ico at vt.edu
>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
> --
> 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/20200701/9171f64a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 525434 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200701/9171f64a/attachment-0001.png>


More information about the L2Ork-dev mailing list