planet.linuxaudio.org

Hello everyone, a new release of DPF-Plugins is here.
DPF-Plugins is a collection of DPF-based plugins, including Kars, MVerb and Nekobi.
This is mostly a bugfix release, keeping up with the cool kids for regular releases.

Changelog:

• Initial experimental VST3 support
• Add bottom-right resize handle in glBars and ProM, needed in plugin formats that can't do host-side resizing
  (ProM resize handle is invisible but still works, known issue)
• Some plugin GUIs can use Cairo instead of OpenGL, if OpenGL is not available at build time
• Standalones no longer require JACK, instead detecting at runtime if it is available
• Standalones will now use RtAudio for native audio device access in case JACK is not available
• ProM now ships with (optional) vendored libprojectM in case it is not available as system library
• ProM now sets up and uses OpenGL3 context instead of OpenGL2 forward compatibility mode, fixing usage on macOS and Windows
• Fix modal about dialogs
• Fix more High-DPI related issues
• Fix OpenGL context swap on GUI deletion, needed on hosts using OpenGL

Downloads

The source code plus Linux, macOS and Windows binaries can be downloaded at https://github.com/DISTRHO/DPF-Plugins/releases/tag/v1.5.
The plugins are released as LADSPA, DSSI, LV2, VST2, VST3 and JACK standalone.

*** snip snip ***
Changes:
   Fixed a packaging error on RHEL-8.
   Updated the PyPAD plug-in to be compatible with Rivendell v4.x.
*** snip snip ***

Further information, including full source code, is available at 
https://github.com/ElvishArtisan/GlassCoder .

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|

A new version of the GStreamer Rust bindings, 0.18.0, was released. Together with the bindings, also a new version of the GStreamer Rust plugins was released.

As usual this release follows the latest gtk-rs 0.15 release and the corresponding API changes.

This release includes optional support for the latest new GStreamer 1.20 APIs. As GStreamer 1.20 was not released yet, these new APIs might still change. The minimum supported version of the bindings is still GStreamer 1.8 and the targetted GStreamer API version can be selected by applications via feature flags.

Apart from this, the new version features a lot of API cleanup and improvements, and the addition of a few missing bindings. As usual, the focus of this release was to make usage of GStreamer from Rust as convenient and complete as possible.

The new release also brings a lot of bugfixes, most of which were already part of the 0.17.x bugfix releases.

Details can be found in the release notes for gstreamer-rs.

The code and documentation for the bindings is available on the freedesktop.org GitLab

• GStreamer Rust Bindings (documentation)

as well as on crates.io.

If you find any bugs, notice any missing features or other issues please report them in GitLab.

This is a New Session Manager maintenance release.

CHANGELOG

• Add [jackpatch] to terminal log output of jackpatch
• Remove hardcoded ANSI colors from terminal log output

All changes are made only on the server side, or in the tools we provide.
Existing sessions, clients, and GUIs remain 100% compatible without requiring any changes.

After years of them seeing no changes, the JACK2 example clients and tools have finally been synced with JACK1. We only needed PipeWire to come along and force us to do it. :)
I mentioned the need to merge/sync the JACK1 and JACK2 headers and tools quite some months ago, but there wasn’t much progress on that until very recently.

For an explanation, Linux distributions like Arch that do not typically split packages (hypothetically) installing pipewire-jack would remove jack2 and replace it with PipeWire’s version. But tools like jack_connect, jack_wait, etc are part of the jack2 package, not pipewire-jack. Installing pipewire-jack would (hypothetically) remove these tools. There are quite a few set ups out there that rely on them, so a solution was needed for this.

David Runge started the effort of splitting these tools from the JACK repositories into a new one, and has now been finalized. The idea here is that both JACK1 and JACK2 will no longer ship with them, and they become an extra set of tools to install separately. This allows to switch between JACK versions (JACK1, JACK2 or PipeWire) and keep the same exact set of tools.

