[L2Ork-dev] Linux dependencies in README.md build guide
Albert Graef
aggraef at gmail.com
Sat Oct 10 12:28:36 EDT 2020
Thanks for checking it out, that's good to know!
Yes, I have a real Wiimote. It might be that Arch/Manjaro just lacks some
bits and pieces in the Bluez stack to make the external work there, though.
But I'll give it a go on Ubuntu 20.04 as soon as I find the time.
Thanks,
Albert
On Sat, Oct 10, 2020 at 4:32 PM Ivica Bukvic <ico at vt.edu> wrote:
> 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
>>
>> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201010/5d7ff86c/attachment-0001.html>
More information about the L2Ork-dev
mailing list