'pw-cli dump short link' was very handy, permitted build of a simple CLI
patch manager for Pipewire (see
https://wiki.archlinux.org/title/PipeWire#PipeWire_patch_sets_for_command_l…).
The 'dump' command appears to have been deleted. Anyone have a good
replacement, something which will generate a simple text list of
Pipewire links with both sides? 'pw-link -l' prints a list, but it's
not simple to parse...at least not for me :-)
Related: I keep trying to save patch sets in qpwgraph, but it only saves
one wire, out of dozens. Activated on, Exclusive tested on and off.Â
Clues, anyone?
--
Jonathan E. Brickman jeb(a)ponderworthy.com  (785)233-9977
Web pages <https://ponderworthy.com/otherpages.html> Facebook
<https://www.facebook.com/jonathan.e.brickman/> Twitter
<https://twitter.com/JEBofChrist>
XUiDesigner v0.8 released
A easy to use tool to generator/design X11 based LV2 Plugin Bundles.
Beside that XUiDesigner allow to generate and install GUI's for existing
LV2 plugins (so far only Reaper fail to load extra UI's), 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. This works now as well for MIDI
capable faust modules.
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++) into
a LV2 plugin.
Example files for how to create a c++ file for parsing (drag n' drop)
with XUiDesigner been included.
For later rework the UI a json file will be created which you could drop
later on XUiDesigner to load and rework the UI.
This may also be usable by other toolkits to create a UI?
This release comes with a couple of Bug-fixes and aims to be nearly stable.
Here is a introduction Wiki
<https://github.com/brummer10/XUiDesigner/wiki/XUiDesigner> entry to
show the first steps.
Note: Please download the attached XUIDesigner_0.8.tar.gz
<https://github.com/brummer10/XUiDesigner/releases/download/v0.8/XUIDesigner…>
archive, as only that contain the needed git submodule ( old long time
knowing bug on github) as the other files wont be able to build
XUiDesigner for you.
New in this release:
Implement Virtual Midi Keyboard Widget
Fix segfault under Wayland
Fix several Bugs
Implement proper *.cc file parser
Add examples for *cc file parsing
Project page:
https://github.com/brummer10/XUiDesigner
Download Release:
https://github.com/brummer10/XUiDesigner/releases/download/v0.8/XUIDesigner…
Enjoy anyway.
Hello all,
Any experts on linear prediction here ?
During my current holidays in Greece, apart from SCUBA diving,
I've been reading up and doing a lot of simulations (in Python)
of algorithms related to linear prediction. This has been - I
must adimit - a gaping hole in my practical DSP experience up
to now.
Things work well, but there is one thing that remains strange.
It is usually said (see e.g. JOS) that the required order of
the prediction should be a bit higher than twice the number
of resonances (or formants for voice processing) in the signal
to be predicted. This makes sense as each resonance is in
essence a second-order process.
>From my experiments it seems that at a sample rate of e.g. 48 kHz
(indeed much higher than normally used to for speech processing),
a much higher order is required to model a low frequency formant
at e.g. 350 Hz.
What seems to happen at low order is that processing the prediction
error (residual) by the the synthesis filter produces and almost
perfect reconstruction of the input, but that the filter is
actually just doing the -6dB/oct slope above the resonance,
while the resonance itself remains in the residual.
So e.g. trying to move the formant by modifying the filter will
fail.
As far as I can see, a prediction order of around 50 is required
to correctly model a resonance at such low frequencies.
So my question now is this: is the rule mentioned above just
wrong, or am I missing something ?
Ciao,
--
FA
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