You can find these tools in the jack-example-tools repository.

On behalf of the Rivendell audio community, Im pleased to announce the release of GlassCoder v1.0.4, a minimalist live audio encoder. In addition to streaming to IceCast and Shoutcast stream aggregators, GlassCoder is capable of generating live HLS streams and publishing them to any standard HTTP server. It is available under the GNU Public License version 2.

Hello all, this is yet another one of those monthly reports about the KXStudio project.
There was no November monthly report, due to me being busy with moving to a new place and a few other personal things.
This month though there are a few things to report on.

DPF and VST3 work resumes

After a little break on the VST3 implementation in DPF, I went back and reworked a few things that were clearly done wrong.
It is still considered experimental, but already works much better than before.
For example, UI to DSP parameter changes works properly now, which was not the case before in some hosts (including reaper).

Once complete, DPF based plugins will be one of the few that implement the whole component vs edit-controller separation.
This might prove quite valuable in the future, specially after hosts also implement the same.
We need to come back to this after I natively implement VST3 support in Carla.

Just as before, I am keeping a TODO list of items near the top of the relevant source code file for VST3. The same also applies to the UI side.
The super short summary is that most common things already work, with only optional buses, MIDI CC handling and minor details missing.
We don't get VST3 support finalized in DPF during 2021, but it shouldn't take that much longer now.

Continuing: Separating JACK tools from JACK1 and JACK2

Mentioned last time was the effort of splitting the example-clients and tools from the JACK repositories into a new repository/project.
I have been working with David Runge on this (or better said, he has been doing most of the work) with me reviewing each set of changes to each file one by one.
We are nearly finished, with only 1 file remaining.

Afterwards there is still some work to be done on the build setup and testing the whole thing, but it is good to see things progressing on this area that was being sadly neglected for many years.
If everything goes well, no one will notice a thing!
Maintenance is a lot of work that goes unnoticed, fun stuff..

Python 3.10 and updated PyQt woes

I do not know exactly the change that triggered it, but with newer versions of python and PyQt, pretty much all my tools that use PyQt are broken.
The community was quite helpful on fixing some Carla issues themselves without my direct intervention (as I do not run a rolling-release Linux distribution, I am not directly affected).
With this a new release of Carla is needed, the same for Cadence but that remains unfixed for the time being.

Cardinal, the Rack!

A new project has been brewing behind the scenes for more or less 3 months now.
It was not in my plans when 2021 started, specially since quite a few other things needed more attention..
But this was one of these things that is just impossible to put down as an idea.
In fact, lack of attention in Carla and JACK lately are due to this project, it is simply too exciting.

The quick history of the project is that, after VCV Rack v2 source code was made public, I began wondering if that codebase could be used for building an open-source plugin (unlike the official product, which is closed-source and commercial).
After finding out that VCV's official plugin would only support VST2 and still only the same 3 base architectures (Linux, macOS and Windows 64bit), also how the whole thing would supposedly work - loading modules from the library just like in the standalone - I was quite disappointed with the whole thing.
Rack is something that always interested me, but I was put off from the (to put it mildly) abrasive attitude towards open-source ideas and Linux packaging.
Running as standalone was also not that fun for me, I personally want to create synths and have those integrated in a DAW/sequencer workflow.

There was a project called VeeSeeVSTRack that also attempted an open-source plugin version of Rack, but it had some serious drawbacks:

• Needs heavy changes to Rack source, which would have to be regularly maintained in order to keep up with upstream
• All included modules need to be patched a fair bit just to work with it
• Custom written plugin format support (so it only supported VST2)
• Custom written OS-level Window handling (only supporting Windows and Linux/X11)

While the idea in general great, there was a not insignificant amount of work needed to maintain it.
If attempting something like this, would be best to not make the same "mistakes", and think about the whole deal on the long term.
With that in mind, the Cardinal project:

