[L2Ork-dev] Current HEAD of Purr Data is broken
Ivica Bukvic
ico at vt.edu
Thu Jul 2 00:04:10 EDT 2020
If I recall correctly when I try to git push on an existing merge request I
get an error, so there has to be some kind of a flag that I'm currently
missing. To initially create a merge request I do:
git push -o merge_request.create upstream local-branch
I'll check tomorrow to see what the error in question is.
Regarding the slowdown, as far as I know this should have nothing to do
with my commits because even when I early on transitioned to the new nw
version I saw a noticeable slow down. I believe this is purely on the nw.js
side of things and something we may want to report. Perhaps earlier
versions were accelerated and newer explicitly ask for enabling of
acceleration or the acceleration is reserved only for select types of
tags/objects? The easiest way to test this is open the old Purr-Data
version, replace the nw folder with a newer version and test something like
the L2Ork Tweeter patch.
Jonathan, you may recall from our zoom conversation when I showed you how
much slower the Tweeter patch was opening with nothing else changed on the
pd side of things.
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, Jul 1, 2020, 22:05 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> On Wed, Jul 1, 2020 at 7:45 PM Albert Graef <aggraef at gmail.com> wrote:
>
>> Maybe I need to explain a bit more elaborately what the proper workflow
>> for a merge request is supposed to be:
>>
>> 1. In your own clone (or clone of your fork of the repo) you start a new
>> (feature or bugfix) branch as usual (git branch -b your-branch-name).
>>
>> 2. When you're done committing your changes, you push your branch, and go
>> to the web interface to create a merge request for your branch.
>>
>> 3. Usually people like Jonathan or me will comment there or on the
>> mailing list, and request more changes.
>>
>> 4. You then just add more commits to your existing branch and push again.
>> The added commits will instantly show up in the merge request.
>>
>> 5. Steps 3+4 are repeated until everybody's happy. :)
>>
>> 6. Jonathan might finally ask you to tidy up (i.e., rebase on the current
>> master, and/or and squash/rework the history with rebase -i). That's not
>> always necessary, but it might be a good thing to do in order to resolve
>> merge conflicts in advance, or clean up the history of the branch. However,
>> this rebase/squash business is a big topic by itself, so I won't elaborate
>> on it tonight.
>>
>> 7. CI does its thing one final time and when it comes out green, Jonathan
>> will merge your branch asap and everybody will be even happier. ;-)
>>
>> That's the recommended workflow for dealing with merge requests, no
>> matter whether you're using Gitlab, Github, Bitbucket, or any other
>> git-based source code hosting site that offers this feature. You need that
>> kind of workflow because *nobody* gets a complicated merge request right on
>> first attempt. :) This workflow keeps everyone involved (relatively) sane
>> and facilitates cooperation. Also, the merge request itself documents the
>> entire process, so that everyone coming in and looking at the MR at any
>> time can understand what's going on.
>>
>> Jonathan, this might be the kind of explanation that you were looking for
>> earlier? I have the vague feeling that I explained this on the ml before,
>> but I'm not sure.
>>
>
> Yes. But I think the issue is that Ico had been making commits straight to
> master for pd-l2ork 1.0. Going from that
> to merge requests was probably the pain point. I'm not sure most other
> devs will be coming from that dev pattern.
>
> Anyhow, I think as you've pointed out it's just as easy to make a series
> of commits to a feature branch as it is
> to master.
>
> On another note-- 0.46.3 with Ico's changes is *slow* on my slow laptop
> (about like an RPI 4). Like, unusably slow for patches that have a lot of
> objects on the toplevel.
>
> E.g., all_about_expr_functions.pd before Ico's merges (and using the older
> nw version 0.17.6): about 3 seconds
>
> Same patch after Ico's merges, using nw.js 0.46.4 on aarch64: about 23
> seconds.
>
> We can't ship a release that takes an order of magnitude longer to load
> patches. We'll need to spend some serious
> time in devTools profiling this, and getting load time back down to
> reasonable levels before releasing.
>
> One other data point-- the animations in the nw demo app (when you double
> click the nw binary) are flawless on
> my slow arm laptop.
>
> -Jonathan
>
>
>
>>
>> HTH,
>> Albert
>>
>>
>> On Thu, Jul 2, 2020 at 1:17 AM Albert Graef <aggraef at gmail.com> wrote:
>>
>>> Thanks. But why a separate merge request? Can't that single commit just
>>> be added to the existing
>>> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/403? If you
>>> just keep adding new merge requests for each and every trivial change, that
>>> makes it so much harder for others to comprehend what's going on and
>>> re-test. Just keep adding to the original branch and push to the MR until
>>> it's finished, that's the workflow that everybody uses.
>>>
>>> On Wed, Jul 1, 2020 at 7:31 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
>>>
>>>> There is now a new merge request to remove the debugging info. This
>>>> should, as far as I can tell, resolve all the issues Albert pointed out so
>>>> far. AFAICT I was unable to reproduce the problem Albert mentioned with the
>>>> 00.under.construction patch.
>>>>
>>>> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/406
>>>>
>>>> Best,
>>>>
>>>> Ico
>>>> On 7/1/2020 1:20 PM, Ivica Bukvic wrote:
>>>>
>>>> I got the debug message resolved. Will be submitting a merge request
>>>> shortly. Still working on the other one.
>>>>
>>>> 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-6139ico at vt.edu
>>>> ci.icat.vt.eduwww.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>>>
>>>>
>>>>
>>>> On Wed, Jul 1, 2020 at 12:40 AM Albert Graef <aggraef at gmail.com> wrote:
>>>>
>>>>> I'm getting those debugging messages also with vanilla array scalars:
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> That might just be some leftover debugging message. At least this
>>>>> example seems to work properly.
>>>>>
>>>>>
>>>>> On Wed, Jul 1, 2020 at 6: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/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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-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/
>>>
>>
>>
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200702/e504b0bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 448533 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200702/e504b0bb/attachment-0002.png>
-------------- 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/20200702/e504b0bb/attachment-0003.png>
More information about the L2Ork-dev
mailing list