[L2Ork-dev] Linux dependencies in README.md build guide

Ivica Bukvic ico at vt.edu
Sat Oct 10 10:32:27 EDT 2020 

So, I just checked the disis_wiimote on Linux Ubuntu 20.04 with a freshly
built snapshot of the HEAD prior to the reverting of !579 and the
disis_wiimote works as advertised. Please note it is designed to work only
with genuine Wiimotes. Other knock off devices are not guaranteed to work
and may or may not work. I don't believe anyone has yet successfully
reverse-engineered the wireless nunchucks.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Director, Human-Centered Design iPhD
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.eduhcd.icat.vt.eduwww.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Fri, Oct 9, 2020 at 2:35 PM Ivica Bukvic <ico at vt.edu> wrote:

> Let me investigate first Albert's report and then I will propose the next
> steps. AFAIR libcwiid is Linux/OSX only. Last time I dabbled with the
> Windows BT stack I concluded it was worse than OSX's (at least at that
> point in time).
>
> 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 Fri, Oct 9, 2020, 14:00 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
>> > I think that it's the way to go if disis_wiimote is ever going to be
>> rewritten.
>>
>> What about Windows support? I believe that external was written at a
>> time when Pd-l2ork only ran under Linux. Is it even possible to
>> support the same interface with whatever carnival of bluetooth animals
>> Windows has on offer?
>>
>> Or, if we want to just restrict it to Linux, I'm happy to help get
>> this ported if Albert is familiar with the relevant API to use.
>>
>> -Jonathan
>>
>> On Fri, Oct 9, 2020 at 1:56 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
>> wrote:
>> >
>> > On Fri, Oct 9, 2020 at 1:54 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
>> wrote:
>> > >
>> > > On Fri, Oct 9, 2020 at 1:39 PM Albert Graef <aggraef at gmail.com>
>> wrote:
>> > > >
>> > > > No, make just invokes tar_em_up.sh, which then on Debian-based
>> systems invokes dpkg-deb (using the packages/linux_make/debian/control
>> file). The debuild stuff is completely separate and requires some
>> additional tools to be installed (debuild et al). There are some (rather
>> terse) instructions in debuild/Makefile, which probably won't make much
>> sense unless you've used debuild before (or read the Ubuntu packaging
>> guide).
>> > > >
>> > > > So the quick and dirty solution is to just fix the dependencies in
>> the packages/linux_make/debian/control file. I see that there's a Depends:
>> python line in there, maybe change that to something that will work on
>> 20.04, such as Depends: python2. (That Depends: line *must* be there,
>> however, because it will be replaced during the build, adding the remaining
>> runtime dependencies which are figured out automagically in
>> linux_make/Makefile. You ought to know this, because according to git blame
>> you wrote that part of the Makefile yourself in 2017. ;-)
>> > >
>> > > I wholeheartedly admit I no longer understand the build system. :)
>> > >
>> > > I don't want two sources of truth for Debian dependencies. If a deb is
>> > > to be built I want to use whatever system you are using with the
>> > > dependency graph you've specified and tested. Otherwise I'll be
>> > > hooking up new runners with an alternate, craggy build process, and
>> > > users *will* magnetically become attracted to these nonstandard builds
>> > > and complain about the crags on the list. (Not to mention the fact
>> > > that I'm running test regressions on a different final product than
>> > > you're releasing.)
>> > >
>> > > Is there a way we can hard-code `make` on debian to use your debbuild
>> > > by default?
>> >
>> > Well, by hard-coded I mean: when the user does `make` and the build
>> > system has decided it's going to build a deb, then it should *only* do
>> > so using your debbuild process. Otherwise you get problems like what
>> > we have currently where both Ico and I are reporting "bugs" that are
>> > actually solved in a different directory of the repo.
>> >
>> > -Jonathan
>> >
>> > > I don't care what extra tools are needed-- if users want
>> > > to build a deb it should be *exactly* the same process as what we use
>> > > to release.
>> > >
>> > > -Jonathan
>> > >
>> > > >
>> > > > Albert
>> > > >
>> > > >
>> > > > On Fri, Oct 9, 2020 at 7:07 PM Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> > > >>
>> > > >> I built using `make` in the main repository directory. Doesn't that
>> > > >> leverage your control file from the debbuild directory?
>> > > >>
>> > > >> -Jonathan
>> > > >>
>> > > >> On Fri, Oct 9, 2020 at 12:28 PM Albert Graef <aggraef at gmail.com>
>> wrote:
>> > > >> >
>> > > >> > On Fri, Oct 9, 2020 at 5:24 PM Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> > > >> >>
>> > > >> >> But your control file has "python" under the "Suggests" heading.
>> > > >> >>
>> > > >> >> Does "Suggests" have an alternate meaning in the Debianese
>> dialect of Vogon? :)
>> > > >> >
>> > > >> >
>> > > >> > I don't think so. The dh-python dependency is a much more likely
>> candidate, but that's a build dependency. But it's hard to say what the
>> cause of the issue is without at least having a copy of the control file
>> that you used. Better yet, send me the entire .deb you built in private
>> mail so that I can have a look.
>> > > >> >
>> > > >> > Yeah, Debian packaging is a real nightmare. I have no doubts
>> that it was actually invented by the Vogons. ;-) And it doesn't help that I
>> have little to no experience with those low-level tools like dpkg-deb. I
>> always use debuild instead.
>> > > >> >
>> > > >> > Albert
>> > > >> >
>> > > >> >
>> > > >> >>
>> > > >> >> -Jonathan
>> > > >> >>
>> > > >> >> On Fri, Oct 9, 2020 at 8:17 AM Ivica Bukvic <ico at vt.edu> wrote:
>> > > >> >> >
>> > > >> >> > Aaand, yet another reply. The python and gtk are needed for
>> wmgui (or something like it) which is a front-end demo app, so it seems to
>> me we would want to remove those as well if we are going to strip the
>> python requirement.
>> > > >> >> >
>> > > >> >> > --
>> > > >> >> > Ivica Ico Bukvic, D.M.A.
>> > > >> >> > Director, Creativity + Innovation
>> > > >> >> > Director, Human-Centered Design iPhD
>> > > >> >> > 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
>> > > >> >> > hcd.icat.vt.edu
>> > > >> >> > www.icat.vt.edu
>> > > >> >> > www.performingarts.vt.edu
>> > > >> >> > l2ork.icat.vt.edu
>> > > >> >> > ico.bukvic.net
>> > > >> >> >
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > On Fri, Oct 9, 2020 at 8:12 AM Ivica Bukvic <ico at vt.edu>
>> wrote:
>> > > >> >> >>
>> > > >> >> >> Forgot to add, since libcwiid we use is in-house, we could
>> potentially consider removing the python requirement from it. I am,
>> however, really rusty as far as makefiles are concerned and could use help
>> with this one, should anyone feel inclined to assist. Not sure if purr-data
>> is pulling from my github libcwiid repo or maintaining a local copy.
>> > > >> >> >>
>> > > >> >> >> Best,
>> > > >> >> >>
>> > > >> >> >> Ico
>> > > >> >> >>
>> > > >> >> >> --
>> > > >> >> >> Ivica Ico Bukvic, D.M.A.
>> > > >> >> >> Director, Creativity + Innovation
>> > > >> >> >> Director, Human-Centered Design iPhD
>> > > >> >> >> 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
>> > > >> >> >> hcd.icat.vt.edu
>> > > >> >> >> www.icat.vt.edu
>> > > >> >> >> www.performingarts.vt.edu
>> > > >> >> >> l2ork.icat.vt.edu
>> > > >> >> >> ico.bukvic.net
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >> On Fri, Oct 9, 2020 at 8:10 AM Ivica Bukvic <ico at vt.edu>
>> wrote:
>> > > >> >> >>>
>> > > >> >> >>> I haven't tested the recent Bluez 5 version. If you are
>> using newer wiimoteplus that has motion plus integrated, you will want to
>> connect with the sync button found next to the battery. I haven't tested
>> the xwiimote driver, but not so long ago, the in-house libcwiid I
>> maintained was the only driver that allowed for complete access to
>> Wiimote's functionality, including the interleaved mode that uses both plus
>> and nunchuk. It is also rock solid. To this day, we still use it in L2Ork
>> and have tested it with 24 simultaneous Wiimote connections in the same
>> room without any issues.
>> > > >> >> >>>
>> > > >> >> >>> I just upgraded my Linux laptop to Ubuntu 20.04 and am
>> happy to test all this. However, I am unable to even build the latest HEAD.
>> Below are relevant errors:
>> > > >> >> >>>
>> > > >> >> >>> gcc -g -Wall -W -DHAVE_CONFIG_H
>> -I/home/l2orkist/Downloads/purr-data-build/externals/disis/cwiid/common/include
>> -I../libcwiid
>> -DWMINPUT_CONFIG_DIR=\"/home/l2orkist/Downloads/purr-data-build/packages/linux_make/build/usr/etc/cwiid/wminput\"
>> -DCWIID_PLUGINS_DIR=\"/home/l2orkist/Downloads/purr-data-build/packages/linux_make/build/usr/lib/cwiid/plugins\"
>>   -c -o py_plugin.o py_plugin.c
>> > > >> >> >>> Package python-2.7 was not found in the pkg-config search
>> path.
>> > > >> >> >>> Perhaps you should add the directory containing
>> `python-2.7.pc'
>> > > >> >> >>> to the PKG_CONFIG_PATH environment variable
>> > > >> >> >>> No package 'python-2.7' found
>> > > >> >> >>> py_plugin.c:38:10: fatal error: Python.h: No such file or
>> directory
>> > > >> >> >>>    38 | #include "Python.h"
>> > > >> >> >>>       |          ^~~~~~~~~~
>> > > >> >> >>> compilation terminated.
>> > > >> >> >>>
>> > > >> >> >>> In trying to install dependencies from the installation
>> guide, I get:
>> > > >> >> >>>
>> > > >> >> >>> sudo apt-get install bison flex automake libasound2-dev \
>> > > >> >> >>> >       libjack-jackd2-dev libtool libbluetooth-dev
>> libgl1-mesa-dev \
>> > > >> >> >>> >       libglu1-mesa-dev libglew-dev libmagick++-dev
>> libftgl-dev \
>> > > >> >> >>> >       libgmerlin-dev libgmerlin-avdec-dev
>> libavifile-0.7-dev \
>> > > >> >> >>> >       libmpeg3-dev libquicktime-dev libv4l-dev
>> libraw1394-dev \
>> > > >> >> >>> >       libdc1394-22-dev libfftw3-dev libvorbis-dev
>> ladspa-sdk \
>> > > >> >> >>> >       dssi-dev tap-plugins invada-studio-plugins-ladspa
>> blepvco \
>> > > >> >> >>> >       swh-plugins mcp-plugins cmt blop slv2-jack omins
>> rev-plugins \
>> > > >> >> >>> >       libslv2-dev dssi-utils vco-plugins wah-plugins
>> fil-plugins \
>> > > >> >> >>> >       mda-lv2 libmp3lame-dev libspeex-dev libgsl0-dev \
>> > > >> >> >>> >       portaudio19-dev liblua5.3-dev python-dev libsmpeg0
>> libjpeg62-turbo \
>> > > >> >> >>> >       flite1-dev libgsm1-dev libgtk2.0-dev git
>> libstk0-dev \
>> > > >> >> >>> >       libfluidsynth-dev fluid-soundfont-gm byacc
>> > > >> >> >>> E: Package 'slv2-jack' has no installation candidate
>> > > >> >> >>> E: Package 'libjpeg62-turbo' has no installation candidate
>> > > >> >> >>>
>> > > >> >> >>> Any thoughts on how to proceed?
>> > > >> >> >>>
>> > > >> >> >>> Best,
>> > > >> >> >>>
>> > > >> >> >>> Ico
>> > > >> >> >>>
>> > > >> >> >>> --
>> > > >> >> >>> Ivica Ico Bukvic, D.M.A.
>> > > >> >> >>> Director, Creativity + Innovation
>> > > >> >> >>> Director, Human-Centered Design iPhD
>> > > >> >> >>> 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
>> > > >> >> >>> hcd.icat.vt.edu
>> > > >> >> >>> www.icat.vt.edu
>> > > >> >> >>> www.performingarts.vt.edu
>> > > >> >> >>> l2ork.icat.vt.edu
>> > > >> >> >>> ico.bukvic.net
>> > > >> >> >>>
>> > > >> >> >>>
>> > > >> >> >>>
>> > > >> >> >>> On Fri, Oct 9, 2020 at 12:15 AM Albert Graef <
>> aggraef at gmail.com> wrote:
>> > > >> >> >>>>
>> > > >> >> >>>> Thanks, Ico.
>> > > >> >> >>>>
>> > > >> >> >>>> Yes, it seems that cwiid is the one which needs it.
>> Looking at the source code in externals/disis/cwiid, there's a configure
>> script there which checks for Python, and a septup.py script that gets run
>> during the build. There's no actual Python C API code being linked there,
>> as far as I can tell. But from unsuccessful OBS builds I know that it will
>> fail with an error when running configure and Python is not installed, and
>> I also seem to recall that Python3 didn't work either, it really needs
>> Python2 for some reason. Unfortunately, the OBS doesn't keep logs of older
>> builds, so all this is from the top of my head, but that's how I remember
>> it.
>> > > >> >> >>>>
>> > > >> >> >>>> Talking about this external, can anyone running a
>> *current* Linux system (Arch or Ubuntu 20.04+) with a recent Bluez 5
>> version confirm that disis_wiimote still works there? I'm asking because I
>> could never make it work, it just doesn't find my Wiimote (which works fine
>> with the xwiimote kernel driver). If I'm not mistaken, disis_wiimote still
>> employs some user space drivers and utilities which aren't supported in
>> Bluez 5 any more. But if anyone has it actually working on Bluez 5 then I'd
>> really like to hear about it!
>> > > >> >> >>>>
>> > > >> >> >>>> Thanks,
>> > > >> >> >>>> Albert
>> > > >> >> >>>>
>> > > >> >> >>>>
>> > > >> >> >>>> On Fri, Oct 9, 2020 at 4:51 AM Ivica Bukvic <ico at vt.edu>
>> wrote:
>> > > >> >> >>>>>
>> > > >> >> >>>>> I believe that is/was for pyext which requires flext. I
>> thought we were not building flext externals anymore? There may be also a
>> requirement for building the libcwiid since it has some gtk and/or python
>> demo apps that get built with it and which we do not need.
>> > > >> >> >>>>>
>> > > >> >> >>>>> 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 Thu, Oct 8, 2020, 18:26 Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> > > >> >> >>>>>>
>> > > >> >> >>>>>> Also-- bullseye (testing) no longer has a "python"
>> package, just
>> > > >> >> >>>>>> python2 and python3.
>> > > >> >> >>>>>>
>> > > >> >> >>>>>> So if we can just get rid of the python dependency
>> altogether that
>> > > >> >> >>>>>> would be ideal. (Unless this is some kind of pdpython
>> external...)
>> > > >> >> >>>>>>
>> > > >> >> >>>>>> -Jonathan
>> > > >> >> >>>>>>
>> > > >> >> >>>>>> On Thu, Oct 8, 2020 at 6:16 PM Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > On Thu, Oct 8, 2020 at 5:55 PM Albert Graef <
>> aggraef at gmail.com> wrote:
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > > On Thu, Oct 8, 2020 at 11:12 PM Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> > > >> >> >>>>>> > >>
>> > > >> >> >>>>>> > >> 1. Why are slv2-jack and libslv2-dev build
>> dependencies of Purr Data?
>> > > >> >> >>>>>> > >> What does LV2 support in Jack have to do with Purr
>> Data?
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > > I assume that you're talking about the Debian
>> packaging stuff in purr-data/packages/linux_make/debian, which is probably
>> severely outdated (those slv2 deps certainly are). Maybe you want to have a
>> look at my debuild control file (purr-data/debuild/debian/control) and
>> update the control file in linux_make/debian accordingly. The debuild stuff
>> is always up-to-date and known to work with every Debian/Ubuntu version
>> younger than Stretch and Xenial, because I'm using it to build packages on
>> the OBS.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > Ah, I see. Hm, rather than the old hard-coded deps I
>> should just put a
>> > > >> >> >>>>>> > line to fetch those deps from that file.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > >> 2. What is python-dev doing in there? If it is
>> actually needed, is the
>> > > >> >> >>>>>> > >> dependency on Python 2 or Python 3?
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > > That's needed to build one of the DISIS externals, I
>> forgot which one it was, but Ico should know. And yes, that's really the
>> Python2 version that it needs, which causes quite some headaches if you
>> want to build Purr on both old and new Debian/Ubuntu versions. But you can
>> have a look at purr-data/debuild/debian/control to see how I solved this in
>> the OBS builds. It would be good if we could just get rid of that Python2
>> dependency, since Python2 is pretty much on its way out.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > Ok, my list vs. your "Build-Depends":
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 1. I've got libjack-jackd2-dev while you have
>> libjack-dev. Any benefit
>> > > >> >> >>>>>> > to one or the other?
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 2. I've got libglu1-mesa-dev while you do not. Any
>> reason I still need that one?
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 3. I have libgmerlin-avdec-dev while you do not. But
>> we both have
>> > > >> >> >>>>>> > libgmerlin-avdec-dev.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 4. I have dssi-dev while you do not. But you have
>> dssi-utils under "Depends"
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 5. As mentioned I have slv2-jack and libslv2-dev, you
>> don't.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 6. I have libgsl0-dev, you have libgsl-dev
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 7. I have portaudio19-dev, you don't.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 8. I have libsmpeg0, you don't.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 9. I have libjpeg62-turbo, you have libjpeg-dev.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 10. I have git, you don't
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > 11. I have byacc, you don't.
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > Hm... wonder why we have libgtk2.0-dev-- was that
>> added for nw.js?
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > -Jonathan
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> >
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > > Albert
>> > > >> >> >>>>>> > >
>> > > >> >> >>>>>> > >>
>> > > >> >> >>>>>> > >> -Jonathan
>> > > >> >> >>>>>> > >> _______________________________________________
>> > > >> >> >>>>>> > >> 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
>> > > >> >> >>>>
>> > > >> >> >>>>
>> > > >> >> >>>>
>> > > >> >> >>>> --
>> > > >> >> >>>> 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
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201010/ff3d6313/attachment-0001.html>

More information about the L2Ork-dev mailing list