• Does not fork Rack's source code, instead it uses it as submodule, replacing only a few critical functions and files
• Besides internal modules, 3rd-party ones can be linked as-is with only changes to not use osdialog due to its event-blocking nature
• Relies on DPF for plugin format support, so we get JACK, LV2 and VST2 from the start, VST3 in progress
• Also relies on DPF for OS-level Window handling, so it works on macOS too (and eventually Haiku)

Similar to VeeSeeVSTRack, Cardinal builds the entire module collection as part of one binary and uses the host audio thread to drive the engine.
This means no online library access or external module loading, which is quite intentional.
More information on the "why" section of Cardinal's README.

The obvious question that might be in the air is what to make of the official Rack Pro plugin.
To which I say - if you enjoy Cardinal, go buy Rack Pro!
Cardinal would not exist without VCV Rack, so it is for our best interest that Rack lives on for a long while.
Also they serve different purposes:
Cardinal is open-source modules only, all integrated into 1 binary.
Rack Pro is just like the standalone with online library access, commercial modules etc. And obviously the official product too.
The Cardinal project includes a table of differences between itself and Rack Pro, in case you want to go deeper into technical details.

Cardinal should be considered beta-state at the moment.
While it already works quite well (except for a few known bugs as typical), there are a few missing pieces and license situation to sort out in detail.
A lot of Rack module developers started coding because of it, so without fully understanding artwork and source code license implications quite a few of them just copied what others were doing.
And this is the problem, Rack itself contains non-commercial and even non-derivatives clauses for its artwork.
A lot of developers copied the non-commercial clause without thinking too much about it, which makes them quite tricky if not impossible to package in a Linux distribution.
Before tagging v1.0, I want to sort out these details first, to ensure everything is done not only legally but also respectfully.
Already started this on this document, which greatly helps in giving an overview of the used source code and artwork licenses.

Before moving on, here's a screenshot, because everyone likes those. :)

Many other DPF additions

While working on Cardinal, DPF got a real stress-test for some of its features.
Some were missing and needed to be added in order to make Cardinal work proper, some were found to be broken.
In no particular order, these changes were made in DPF to accommodate for Cardinal:

• Add clipboard (copy & paste) support
• Add cursor support
• Add file dialog save support (used to be only loading allowed)
• Add "desktop portal" DBus service support for providing native file browser dialogs on Linux
• Add APIs around finding the bundle path of the plugin
• Allow LTO (Link-Time-Optimization) build
• Auto-creating macOS VST2 bundle from build step, instead of needing to run a script
• Many fixes around file browser dialog support
• Many fixes around VST2 keyboard input (WIP)

The only missing feature at the moment is drag&drop support, but that needs an implementation on pugl's side first.
Once that side is done, I already have a plugin in which to test it the functionality, so it should be pretty quick.

 

And that is all for now.
If you appreciate the kind of work I do, please consider a donation.
Thank you in advance for your support, happy holidays and a happy new year!

When my stereo amplifier stopped working I could’ve bought a new one but after a quick look inside I was pretty sure the damage was minor so I brought it to a repair service. When I could pick it up again not only were the costs way below the price of a new amplifier but the repair service basically did a full recap with good quality capacitors so not only will it last another decade or two it also still sounds great.

But since this is a pre smart era device it only came with a bulky IR remote, so no possibility to control it via Wi-Fi. I bought a cheap Wi-Fi remote control device that could be flashed with Tasmota and integrated it with my Domoticz setup. Then we got a new thermostat that worked with Domoticz initially but after a firmware update it stopped working. With Home Assistant everything worked except for the IR remote control so for a while I used both solutions.

Not ideal so I dug a bit deeper to get the IR remote control to work with Home Assistant. Since user stories on this matter are pretty much non-existent here are the steps to get a similar solution going on your Home Assistant setup. Be warned that this is not a step-by-step walkthrough, I’m assuming you know how to flash ESP devices, that you know your way around Home Assistant and Tasmota and that you have your own MQTT server running.

