From willgodfrey at musically.me.uk Thu Aug 4 16:05:06 2022 From: willgodfrey at musically.me.uk (Will Godfrey) Date: Thu, 4 Aug 2022 15:05:06 +0100 Subject: [LAD] gitlab Message-ID: <20220804150506.6eaec903@devuan> If any of you have a project hosted there, this might be of interest ... or a warning :( https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/ -- Will J Godfrey {apparently now an 'elderly'} https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. From brummer- at web.de Sat Aug 6 18:55:27 2022 From: brummer- at web.de (Hermann Meyer) Date: Sat, 6 Aug 2022 18:55:27 +0200 Subject: [LAD] XUiDesigner v0.4 released In-Reply-To: <6547f9b7-aa9e-6524-4913-88d484504888@web.de> References: <6547f9b7-aa9e-6524-4913-88d484504888@web.de> Message-ID: <6ff69956-f914-ce69-751f-e3f654d8ee41@web.de> Am 07.07.22 um 13:25 schrieb Hermann Meyer: > > I'm pleased to announce the release v0.4 of XUiDesigner > > A easy to use GUI generator/designer tool to create X11 based UI's for > LV2 plugins. > > Inspired by Glade and QT Designer > > XUiDesigner allow to generate alternative UI's for existing LV2 > plugins which could be installed and used parallel to the existing ones. > > It allow as well to create full LV2 plugin bundles from scratch, were > only the dsp part needs to be done. > > With this version, it allow to generate LV2 plugin bundles from faust > (*.dsp) files. Those could be simply drop on the XUiDesigner interface > and XUiDesigner will create the UI for it. The UI could be reworked > when needed (reorder the controls, implement colours or images, . . .) > . Then the complete Bundle could be saved. All what needs to be done > then is run |make && make install| on the bundle, to get the LV2 plug > into the preferred LV2 host. > > Still this is in the beta stage, so there may be come changes which > are not backward compatible, but the generated LV2 bundles are all > fully working. > > > Project page: > > https://github.com/brummer10/XUiDesigner > > release: > > https://github.com/brummer10/XUiDesigner/releases/download/v0.4/XUIDesigner_0.4.tar.gz > > regards > > hermann > > I've added a wiki page as starting point to explain the workflow of XUiDesigner: https://github.com/brummer10/XUiDesigner/wiki/XUiDesigner -------------- next part -------------- An HTML attachment was scrubbed... URL: From brummer- at web.de Mon Aug 8 19:20:57 2022 From: brummer- at web.de (Hermann Meyer) Date: Mon, 8 Aug 2022 19:20:57 +0200 Subject: [LAD] XUiDesigner v0.5 released Message-ID: Release early and often. Special when you've a new tool. So here we go. XUiDesigner v0.5 is released. A easy to use tool to generator/design X11 based LV2 plugins. Beside that XUiDesigner allow to generate and install GUI's for existing LV2 plugins, it support as well to generate LV2 plugins from scratch. Special support is implemented for FAUST dsp files, which allow you to generate a LV2 plugin with X11 based UI by just drag'n'drop a FAUST dsp file into the XUiDesigner interface. In any way, you don't need to interference with any of the annoying LV2 implementations. XUiDesigner handle that all for you. The very same is true when you like to implement your own dsp (C or C++) into a LV2 plugin. You could create the GUI interface, save the plugin bundle, and implement the needed calls to init, activate and run your dsp into the generated .cpp file. (Yes, the points were to do what been hinted in the file, not that you are really need that) Here is a introduction Wiki entry to show the first steps: https://github.com/brummer10/XUiDesigner/wiki/XUiDesigner Here is the project page: https://github.com/brummer10/XUiDesigner and the latest release is here: https://github.com/brummer10/XUiDesigner/releases/tag/v0.5 As usual. feedback, bug reports or feature requests been welcome on: https://github.com/brummer10/XUiDesigner/issues regards hermann From fons at linuxaudio.org Mon Aug 15 14:30:02 2022 From: fons at linuxaudio.org (Fons Adriaensen) Date: Mon, 15 Aug 2022 14:30:02 +0200 Subject: [LAD] installing python extensions Message-ID: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> Hello all, I have some mixed python/C++ packages, e.g. zita-audiotools and zita-jacktools. To install these I expect the following to happen: 1. The C++ parts are compiled and combined into a *.so file which is a python extension. 2. The *.so and the python parts, any data etc. get installed into the user's /usr/lib/python*.*/site-packages. To make this as easy as possible I provide a setup.py and a Makefile, so that all that should be required is: make; sudo make install Originally this used distutils, when that got 'deprecated' this changed to setuptools. So until recently the Makefile was something like: ---- PY = /usr/bin/python3 build: $(PY) ./setup.py build install: $(PY) ./setup.py install clean: $(PY) ./setup.py clean rm -rf build dist zita_jacktools.egg-info --- Then I got warnings telling me that calling setup.py directly is now also deprecated, and that I should use 'official tools' to build and install. What exactly that means I was unable to find out, but the following seems to work: ---- PY = /usr/bin/python3 build: $(PY) -m build -w install: pip install --force-reinstall dist/*.whl clean: rm -rf build dist *.egg-info *~ ---- But this still produces a warning: > WARNING: Running pip as the 'root' user can result in broken > permissions and conflicting behaviour with the system package > manager. It is recommended to use a virtual environment instead. Now clearly installing things in site-packages requires root, so what is then the recommended method ?? And why the virtual environment (which is used by build anyway) ?? If anyone can shed some light on this mess he/she will deserve my eternal gratitude. Ciao, -- FA From chris at chrisarndt.de Mon Aug 15 16:19:37 2022 From: chris at chrisarndt.de (Christopher Arndt) Date: Mon, 15 Aug 2022 16:19:37 +0200 Subject: [LAD] installing python extensions In-Reply-To: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> Message-ID: <3fd1fd0a-6e09-e17b-9bf8-bbc77f195dce@chrisarndt.de> Am 15.08.22 um 14:30 schrieb Fons Adriaensen: > I have some mixed python/C++ packages, e.g. zita-audiotools > and zita-jacktools. > > To install these I expect the following to happen: > > 1. The C++ parts are compiled and combined into a *.so > file which is a python extension. > 2. The *.so and the python parts, any data etc. get > installed into the user's /usr/lib/python*.*/site-packages. The way to install a python package nowadays should be via a wheel package (unless installed via a (Linux) distro package). These wheel files are basically Zip archives with some additional meta-data and can contain compiled Python extensions (which makes them Python version, OS and architecture-dependent, of course). The advantages of using wheels are: - no code from the package is executed at installation time (e.-g. setup.py etc.) - users can choose to install system-wide, under ~/.local or into a virtual environment. - installation is generally faster and wheels can be cached for speedup of repeated installations (e.g. in a development or CI environment). > Originally this used distutils, when that got 'deprecated' > this changed to setuptools. [...] > Then I got warnings telling me that calling setup.py directly > is now also deprecated, and that I should use 'official tools' > to build and install. What exactly that means I was unable to > find out, but the following seems to work: This guide explains the up-to-date process to define a package, at least for pure Python packages: https://packaging.python.org/en/latest/tutorials/packaging-projects/ If you have Python extension, you need to look into the documentation of your chosen build backend (e.g. poetry, flit, etc.). In short, you write a pyproject.toml file, in which you define which build backend to use and then, depending on that backend, you either define the package meta data and build instructions also in that file or (if you still want to use setuptools as a build backend) in a pair of setup.py / setup.cfg files. The goal is to have as little actual python code in setup.py as possible and define all static meta data elsewhere. >> WARNING: Running pip as the 'root' user can result in broken >> permissions and conflicting behaviour with the system package >> manager. It is recommended to use a virtual environment instead. What this basically says is that you shouldn't normally mess with the system-wide Python packages in /usr/lib/pythonX.Y/site-packages, because this is used by the Python packages installed via the distribution packaging system. Programs installed also via distro packages may rely on packages installed there and specific versions of them. If you install a Python package via pip as root into this location, pip will resolve dependencies, which may result in some existing packages being upgraded to newer versions. As the warning says , this may cause conflicts (or subtly break things). > Now clearly installing things in site-packages requires root, > so what is then the recommended method ?? And why the virtual > environment (which is used by build anyway) ?? IMO you should distinguish between these scenarios: a) A program depends on, say, zita-xyz and is installed via a distro package. It should depend on the respective distro-package for zita-xyz. This installs into /usr/lib/pythonX.Y/site-packages. You can let the distro packages worry about the pip warning, you just provide the correct pyproject.toml and other build files. b) A program depends on zita-xyz and is installed via pip. Then it should define this dependency in pyproject.toml and pip will take care of installing zita-xyz. The user running pip can decide whether to install the program system-wide (not recommended), under ~/.local or into a virtual environment (e.g. using pipx [1]). zita-xyz will be installed in the same location. If both are installed in a dedicated virtual environment, it ensures that there are no conflicts with other programs, possibly depending on a different version of zita-xyz. c) A developer (or "power-user") uses zita-xyz for the implementation of a program or some utility scripts. He/she uses pip to install zita-xyz (and its dependencies, if any). If he/she want zita-xyz to be importable from any Python interpreter with a matching version started *by that user*, he installs it with the --user option into ~/.local. If he/she wants to make sure that a certain program always has access to and uses a certain zita-xyz version it depends on, he/she installs it into dedicated virtual environment for that (collection) of program(s) and always starts the program (or the Python interpreter) from the bin directory of that virtual env. There are several ways to facilitate / automate the latter, e.g. via poetry [2], which I have mostly good experiences with. And oh, btw, any virtual environment created by the build process is ephemeral and not relevant to the actual installation. One last thing: extension packages come with the additional difficulty that they either need to be compiled on installation by the user (then requiring the presence of needed headers etc.) or somebody (e.g. the project maintainer) needs to provide a host of Python version/OS/architecture-dependent variants of wheel packages. For Windows and macOS this is relatively easy via CI environments like Gitlab CI oder Github actions. But for Linux, for these binary wheels to be compatible with a wide variety of Linux distributions, special care needs to be taken. For more information, for example, look at [3]. Hth, Chris [1] https://pypi.org/project/pipx/ [2] https://pypi.org/project/poetry/ [3] https://github.com/pypa/cibuildwheel From marc at hacklava.net Mon Aug 15 16:54:06 2022 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Mon, 15 Aug 2022 10:54:06 -0400 Subject: [LAD] installing python extensions In-Reply-To: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> Message-ID: Hi Fons, Christopher Arndt sent a long and detailed answer, here's a shorter one. Python packages can be installed in user's home or virtual environments. For example, to install the zita tools in my home environment, I cd to the zita-audiotools-1.3.0 directory, then used: pip install . Installation was successful, so I used the same method for zita-jacktools. It includes the .so modules: ls $HOME/.local/lib/python3.*/site-packages/zita_*tools/ For completion I uninstalled the packages in my home: pip uninstall zita-audiotools zita-jacktools Then I deleted the makefiles and reinstalled the packages (using same method). I also reinstalled them globally using: sudo pip install . It worked too: ls /usr/local/lib/python3.*/dist-packages/zita_*tools/* There's newer configuration methods, but for now there's no need to update your packages, apart from removing the makefiles (and update the documentation). Marc Le 2022-08-15 à 08 h 30, Fons Adriaensen a écrit : > Hello all, > > I have some mixed python/C++ packages, e.g. zita-audiotools > and zita-jacktools. > > To install these I expect the following to happen: > > 1. The C++ parts are compiled and combined into a *.so > file which is a python extension. > 2. The *.so and the python parts, any data etc. get > installed into the user's /usr/lib/python*.*/site-packages. > > To make this as easy as possible I provide a setup.py and a > Makefile, so that all that should be required is: > > make; sudo make install > > Originally this used distutils, when that got 'deprecated' > this changed to setuptools. So until recently the Makefile > was something like: > > ---- > PY = /usr/bin/python3 > > build: > $(PY) ./setup.py build > > install: > $(PY) ./setup.py install > > clean: > $(PY) ./setup.py clean > rm -rf build dist zita_jacktools.egg-info > --- > > Then I got warnings telling me that calling setup.py directly > is now also deprecated, and that I should use 'official tools' > to build and install. What exactly that means I was unable to > find out, but the following seems to work: > > ---- > PY = /usr/bin/python3 > > build: > $(PY) -m build -w > > install: > pip install --force-reinstall dist/*.whl > > clean: > rm -rf build dist *.egg-info *~ > ---- > > But this still produces a warning: > >> WARNING: Running pip as the 'root' user can result in broken >> permissions and conflicting behaviour with the system package >> manager. It is recommended to use a virtual environment instead. > Now clearly installing things in site-packages requires root, > so what is then the recommended method ?? And why the virtual > environment (which is used by build anyway) ?? > > If anyone can shed some light on this mess he/she will deserve > my eternal gratitude. > > Ciao, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at hacklava.net Mon Aug 15 17:18:06 2022 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Mon, 15 Aug 2022 11:18:06 -0400 Subject: [LAD] installing python extensions In-Reply-To: References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> Message-ID: <1d90cac8-bd28-6c50-909d-08ee0b6e470b@hacklava.net> Le 2022-08-15 à 10 h 54, I wrote : > Python packages can be installed in user's home or virtual environments. > For example, to install the zita tools in my home environment, I cd to > the zita-audiotools-1.3.0 directory, then used: > pip install . It's also possible to install the packages using their download urls: pip install https://kokkinizita.linuxaudio.org/linuxaudio/downloads/zita-audiotools-1.3.0.tar.bz2 pip install https://kokkinizita.linuxaudio.org/linuxaudio/downloads/zita-jacktools-1.6.0.tar.bz2 ls $HOME/.local/lib/python3.*/site-packages/zita_*tools/ Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From fons at linuxaudio.org Mon Aug 15 21:21:54 2022 From: fons at linuxaudio.org (Fons Adriaensen) Date: Mon, 15 Aug 2022 21:21:54 +0200 Subject: [LAD] installing python extensions In-Reply-To: References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> Message-ID: <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> On Mon, Aug 15, 2022 at 10:54:06AM -0400, Marc Lavallée wrote: > Christopher Arndt sent a long and detailed answer, here's a shorter one. One (metric) unit of Eternal Gratitude to both of you. So > pip install . will install to ~/.local/lib while > sudo pip install . will install to /usr/local/lib I find the destination directory depending on who the user pretends to be a bit strange, but it works ! Also tested this with a package that includes data files (*.npy) that should be found by the installed code, and also this works. The only minor problem is that the sudo version leaves two directories (build and *.egg-info) that can only be cleaned up by root. No problem on systems that allow sudo everything, but I may keep the Makefile just to offer 'sudo make clean', assuming most system will allow this. Unless there is a cleaner solution. Ciao -- FA From chris at chrisarndt.de Mon Aug 15 22:15:56 2022 From: chris at chrisarndt.de (Christopher Arndt) Date: Mon, 15 Aug 2022 22:15:56 +0200 Subject: [LAD] installing python extensions In-Reply-To: <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> Message-ID: Am 15.08.22 um 21:21 schrieb Fons Adriaensen: > I find the destination directory depending on who the user pretends > to be a bit strange, but it works ! "pip install" as a normal user used to fail with an (apparently for most users) incomprehensible error message about not being able to write to the system-wide site-packages (doh!) and you needed the --user option to install into ~/.local/lib. That changed a while ago, so it automatically assumes --user, if not run as root and not told otherwise. I'm on the fence about whether I agree with this change or not. > Unless there is a cleaner solution. $ python setup.py build $ sudo python setup.py install --skip-build (not sure about the appropriate options for other build backends) "install" implies build (and build_ext, if necessary) unless you tell it otherwise, and that step creates the .egg-info dir. Chris From marc at hacklava.net Mon Aug 15 23:14:17 2022 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Mon, 15 Aug 2022 17:14:17 -0400 Subject: [LAD] installing python extensions In-Reply-To: <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> Message-ID: <6e609eef-ca5e-1f76-3bf2-aed05420f2b7@hacklava.net> Le 2022-08-15 à 15 h 21, Fons Adriaensen a écrit : > One (metric) unit of Eternal Gratitude to both of you. One unit of "Fons Gratitude" is already a lot, but thanks (infinity / 2) times! > So >> pip install . > will install to ~/.local/lib And when a virtualenv is activated, packages are installed in the ./lib sub-directory of the virtualenv directory. > while >> sudo pip install . > will install to /usr/local/lib > > I find the destination directory depending on who the user pretends > to be a bit strange, but it works ! When installing with the root user, the default prefix is /usr/local because /usr is usually managed by the system. But it's possible to install in /root/.local/lib, using: sudo pip install --user . Or as the root user, to install to your home directory, try: sudo su - fons pip install . The --user option is (now) the default, except when installing as root. > The only minor problem is that the sudo version leaves two > directories (build and *.egg-info) that can only be cleaned up > by root. No problem on systems that allow sudo everything, but > I may keep the Makefile just to offer 'sudo make clean', > assuming most system will allow this. Unless there is a > cleaner solution. That could be something simple like: PY = env python3 PIP = env pip3 build:     $(PIP) wheel . install:     $(PIP) install --force-reinstall *.whl uninstall:     $(PIP) uninstall zita-audiotools clean:     rm -rf build *.egg-info *.whl Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisarndt.de Mon Aug 15 23:33:35 2022 From: chris at chrisarndt.de (Christopher Arndt) Date: Mon, 15 Aug 2022 23:33:35 +0200 Subject: [LAD] installing python extensions In-Reply-To: <6e609eef-ca5e-1f76-3bf2-aed05420f2b7@hacklava.net> References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> <6e609eef-ca5e-1f76-3bf2-aed05420f2b7@hacklava.net> Message-ID: Am 15.08.22 um 23:14 schrieb Marc Lavallée: > Le 2022-08-15 à 15 h 21, Fons Adriaensen a écrit : >>> sudo pip install . >> will install to /usr/local/lib >> > When installing with the root user, the default prefix is /usr/local > because /usr is usually managed by the system. Actually, it will install to sys.prefix, which is usually /usr, if the Python version used to run pip is installed via a distro package. BTW, the recommended way to run pip is actually python -m pip because then you can control (via PATH or the command name you use) which Python interpreter is used. Chris From marc at hacklava.net Mon Aug 15 23:48:34 2022 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Mon, 15 Aug 2022 17:48:34 -0400 Subject: [LAD] installing python extensions In-Reply-To: References: <20220815123001.ihjqja4x5s6kupij@mail1.linuxaudio.cyso.net> <20220815192154.jiowehnceoejvrkv@mail1.linuxaudio.cyso.net> <6e609eef-ca5e-1f76-3bf2-aed05420f2b7@hacklava.net> Message-ID: Le 2022-08-15 à 17 h 33, Christopher Arndt a écrit : > BTW, the recommended way to run pip is actually > > python -m pip > > because then you can control (via PATH or the command name you use) > which Python interpreter is used. So the Makefile could be: PIP = python3 -m pip PKG = zita_audiotools build:     $(PIP) wheel . install:     $(PIP) install --force-reinstall $(PKG)*.whl uninstall:     $(PIP) uninstall $(PKG) clean:     rm -rf build $(PKG)*.egg-info $(PKG)*.whl Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwm.art.net at gmail.com Sat Aug 20 23:18:43 2022 From: jwm.art.net at gmail.com (James) Date: Sat, 20 Aug 2022 22:18:43 +0100 Subject: [LAD] Wav Composer Not Toilet Message-ID: Fired my first open source project (it's 19 years old now) up the other day to create some background ambience for a youtube video I was making. It didn't compile, so I fixed the compile errors and got it working. Unarchived it from github, pushed a few commits, fixed the compile warnings. Just dipping toes in code. https://github.com/jwm-art-net/wcnt It's not professional quality software, but it makes sound, shrug. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwm.art.net at gmail.com Sun Aug 21 00:33:16 2022 From: jwm.art.net at gmail.com (James) Date: Sat, 20 Aug 2022 23:33:16 +0100 Subject: [LAD] Wav Composer Not Toilet In-Reply-To: References: Message-ID: Hi Martyn, It uses libsndfile, limited to stereo output per file (but multiple files simultaneously if required), pcm 16/24/32 or float 32/64, any samplerate. Whether the audio quality of the synthesis/sampling meets your needs is a different matter however. Thanks for the interest :-) James On Sat, 20 Aug 2022 at 23:13, Martyn Cox wrote: > Thanks James. I’ll definitely check this out. > > I’m not in a position to try it right now but I’m curious what parameters > are available for the .wav sample generation? > > And what sample rates can it spit out? > > I saw it was a text based audio app, which is neat. > > Martyn > - > https://sound7.co.uk > > > On 20 Aug 2022, at 22:18, James wrote: > >  > Fired my first open source project (it's 19 years old now) up the other > day to create some background ambience for a youtube video I was making. It > didn't compile, so I fixed the compile errors and got it working. > > Unarchived it from github, pushed a few commits, fixed the compile > warnings. Just dipping toes in code. > > https://github.com/jwm-art-net/wcnt > > It's not professional quality software, but it makes sound, shrug. > > James > > > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev at lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzofsutton at gmail.com Wed Aug 24 18:14:24 2022 From: lorenzofsutton at gmail.com (Lorenzo Sutton) Date: Wed, 24 Aug 2022 18:14:24 +0200 Subject: [LAD] Pure Python (3) chiptune - Summer 2022 Message-ID: <085ce9e6-5fd2-f767-1576-87771c582d90@gmail.com> In the tradition of previous seasonal Python chiptunes, a Summer 2022 one, now with Python 3 https://gitlab.com/lorenzosu/python-chiptune-summer-2022/ Wishing all Linux || audio || hackers a great end of summer! :-)