First you will have to acquire a Wi-Fi remote control device that can be flashed with Tasmota. I got one from Amazon similar to this unit. Flashed it over the air with tuya-convert. Next step was to add the Pyscript HACS integration to Home Assistant. Then I added the following Python script wich I named irsend.py to the pyscripts directory.

#!/usr/bin/env python3

import paho.mqtt.client as mqtt

mqtt_server = "localhost"
topic = "ir_remote01"

# IR codes
ir_codes = {}
ir_codes['stereo_protocol'] = 'NEC'
ir_codes['stereo_volume_down'] = '0xE13E31CE'
ir_codes['stereo_volume_up'] = '0xE13E11EE'
ir_codes['stereo_off'] = '0xE13E13EC'
ir_codes['stereo_on'] = '0xE13EA45B'
ir_codes['stereo_tuner'] = '0xE13EBB44'
ir_codes['stereo_aux'] = '0xE13ED926'
ir_codes['stereo_cd'] = '0xE13EA15E'
ir_codes['stereo_video'] = '0xE13E43BC'


@service
def send_ir_code(action=None, id=None):
    log.info(f'irsend: got action {action} id {id}')
    ir_protocol = ir_codes[f'{id}_protocol']
    ir_code = ir_codes[f'{id}_{action}']
    ir_payload = f'{{"Protocol":"{ir_protocol}","Bits":32,"Data":"{ir_code}"}}'
    log.info(f'irsend: sending payload {ir_payload}')
    mqtt_client = mqtt.Client()
    mqtt_client.connect(mqtt_server)
    mqtt_publish = mqtt_client.publish(f'{topic}/cmnd/irsend', ir_payload)
    mqtt_client.disconnect()

What this script does is sending a message over MQTT to the IR remote control, the IR remote control then converts this message to an IR signal and transmits this signal. The script needs two input parameters, action and id. These parameters are made available to the script through pyscript. The Python @service decorator makes the script available as a Service in Home Assistant.

With this Service working I can add it to a View. I used a Grid card for this and added Buttons cards to this Grid.

The Grid Card Configuration looks like this.

Added a Name, an Icon and set the Tap Action to Call Service. As a Service I could select Pyscript Python scripting: send_ir_code and as Service data I entered an id and an action as a dictionary, so {id: stereo, action: on}. Did this for all the other actions and now I can control my pre smart age stereo in a smart way.

The post Using Home Assistant with IR controlled devices appeared first on autostatic.com.

Kahvi Collective released a new compilation on Bandcamp, inclusive two new tracks by Notstandskomitee:

rtcqs v0.3.1 is now available on Codeberg and Github. rtcqs is the continuation of the realtimeconfigquickscan project but then rewritten in Python. It comes with a Qt GUI and a few extra checks.

Dear all,

I’d like to announce rtcqs, the continuation of the realtimeconfigquickscan project. It’s a port to Python with some added extra’s, like a Spectre/Meltdown mitigations check and a Qt GUI. It has the approval of the original author of realtimeconfigquickscan to whom I owe a debt of gratitude, not only for the original code but also for his helpfulness with the continuation, or maybe even evolution of the project.

So check it out, indulge me with bugs, issues, improvements or any other useful feedback on the Codeberg repo which you can find at at https://codeberg.org/rtcqs/rtcqs

Happy system tuning and happy holidays!

Jeremy

While setting up a solution to fully automate the deployment of SSL certificates at work I piggybacked on the flow and focus to rewrite the realtimeconfigquickscan Perl code in Python. As part of the certificate deployment project I wrote an application to decrypt, re-encrypt and base64 encode PFX files so they can be uploaded to a vault solution. This way I ran into PySimpleGUI which enabled me to quickly put together a nice looking Qt GUI.

rtcqs main window

The code could be more terse and probably contains some typical non-programmer idiosyncracies. First improvement will be to make the code more dynamic so the GUI gets generated instead of using hardcoded values like it does now. And I’d like to add a power management check but then I first need to read up on that subject. There are also some checks that might need some more scrutiny like the swappiness and max_user_watches checks to verify if those checks are really needed for a real-time audio environment.

The post rtcqs released appeared first on autostatic.com.

In addition to the usual bug fixing, a common pattern across all projects are the changes related to the transition to Qt6, still experimental but mature enough, while keeping compatibility with Qt5. One stopper in this transition is the removal of the QTextCodec class in Qt6 core libraries, moved to the Core5Compat module, risking to be definitely removed at some point in the future. Some methods in Drumstick::File that depend on this class are deprecated now. This functionality is key for data preservation when parsing/importing MIDI files containing text metadata (titles, comments, names, copyrights, lyrics, markers, ...) encoded in any random scheme available in the last 30 years. But the alternative in Qt6 is the QStringConverter and related classes that only supports a very limited set of encodings, mostly Unicode.

This problem deserves deeper thoughts...

If we were talking about pure text files, this could be solved using for instance the iconv command line Unix utility, that converts text files from one encoding to another, for instance from ISO-8859-5 (Cyrillic alphabet) to UTF-8. Then, the new text file encoded in Unicode could be processed by a Qt6 program without limitations. But MIDI files are compact binary structures that can't be processed directly with that utility.

The second root of the problem comes from the SMF nature itself. The Standard MIDI File format was created as an interchange file format, so the music created in sequencers using proprietary storage formats could be exported and retrieved by another sequencer. Sequencer machines and software at one point become deprecated, stopping to work, and can't be used anymore. Composition files created in those systems are now digital garbage for the trash bin, except if the author took the precaution of keeping exported MIDI files. Those are now the equivalent of modern digital manuscripts, which we try to preserve and keep them readable for the foreseeable future within our musical applications.

Changes in Virtual MIDI Piano Keyboard v0.8.6:

• Fixed advanced setting on connections dialog.
• Enabled empty input connection after fix on drumstick-ALSA: requires external connections utility.
• Better inverted piano colors after fix on drumstick-widgets: changed the white keys background picture depending on the key background color.
• Removed dependency on Qt6::Core5Compat when building with Qt6
• Requires: drumstick-2.5

Downloads: http://sourceforge.net/projects/vmpk/files/0.8.6/

Changes in Drumstick MIDI Player v1.5.3:

• After drumstick ticket #37: WRK format markers are supported
• Replaced deprecated signals from drumstick-file when building with Qt6
• Requires: drumstick-2.5

Downloads: https://sourceforge.net/projects/dmidiplayer/files/v1.5.3/

Changes in Drumstick Metronome 1.3.0

• Czech translation updated, by Pavel Fric
• Qt6 compatibility fixes
• New build options: USE_QT and BUILD_DOCS
• Revised and updated documentation system: using Pandoc to create man page and help documents
• New settings: qt style, forced dark mode, and internal icon theme
• Added action icons: internal theme based on breeze
• Desktop icon replaced

Downloads: https://sourceforge.net/projects/kmetronome/files/kmetronome/1.3.0/

Changes in Drumstick MIDI Monitor v1.2.0

• Czech translation updated, by Pavel Fric
• Revised and updated documentation system: using Pandoc to create man page and help documents
• New build options: USE_QT and BUILD_DOCS
• Qt6 compatibility fixes
• Save recording fixes
• Fixed mute track functionality
• Fixed event playback highlighting
• Support WRK file format markers, provided by Drumstick 2.5
• Desktop icon replaced

Downloads: https://sourceforge.net/projects/kmidimon/files/1.2.0/

Changes in WRK2MID v1.1.0

• New build option: BUILD_DOCS.
• New Build option: USE_QT to choose between Qt5 and Qt6. Closes ticket #3.
• Convert WRK track Port parameter. Closes ticket #2.
• Convert WRK markers into SMF text markers. Closes ticket #1.
• Displayed compiled and runtime library version information.

Downloads: https://sourceforge.net/projects/wrk2mid/files/v1.1.0/

Changes in Drumstick Libraries v2.5.0:

• New build options: BUILD_ALSA, BUILD_FILE, BUILD_RT, BUILD_WIDGETS to control building only some of the libraries.
• RT, VPiano: Fixed ALSA and CoreMIDI backends, enabling empty connections (for using external connection tools).
• Deprecation of the Drumstick::File functions affected by the QTextCodec class removal on Qt6.
• Raised macOS deployment target to 10.13 (High Sierra).
• Widgets: changed the white keys background picture depending on the key background color.
• VPiano: new option to display inverted key colors.
• File: WRK format markers processing. Closes ticket #37.

Downloads: https://sourceforge.net/projects/drumstick/files/2.5.0/

When [Mahesh Venkitachalam] was experimenting with machine learning for audio applications on a Raspberry Pi, he found himself looking for a simple USB microphone. A cheap one was easy to find, but the sound quality and directionality left much to be desired. A large, studio-quality mic would be overkill, so [Mahesh] decided to simply build exactly what was needed: a compact, yet high-quality USB microphone that he called Mico.

The sensing device is a MEMS microphone that outputs a pulse density modulated (PDM) signal. There are chips available to directly interface such a microphone to a USB port, but [Mahesh] found them difficult to work with and therefore settled on something he knew already: the Raspberry Pi Pico platform. Luckily, someone had already figured out how to read out a microphone and present a USB device to a PC, so all that was needed was to put all the bits together into a convenient form factor.

The great thing about the Pico platform is that its main controller chip, the RP2040, is available as a separate component. [Mahesh] designed a sleek little PCB that holds the RP2040 along with the MEMS microphone and a USB connector. The end result looks tidy enough that it might have come out of a mass-produced gizmo. Those don’t usually come with full schematics and source code, but the Mico does: everything is available on its GitHub page for anyone to re-use and improve.

You can judge the sound quality for yourself in the video embedded below. If you like DIY USB microphones, you’re in luck: we’ve featured one based on an STM32 as well as a beautiful recreation of a studio-quality mic.

The preeminent multi-platform touch control app just keeps improving since its next-gen reboot earlier this year. And that means the ability to get your hands on music and visuals wherever you are, on any OS. So let's catch up with Hexler.

The post TouchOSC updates are here, plus excellent videos for inspiration, instruction appeared first on CDM Create Digital Music.

The RSS feed is currently experiencing technical difficulties. The error is: invalid or no response from Elasticsearch

Patching for the people - there's no reason cost or access has to keep you from the powers and fun of modular synthesis and music making. VCV Rack's launch this month got lots of attention, but there are other options, too. Here the latest, best picks.

The post The best free tools for working with modular synthesis and music appeared first on CDM Create Digital Music.

check out this small Italien interview with Notstandskomitee:

https://luponair.wordpress.com/2021/12/02/micro-intervista-notstandskomitee-2

The first pre-release of Anklang was uploaded to Github a couple days ago. The Anklang project is a digital audio synthesis application for live creation and composition of music or other audio material. It merges several new developments and (Beast) rewriting efforts by Stefan Westerfeld and me…

• Roll back VSTGUI to 4.10.2 to avoid corruption of the UI in some scenarios

See: GitHub release page

Download links:

• sfizz-1.1.1-macos.dmg
• sfizz-1.1.1-mingw32.tar.gz
• sfizz-1.1.1-mingw64.tar.gz
• sfizz-1.1.1-moddevices.tar.gz
• sfizz-1.1.1-win32.exe
• sfizz-1.1.1-win64.exe
• sfizz-1.1.1.tar.gz