planet.linuxaudio.org

September 27, 2020

drobilla.net - LAD

Sratom 0.6.6

Sratom 0.6.6 has been released. Sratom is a small library for serialising LV2 atoms to and from RDF, for converting between binary and text or storing in a model. For more information, see http://drobilla.net/software/sratom.

Changes:

  • Fix various minor warnings and other code quality issues

by drobilla at September 27, 2020 07:18 PM

Suil 0.10.8

Suil 0.10.8 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.

Changes:

  • Fix X11 in Gtk size regressions (thanks Robin Gareus)
  • Fix compilation on MacOS older than 10.12
  • Fix drag and drop for X11 in Gtk
  • Fix various minor warnings and other code quality issues

by drobilla at September 27, 2020 04:22 PM

September 25, 2020

The Linux-audio-announce Archives

[LAA] Release: Patroneo v1.7

Ladies and Gentlemen,

hereby the Laborejo Software Suite releases updates for its programs in
the hope to be useful in your musical toolbox.
You can now download Patroneo version 1.7.

All software is released under GPLv3.

Patroneo (Esperanto: /Pattern/) is an easy to use, pattern based midi 
sequencer, a program that sends digital "notes" to software instruments
such as synthesizers and samplers.

Changelog Highlights:
* [Patroneo] Allow Note-On Velocity 0 to make external conversion into CCs possible
* [Patroneo] Fix crash when loading a project with only one track

You can find all releases as sources here. Also check your distribution
for packages in a few days after this announcement, please.
https://laborejo.org/downloads/

For more information, a multi-language user manual, build instructions
and git access please visit

https://www.laborejo.org/patroneo/


Greetings,
Laborejo Software Suite
https://www.laborejo.org/

by info at laborejo.org (Laborejo Software Suite) at September 25, 2020 08:06 PM

blog4

The Quarantine Report is due October 1.

The new Notstandskomitee album The Quarantine Report is due for release on October 1., available on all digital music platforms. Here is an early preview / trailer based on the upcoming CGI musicvideo for the second track SKU:



by herrsteiner (noreply@blogger.com) at September 25, 2020 06:04 PM

September 24, 2020

Audio – Stefan Westerfeld's blog

SpectMorph 0.5.2 released

A new version, SpectMorph 0.5.2 is available at www.spectmorph.org.

SpectMorph (LV2/VST plugin, JACK) is able to morph between samples of musical instruments. A standard set of instruments is shipped with SpectMorph, and an instrument editor is available to create user defined instruments from user samples.

With this release, the SpectMorph LFO can be synchronized with the song tempo. This allows morphing frequency to be specified as note length (for instance quarter notes). As a related new feature, the playback speed of samples (user defined instruments) can be controlled using automation/LFOs, so it is possible to time-stretch a sample as needed to be synchronized to the song tempo. To see how to use the new possibilities, I recommend these tutorials:

A full list of all changes can be found here.

And finally here is a new piece of music made with SpectMorph:

by stw at September 24, 2020 04:46 PM

September 22, 2020

The Linux-audio-announce Archives

[LAA] spectmorph-0.5.1

spectmorph-0.5.2 has been released.

The two new main features (synchronizing morphing with the song tempo
and positional play) are explained here: https://youtu.be/6E4HClXdV_Y

If you haven't watched our video tutorial for the instrument editor
added in 0.5.0, you can do so here: https://youtu.be/JlugWYPDp84

Overview of Changes in spectmorph-0.5.2:
----------------------------------------
* Support bpm/beat synchronization for LFO
  - new presets using beat sync LFO: Mars / Saturn
* Add WavSource custom position playback mode
* New Instruments: Sven Ah / Ih / Oh (another male human voice)
* Store data in XDG directories on Linux:
  - move ~/.spectmorph directory to $XDG_DATA_HOME/spectmorph
  - move ~/SpectMorph directory to $XDG_DOCUMENTS_DIR/SpectMorph
  - create $XDG_DOCUMENTS_DIR/SpectMorph directory when needed (on write)
  - backward compatibility: use ~/SpectMorph if it already exists
* Bump number of control inputs from 2 to 4
* Implemented midi CC control for smjack (General Purpose Controller 1..4)
* Fix crashes caused by dangling MorphOperator pointers
* Fix loading floating point wav files
* Minor fixes and cleanups

What is SpectMorph?
-------------------
SpectMorph is a free software project which allows to analyze samples of
musical instruments, and to combine them (morphing). It can be used to
construct hybrid sounds, for instance a sound between a trumpet and a
flute; or smooth transitions, for instance a sound that starts as a
trumpet and then gradually changes to a flute.

SpectMorph ships with many ready-to-use instruments which can be
combined using morphing.

SpectMorph is implemented in C++ and licensed under the GNU LGPL version 3

Integrating SpectMorph into your Work
-------------------------------------
SpectMorph is currently available for Linux, Windows and macOS users.
Here is a quick overview of how you can make music using SpectMorph.

- VST Plugin, especially for proprietary solutions that don't support LV2.
  (Available on Linux and 64-bit Windows/macOS)
- LV2 Plugin, for any sequencer that supports it.
- JACK Client.

Links:
------
Website:  http://www.spectmorph.org
Download: http://www.spectmorph.org/downloads

There are many audio demos on the website, which demonstrate morphing
between instruments.
-- 
Stefan Westerfeld, http://space.twc.de/~stefan

by stefan at space.twc.de (Stefan Westerfeld) at September 22, 2020 01:19 PM

September 15, 2020

rncbc.org

Qtractor 0.9.17 - An End-of-Summer'20 Release


So long Summer'20,

Qtractor 0.9.17 (end-of-summer'20) is released!

Change-log:

  • Early fixing to build for Qt >= 6.0.0 and the C++17 standard.
  • Fixed crash when changing an auto-monitored audio track's number of channels due on switching its audio output bus.
  • Avoid a complete track re-open when changing properties, unless either input or output buses are changed.
  • Fixed custom track icon selection when none is currently set.

Description:

Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio.

Website:

http://qtractor.org
https://qtractor.sourceforge.io
http://qtractor.sourceforge.net

Project page:

https://sourceforge.net/projects/qtractor

Downloads:

https://sourceforge.net/projects/qtractor/files

Git repos:

https://git.code.sf.net/p/qtractor/code
https://github.com/rncbc/qtractor.git
https://gitlab.com/rncbc/qtractor.git
https://bitbucket.org/rncbc/qtractor.git

Wiki (outdated; help wanted!):

https://sourceforge.net/p/qtractor/wiki/

License:

Qtractor is free, open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Keep the fun! Stay healthy!

Donate to rncbc.org

by rncbc at September 15, 2020 07:00 PM

September 13, 2020

digital audio hacks – Hackaday

World Radio Lets Your Fingers Do the Walking

Listening to radio from distant countries used to take a shortwave rig, but thanks to the Internet we can now pull in streams from all over the globe from the comfort of our own desktop. With a few clicks you can switch between your local news station and the latest in pop trends from Casablanca. But as convenient as online streaming might be, some folks still yearn for the traditional radio experience.

For those people, the Raspberry Pi World Radio by [Abraham Martinez Gracia] might be the solution. Built into the body of a 1960s Invicta radio, this Internet radio uses a very unique interface. Rather than just picking from a list of channels, you use the knobs on the front to pan and zoom around a map of the world. Streaming channels are represented by bubbles located within their country of origin, so you’ll actually have to “travel” there to listen in. The video after the break gives a brief demonstration of how it works in practice.

We’ll admit it might become a bit tedious eventually, but from a visual standpoint, it’s absolutely fantastic. [Abraham] even gave the map an appropriately vintage look to better match the overall aesthetic. Normally we’d say using a Raspberry Pi 4 to drive a streaming radio player would be a bit overkill, but considering the GUI component used here, it’s probably the right choice.

Of course we’ve seen Internet radios built into vintage enclosures before, and we’ve even seen one that used a globe to select the station, but combining both of those concepts into one cohesive project is really quite an accomplishment.

by Tom Nardi at September 13, 2020 05:00 AM

September 08, 2020

rncbc.org

Vee One Suite 0.9.17 - A Late Summer'20 Release


One lousy Summer, just saying goodbye,...

And now this...

The Vee One Suite of old-school software instruments, synthv1, as a polyphonic subtractive synthesizer, samplv1, a polyphonic sampler synthesizer, drumkv1 as yet another drum-kit sampler and padthv1 as a polyphonic additive synthesizer, are here released for the (Northern) Summer'20 ending season and bumped to version 0.9.17.

Featuring:

  • a pure stand-alone JACK client with JACK-session, NSM (Non/New Session Management) and both JACK MIDI and ALSA MIDI input support;
  • a LV2 instrument plug-in.

Change-log:

  • Arbitrary number of pitch-shifted octave sample tables is now an instance parameter; pitch-shifting algorithm is selected as a global user preference option cf. Help > Configure... > Options > Pitch-shift type: S.M.Bernsee classic algorithm (default) or RubberBand library. (applies to samplv1 only)
  • Added -n, --client-name to the JACK stand-alone client application command line option arguments.
  • Fixed uninitialized number of voices variable; early-bird adaptations to Qt6 >= 6.0.0 and C++17 standard.

The Vee One Suite are free, open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

And here they are, one more time and again:

 

synthv1 - an old-school polyphonic synthesizer

synthv1 0.9.17 (late-summer'20) released!

synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx.

LV2 URI: http://synthv1.sourceforge.net/lv2

website:
https://synthv1.sourceforge.io
http://synthv1.sourceforge.net

project page:
https://sourceforge.net/projects/synthv1

downloads:
https://sourceforge.net/projects/synthv1/files

git repos:
https://git.code.sf.net/p/synthv1/code
https://github.com/rncbc/synthv1.git
https://gitlab.com/rncbc/synthv1.git
https://bitbucket.org/rncbc/synthv1.git

 

samplv1 - an old-school polyphonic sampler

samplv1 0.9.17 (late-summer'20) released!

samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.

LV2 URI: http://samplv1.sourceforge.net/lv2

website:
https://samplv1.sourceforge.io
http://samplv1.sourceforge.net

project page:
https://sourceforge.net/projects/samplv1

downloads:
https://sourceforge.net/projects/samplv1/files

git repos:
https://git.code.sf.net/p/samplv1/code
https://github.com/rncbc/samplv1.git
https://gitlab.com/rncbc/samplv1.git
https://bitbucket.org/rncbc/samplv1.git

 

drumkv1 - an old-school drum-kit sampler

drumkv1 0.9.17 (late-summer'20) released!

drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx.

LV2 URI: http://drumkv1.sourceforge.net/lv2

website:
https://drumkv1.sourceforge.io
http://drumkv1.sourceforge.net

project page:
https://sourceforge.net/projects/drumkv1

downloads:
https://sourceforge.net/projects/drumkv1/files

git repos:
https://git.code.sf.net/p/drumkv1/code
https://github.com/rncbc/drumkv1.git
https://gitlab.com/rncbc/drumkv1.git
https://bitbucket.org/rncbc/drumkv1.git

 

padthv1 - an old-school polyphonic additive synthesizer

padthv1 0.9.17 (late-summer'20) released!

padthv1 is an old-school polyphonic additive synthesizer with stereo fx

padthv1 is based on the PADsynth algorithm by Paul Nasca, as a special variant of additive synthesis.

LV2 URI: http://padthv1.sourceforge.net/lv2

website:
https://padthv1.sourceforge.io
http://padthv1.sourceforge.net

project page:
https://sourceforge.net/projects/padthv1

downloads:
https://sourceforge.net/projects/padthv1/files

git repos:
https://git.code.sf.net/p/padthv1/code
https://github.com/rncbc/padthv1.git
https://gitlab.com/rncbc/padthv1.git
https://bitbucket.org/rncbc/padthv1.git

 

Donate to rncbc.org

Have fun!

by rncbc at September 08, 2020 06:00 PM

digital audio hacks – Hackaday

The Floppy Disk As A Portable Music Format

We remember the floppy disk as the storage medium most of us used two decades or more ago, limited in capacity and susceptible to data loss. It found its way into a few unexpected uses such as Sony’s Mavica line of digital cameras, but outside those who maintain and use older equipment it’s now ancient history.

Seemingly not for [Terence Eden] though, who has made a portable audio player that uses a floppy disk as its storage medium. It came about with the realization that half an hour of extremely compressed audio could be squeezed onto a standard 3.5 inch floppy, and then that the Beatles’ A Hard Day’s Night album comes in at only a shade over that time. With some nifty manipulation of the compression command line and the judicious removal of some unnecessary metadata, the album can fit on a floppy in equivalent quality to the AM radio fans would have heard it over back in 1964.

The player would have been a major undertaking when the floppy was king, but in 2020 it’s simply a USB floppy drive, a Raspberry Pi, and a battery pack. He’s given us the full instructions, and no doubt a more permanent version could be built with a 3D-printed case.

We’re fascinated by the recent trend of storing audio on floppy disks, but despite the hipster vibe, we doubt  the idea will catch on. It’s not the first floppy-based player we’ve seen, but the previous one was more of a fake player.

by Jenny List at September 08, 2020 05:00 AM

GStreamer News

GStreamer 1.18.0 new major stable release

The GStreamer team is excited to announce a new major feature release of your favourite cross-platform multimedia framework!

As always, this release is again packed with new features, bug fixes and other improvements.

The 1.18 release series adds new features on top of the previous 1.16 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

Highlights:

  • GstTranscoder: new high level API for applications to transcode media files from one format to another
  • High Dynamic Range (HDR) video information representation and signalling enhancements
  • Instant playback rate change support
  • Active Format Description (AFD) and Bar Data support
  • ONVIF trick modes support in both GStreamer RTSP server and client
  • Hardware-accelerated video decoding on Windows via DXVA2 / Direct3D11
  • Microsoft Media Foundation plugin for video capture and hardware-accelerated video encoding on Windows
  • qmlgloverlay: New overlay element that renders a QtQuick scene over the top of an input video stream
  • New imagesequencesrc element to easily create a video stream from a sequence of jpeg or png images
  • dashsink: Add new sink to produce DASH content
  • dvbsubenc: DVB Subtitle encoder element
  • TV broadcast compliant MPEG-TS muxing with constant bitrate muxing and SCTE-35 support
  • rtmp2: new RTMP client source and sink element implementation
  • svthevcenc: new [SVT-HEVC](https://github.com/OpenVisualCloud/SVT-HEVC)-based H.265 video encoder
  • vaapioverlay compositor element using VA-API
  • rtpmanager support for Google's Transport-Wide Congestion Control (twcc) RTP extension
  • splitmuxsink and splitmuxsrc gained support for auxiliary video streams
  • webrtcbin now contains some initial support for renegotiation involving stream addition and removal
  • New RTP source and sink elements to set up RTP streaming via rtp:// URIs
  • New Audio Video Transport Protocol (AVTP) plugin for Time-Sensitive Applications
  • Support for the Video Services Forum's Reliable Internet Stream Transport (RIST) TR-06-1 Simple Profile
  • Universal Windows Platform (UWP) support
  • rpicamsrc element for capturing from the Raspberry Pi camera
  • RTSP Server TCP interleaved backpressure handling improvements as well as support for Scale/Speed headers
  • GStreamer Editing Services gained support for nested timelines, per-clip speed rate control and the [OpenTimelineIO](https://opentimelineio.readthedocs.io) format.
  • Autotools build system has been removed in favour of Meson
  • Many performance improvements

Full release notes can be found here.

Binaries for Android, iOS, Mac OS X and Windows will be provided in due course.

You can download release tarballs directly here: gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, gst-rtsp-server, gst-python, gst-editing-services, gst-devtools, gstreamer-vaapi, gstreamer-sharp, gst-omx, or gstreamer-docs.

September 08, 2020 12:30 AM

September 07, 2020

blog4

The Chants Of Real Estate Data


As a part of the curated exhibition Sound Campus of the Kunstuniversität Linz, Malte Steiner was invited to create the VR / 3D work The Chants Of Real Estate Data. Like other works of his project The Big Crash it is based on data from the housing market which was retrieved online and used to create virtual architecture and a multichannel sound composition which can be experienced as part of the Sound Campus Metaverse, shown and made available during this years Ars Electronica. It can be downloaded from tomorrows 8. September on and is available only till the 13. September inclusive.

Here a teaser on Youtube about the Sound Campus Metaverse: 



by herrsteiner (noreply@blogger.com) at September 07, 2020 09:24 PM

KXStudio News

Carla 2.2 RC2 is here!

Hello everyone, this is an announcement for the next release candidate for Carla v2.2.
Comes after a few issues were reported and fixed, and as an exception a new plugin is added.

The new plugin is actually "XY Controller" from the Cadence project.
It works pretty much the same way, except that received MIDI data will not change the UI elements.
This is because this is a plugin now, not a standalone application anymore. But everything else remains.
As a bonus, the X and Y are now plugin parameters, and work as parameter outputs too, so they can control other stuff in Carla.

Why the plugin was added so suddenly will be explained in detail in a future Cadence release.
But in short, I am splitting Cadence into easier to manage sub-projects.
The "Meter" and "XY Controller" tools are now part of Carla, so they can be removed from Cadence.

Besides the new plugin (which again is an exception, due to Carla v2.2 already being in Release-Candidate state) we only have bug-fixes.
The full list of changes is:

  • Add xycontroller plugin
  • Auto-select text in plugin search entry when focused via shortcut
  • Compress canvas clipboard image saving (as PNG)
  • Disable OSC by default on macOS
  • Fix crash when receiving unexpected VST2 time information
  • Fix current project filename persistence after engine stop
  • Fix deadlock when using VST3 plugins inside Carla as plugin
  • Fix listing LV2 plugins on Windows (2.2 regression)
  • Fix oddities with MIDI learn
  • Fix potential crashes when opening or hiding plugin UIs
  • Fix some plugins not having all their audio ports exposed
  • Fix some plugin UIs not in front of Carla when first shown
  • Fix wine bridge build against winehq-stable and winehq-stable
  • Overall fix to midi pattern plugin
  • Package macOS plugin version, making Carla-Plugin usable with macOS 10.15

Downloads

To download Carla binaries or source code, jump on over to the KXStudio downloads section.
If you're using the KXStudio repositories, you can simply install "carla-git" (plus "carla-lv2" and "carla-vst" if you're so inclined).
Bug reports and feature requests are welcome! Jump on over to the Carla's Github project page for those.

Final note

Just a reminder that this is a release candidate, and not the final release yet.
There are still a few known issues, but since they are specific to certain workflows, the amount of users affected is limited.
If you find any more of them, please let me know in the github issue tracker, thanks!

by falkTX at September 07, 2020 07:58 PM

Ardour 6.3 is released

Ardour 6.3 is released. This is mostly a maintenance release, but the new Loudness Analysis feature will be very useful to some users. The usual steady drip-drip of bug fixes continues, and thanks to Ayan Shafqat, we now have up to date super-optimized metering code for Linux on both x86(64) and ARM platforms (metering is the most computationally expensive thing that Ardour itself does).

For more details, please read the whole release announcement .

Download as usual from https://ardour.org/download

15 posts - 10 participants

Read full topic

by Paul Davis at September 07, 2020 06:02 PM

September 04, 2020

Talk Unafraid

Rusty all-sky cameras

All-sky cameras are a lovely idea, especially if you’re someone like me who enjoys hiding in the warm most of the time and letting the computers look after the telescope in the depths of winter. I’ve been enjoying some time (when the clouds permit) this summer looking at things directly, but deep-space-object imaging in summer is brutal – short periods of darkness mean all the setup and teardown only for an hour or two of adequate darkness.

An all-sky camera is just a camera with a fisheye lens looking up 24/7/365, taking exposures in darkness of typically over 30 seconds to see stars. You can analyse these exposures to find out about sky conditions, use them as a quick visual guide, and spot meteors. And since they live outside all the time, there’s no setup or teardown!

So I figured I’d have a go at doing an all-sky camera, from scratch. There were a few reasons I wanted to do this. My mirror project is still going (slowly) when I get the headspace, but it takes a lot of messy setup and teardown, so is hard to dip into in the evenings when I have time. But mostly I was curious to dig a bit more into INDI, the protocol I use to control my telescope.

INDI is the instrument-neutral device interface, and it is XML over TCP. It’s quite an old design, using fairly old technologies. However, it’s well-liked by manufacturers as it has a quite simple C API, a very flexible abstraction model, and works well over networks as well as for local use. indiserver is the reference server implementation and has dozens of drivers for cameras, mounts, observatory dome motors, and everything inbetween. I can write C, but if I can avoid it, I always try to – so rather than use the libindi library or the pyindi libraries (which depend on the C library) I thought I might have a go at writing a new implementation from scratch.

I’ve been tinkering with Rust for a while now, and wrote my first serious project in it last month – a parser for Telcordia’s slightly-obscure optical time domain reflectometry (OTDR) format. I found it quite jarring coming from Python, even having written C/C++ in the past, but after a while I realised I was making better structural decisions about my code than I was in Python et al. The Rust compiler is aggressively studious, and forces you to think things through – but after a while getting used to the style, this becomes something quite conversational, rather than adversarial.

Aside from writing some Rust I needed some hardware, so through a half-dozen eBay orders and bits I had lying around, I assembled a “v1” camera. This contained a Pi 4, a WiFi radio with a high-gain antenna, an ASI120MC camera I was using for guiding, and a 12V to 5V step-down board. The power was supplied by a 12V PSU in a waterproof box sat next to this.

To look out, the enclosure got a dome thrown on top – an old CCTV camera dome, with silicone sealant around the rim to make a good watertight fit. I didn’t get the hole position spot on, but it was close enough and seals up fine.

Armed with some hardware, I was ready to test. My first test images revealed some horrendous hot pixels – a known issue with un-cooled cameras – and some clouds. An excellent first step!

One frame from the camera
One frame, gently post-processed

Taking frames over the course of an evening and assembling into a video yielded a fairly nice result. To drive the camera I used KStars, with indiserver running on the Pi4 to control the hardware.

I assembled the above video in PixInsight, having done hot pixel removal and a few other bits of post-processing. Not really a viable approach for 24/7 operation!

v2 – Brown Noctuas – not just for PCs! They also do tiny ones.
Inlet and outlet, with grilles to keep the smaller bits of wildlife out (hopefully)

Hot pixels are more or less guaranteed on uncooled cameras, but the box was getting quite hot. So I’ve now wrapped it in shiny aluminium foil to increase its solar reflectance index, and added a 40mm fan to circulate air through the enclosure (with a 40mm opening on the far side, camera in the middle – some quick CFD analysis suggested this as a sensible approach).

This definitely helps matters somewhat, though in winter a dew heater will be required, and rain removal is something that bears further study – my initial approach involves some G Techniq car windscreen repellent.

I’ve started on an INDI client implementation in Rust, now. This has been a challenge so far. For starters, Rust doesn’t have many XML parsers/generators, and those that exist aren’t well documented. However, having gotten the basics working, the way that INDI works presents some challenges. The protocol essentially shoves XML hierarchies around and then makes updates to elements within that hierarchy, and expects clients to trigger events or make changes to their state based on state changes within that hierarchy. There’s very little protocol-defined convention and a lot of unwritten expectations.

This makes for a very flexible protocol, but a very uncertain client. This doesn’t map into Rust terribly well, or at least requires a more complex level of Rust than I’ve used to date! It does also explain a great deal about some of the challenges I’ve had with stable operation using INDI clients of various forms. There’s such a thing as too much rigidity in abstractions, but there’s definitely such a thing as too little.

So, next step is getting the basic client working and stable with good and verifiable handling of errors. I’m intending to fuzz my client in the same way I’ve fuzzed otdrs, but also to have extensive test cases throughout to ensure that I can replicate well-behaved servers as well as the full gamut of odd network errors and conditions that can arise in INDI ecosystems. Hopefully I’ll end up with a client library for INDI which is fairly bulletproof – and then I can start writing an application!

My initial plan is to write something nice and basic that just does a fixed exposure and stores the raw FITS files on disk in a sensible layout. But once that’s done, I want to tackle image analysis for auto-exposure and dark frame processing. This will involve parsing FITS frames, doing some processing of them, and writing either FITS or PNG files out for storage.

It’s definitely an interesting challenge – but it feels tractable to extend my Rust knowledge. I’ve been really taken with the language as a tool for systems programming, which overlaps quite well with astronomy software. We generally want high levels of reliability, do plenty of maths and processing which benefits from low-level language performance, and increasingly do networking or work with remote hardware. It’s a good fit, it feels, and just needs some more time invested in it.

by James Harrison at September 04, 2020 07:50 PM

August 30, 2020

Scores of Beauty

Google Summer of Code 2020: SMuFL

Hi all! I’m Owen, a music composition undergrad from Arizona State University, and I’ve been working for LilyPond under Google Summer of Code these past three months. It’s been quite an adventure–I’ve gotten familiar with some of LilyPond’s insides, (partially) deciphered the ancient METAFONT language, and discovered the perks and responsibilities of developing free software, all while slapping my fingers on a plastic keyboard for money!

TL;DR: I improved LilyPond’s native support for SMuFL fonts like Bravura and brought more SMuFL compatibility to the Emmentaler font. My work can be found here: https://gitlab.com/lilypond/lilypond/-/tree/dev/lamb/GSoC-2020-final.

SMuFL

The Standard Music Font Layout (SMuFL), created by Daniel Spreadbury and now overseen by the W3C Music Notation Community Group, is a fairly new open standard for music fonts. It specifies names and Unicode code points for a large set of musical symbols (known as glyphs), as well as a metadata file for each font that contains other information, such as staff thickness. Its aim is to allow notation fonts to be used in any piece of music software.

My job this summer was to bring support for SMuFL to LilyPond and, if possible, make Emmentaler, LilyPond’s in-house music notation font, SMuFL-compliant. I was not able to meet this goal entirely, but I have made significant progress, including allowing Bravura, the reference font for SMuFL, to be loaded in and used for basic notation.

Glyph Names

LilyPond uses a period-punctuated naming system for a font’s glyphs. For instance, a whole note / semibreve glyph is named noteheads.s0, a half note / minim notehead glyph is named noteheads.s1, etc. This system is tailored to the way LilyPond understands notes, so it would not be easy (or even desirable) to remove it outright.

SMuFL’s own naming system uses a camel-case style: noteheadWhole, noteheadHalf, etc. Instead of requiring glyphs to have these particular names, however, SMuFL generally expects a particular named glyph to be found at a particular code point. For instance, noteheadWhole is assigned 0xE0A2; noteheadHalf, 0xE0A3. Not every glyph name is assigned such a universal code point, so the glyph names are still significant–they’re just not the glyphs’ actual names in the same way that the Lily-style names are.

Rather than abandoning one naming scheme for the other, I opted to support both, and to offer a method of conversion from one to the other. This started with moving Emmentaler’s glyphs to where SMuFL expects them to be.

Emmentaler is currently made via a pipeline of sorts. First, glyphs are defined in METAFONT files, which are run through METAPOST to create small “subfont” files for each category of glyphs, as well as logfiles containing extra information for each glyph. A Python script is then run on each logfile, generating a couple lisp metadata files for each one. (Lisp files are easy for LilyPond to read.) Finally, another Python script generates one, large font file from the subfonts, and embeds the lisp files in it.

In order to make Emmentaler SMuFL-compatible, I went into the METAFONT files and added an extra parameter to the glyph definition function, a piece of text that describes the glyph’s SMuFL name(s) and any variation or ligature information it may have. This string is piped, along with the glyphs’ other information, to the first Python script, which now makes JSON files from this information as well as lisp files. When the main Python font generation script takes over, it now reads from those JSON files, putting glyphs where they belong according to SMuFL’s name-to-codepoint associations. It also creates, from the same information, a new, SMuFL-compliant metadata file. (The lisp files are now placed inside this metadata file as strings, instead of being embedded in the font as tables. In time, they can be removed, but only once all their information can be properly retrieved from elsewhere in the metadata.)

After that, I reworked the way LilyPond looks up glyphs. Instead of searching for a glyph with a particular lilypond-style name, it now converts the lilypond-style name to a SMuFL-style name, converts the SMuFL-style name to its corresponding code point, and then finds the character with that code point. A bit convoluted, but necessary for full compatibility with SMuFL fonts.

Metadata storage

A music font contains more than just glyphs. It also has to define the staff thickness, stem thickness, bar thickness, and a host of other such metrics that work best with its glyphs. LilyPond has historically embedded lisp tables in the font file to provide this information, but of course this would be bad news for a program that doesn’t read lisp!

SMuFL specifies a font’s metadata to be contained in a JSON file, separately from the main font file. It includes the necessary metrics, as well as lists of “optional characters”–characters not given an explicit codepoint in SMuFL–and their codepoints. As part of this summer’s project, I created metadata files for each of Emmentaler’s size variations and (mostly) removed the need for the old lisp tables. I have not yet included all of the recommended metrics, so that’s on the list for what to do next.

Noteheads, Stems and Flags

One place in which LilyPond and SMuFL differ significantly is their treatment of stem attachment. Before my work, Emmentaler defined a single stem attachment point for each notehead, on the right side of the glyph. This would be used for upwards stems. If a note’s stem faced down, LilyPond would reflect that point across the center of the notehead before using it. This worked well enough, although it required Emmentaler to define two separate glyphs whenever a notehead wasn’t totally symmetrical.

SMuFL, on the other hand, requires a glyph have a separate attachment point for each stem direction from the start, so that no glyphs have to be duplicated. It also expresses the attachment point in units of staff spaces, a more universal measurement than LilyPond’s.

To bring LilyPond closer to SMuFL, I introduced a couple new variables to Emmentaler’s METAFONT files: chardwx and chardwy. These serve as downwards-stem variants of the existing charwx and charwy stem-attachment coordinate variables for each glyph. If they haven’t been explicitly defined by the end of each glyph definition, they are assigned to the values of charwx and charwy, reflected around the center of the glyph. Then, I told LilyPond to stop doing the reflection itself, and just read from the appropriate point from the get-go.

That wasn’t the end of my troubles with stems, though. The first time I got Bravura to load into LilyPond, the flags on standalone eighth notes looked larger than they should have been. This was strange, as everything else was scaled correctly. It turned out that the noteheads’ flags were attached to the right edge of the stem instead of the left side! This made the gap between the Bravura flag and the stem bigger, which, in turn, created the illusion that the flag itself was scaled too big.

Emmentaler and LilyPond are built assuming a flag will be attached to the right side of its stem. That way, if you want to make a stem thicker or thinner, the flag will still be positioned well. However, SMuFL expects flag glyphs to be attached to the left side of the stem, allowing font designers to customize the look of a flag all the way to that side if they want. Making the distinction for this in LilyPond’s code was fairly simple, but the ordeal did highlight an ongoing discrepancy between Emmentaler and SMuFL that will have to be addressed in the future if we’re going to make Emmentaler fully SMuFL-compliant.

Using Bravura

To use Bravura (or any SMuFL-compliant font), a little setup is needed, as I haven’t yet told LilyPond where to look for installed SMuFL fonts. First, you’ll need to make sure both the .otf font file and .json metadata file have the same (case sensitive) base name, e.g. bravura.otf and bravura.json. Move them into your LilyPond installation’s font directory, .../share/lilypond/current/fonts/otf/, then place the following snippet in a \paper {} block in your score:

#(define fonts
   (set-global-fonts
    #:music "bravura"
    #:has-sizes? #f
    ))

(The new has-sizes? property tells LilyPond that Bravura doesn’t come in multiple size variations, like Emmentaler does.)

And… Bravo(ura)! Notes, rests, accidentals, clefs, and articulations should appear correctly for the most part. Braces, numeric time signatures, dynamics, and ancient notation are not yet supported.

New Features!

Since the Lily-style names don’t cover every glyph defined in SMuFL (and can never hope to cover every optional glyph a font maker might choose to make), I added a few new functions to LilyPond, allowing a user to find glyphs by their SMuFL-style names:

  • \smuflglyph, a markup function and a counterpart to \musicglyph. Prints a glyph with the given SMuFL-style name.
  • ly:font-get-smufl-glyph, a Scheme function and a counterpart to ly:font-get-glyph. The only difference is that it takes a SMuFL-style name instead of a Lily-style name as an input. \smuflglyph depends on this function.
  • ly:font-convert-glyph-name, a Scheme function that translates a given Lily-style name to a SMuFL-style name, if it can. If it can’t find a suitable SMuFL name, the function returns the original input unchanged.

The Bumpy Road

This all looks good on paper, but of course my actual coding process was much messier. I started from scratch, with no knowledge of LilyPond’s inner workings. It took a great many Ctrl-F’s and “Find references” calls in my IDE of choice before I began to see the map of what goes where throughout the main C++ codebase.

To edit Emmentaler, I had to learn about METAFONT, a little-known sister language to TeX. It has some real quirks when it comes to operator precedence and variable definition that I haven’t seen in more modern languages, which made it quite a challenge to work with. For instance, -1[x1, x2] is not, as it might seem, (-1)[x1, x2], but instead -(1[x1, x2])!

Along with that learning process, I also made many mistakes working with git, rendered my virtual machine workspace useless for three entire work days, and almost burned myself out thanks to an unhealthy work schedule one week. But hey–mistakes are the way you learn, right? This was my first time working with someone else’s code, so I’m grateful for everyone’s patience with me as I learned the ropes of software development.

Next Steps

Since I wasn’t able to make Bravura a full drop-in replacement for Emmentaler over the summer, I’m willing to put in some volunteer hours to finish the job. For your edification (and in case I fall off the grid and someone else has to carry on my work), here’s a list of things I haven’t gotten to yet, in roughly descending order of urgency:

  • Emmentaler
    • Make sure each category of glyphs (noteheads, rests, etc.) is positioned and scaled correctly.
    • Make Emmentaler’s dynamic letters and time signature numbers occupy the correct code points (currently they’re found in the Basic Latin table as if they were regular letters and numbers).
    • Associate Parmesan (a subset of Emmentaler for ancient notation) glyphs with their proper SMuFL names and codepoints.
    • Fill all metrics in the metadata.
    • Combine the brace font into the main font, encoded appropriately; zip all size variations together as an OpenType Collection.
    • Give Emmentaler a `liga` OpenType table, for ligatures (glyphs that are combinations of two or more other glyphs).
    • Generate an Emmentaler-text font variations, with different metrics as SMuFL specifies.
  • LilyPond
    • Add support for SMuFL fonts’ dynamic letters and time signature numbers.
    • Add support for SMuFL fonts’ braces.
    • Add support for metrics found in metadata.
    • Have LilyPond look for SMuFL-compliant fonts and metadata where they should be installed on a given OS.
    • Add Scheme functions for easy access to metadata information.
    • Support text variations of SMuFL fonts, i.e. Bravura-text.otf. These font variations have different scaling and are recommended by SMuFL for use within lines of text.
    • At the moment, some C++ functions take a Lily-style name as an argument, while others take a SMuFL-style name. It would probably be better to consistently use SMuFL names when possible, though this is up for discussion.

Thanks

Thank you to Werner Lemberg, my mentor, for guiding me through the project, and to the rest of the LilyPond dev community for helping me out of many tight spots!

Working on LilyPond was fulfilling in itself, but by far the best part of the summer was getting to work with so many bright minds who have similar interests to mine. I mean, come on–music, typography, and coding in the same place? You don’t get that every day. Just being around other people with that same combination of interests as my own–and much more experience with them–pushed me to code better than ever before.

I hope that, amid my college schedule, I can continue improving LilyPond with the rest of the developers–just not on a time crunch from now on. Summer’s over!

by Owen Lamb at August 30, 2020 09:46 PM

August 21, 2020

GStreamer News

GStreamer 1.17.90 pre-release (1.18 rc1)

The GStreamer team is pleased to announce the first release candidate for the upcoming stable 1.18 release series.

The unstable 1.17 release series adds new features on top of the current stable 1.16 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework.

The 1.17.90 pre-release series is for testing and development purposes in the lead-up to the stable 1.18 series which is now feature frozen and scheduled for release soon. Any newly-added API can still change until that point, although it is very rare for that to happen at this point.

Depending on how things go there might be another release candidate next week and then hopefully 1.18.0 shortly after.

Full release notes will be provided in the near future, highlighting all the new features, bugfixes, performance optimizations and other important changes.

The autotools build has been dropped entirely for this release, so it's finally all Meson from here on.

This pre-release is for all developers, distributors and early adaptors and anyone who still needs to update their build/packaging setup for Meson.

On the documentation front we have switched away from gtk-doc to hotdoc, but we now provide a release tarball of the built documentation in html and devhelp format, and we recommend distributors switch to that and provide a single gstreamer documentation package in future. Packagers will not need to use hotdoc themselves.

Instead of a gst-validate tarball we now ship a gst-devtools tarball, and the gstreamer-editing-services tarball has been renamed to gst-editing-services for consistency with the module name in Gitlab.

Packagers: please note that plugins may have moved between modules, so please take extra care and make sure inter-module version dependencies are such that users can only upgrade all modules in one go, instead of seeing a mix of 1.17 and 1.16 on their system.

Binaries for Android, iOS, Mac OS X and Windows are also available at the usual location.

Release tarballs can be downloaded directly here:

As always, please let us know of any issues you run into by filing an issue in Gitlab.

August 21, 2020 06:00 PM

July 31, 2020

KXStudio News

KXStudio Monthly Report (July 2020)

Hello all, another monthly report about the KXStudio project is here.
This actually covers June and July, since there was not much to tell during June.

So... first, for those that did not notice, there was quite a few linux/opensource-audio releases on July 15, for the Quarterly Release Pact.
The "Quarterly Release Pact" is an informal agreement between developers to do releases of as much software as possible on a common day.
This is a nice way to:

  • Keep the software in the public eye
  • Increase trust, as people see that the software is in development and is cared for
  • Increase motivation of the developers, as seeing a group working (by their releases) is a good way to push them to do something too
  • Engage in a kind of "Swarm Marketing": A small release does not have much impact and won't get featured often by news sites, but a whole group of software releases demands more attention.

I can speak for myself that the release day is a great motivator to push releases.
When such date is near, everything that has reached a certain point where a release is perhaps worth doing (but usually would be hold-off due to not being "perfect enough"), just gets released.
Because to be fair, there is no point on holding off a release for long periods of time.
If something really goes wrong, a quick bug-fix can be done, so why not. It is software, these things happen sometimes..

With that in mind, the DISTRHO-Ports and WineASIO projects got new releases.
I worked (with some help) to move the DISTRHO-Ports build system from the super-old premake3 build system to meson.
While irrelevant for users, it is very important for Linux distribution packagers because premake3 is simply no longer maintained (and thus not even installable in some cases).
The other changes were not really that substantial in my view, but why not release anyway?
As someone who has done a few packages myself, I can understand the pain of those that want to package something but have their work made difficult by this kind of problem.
(If all goes well, DISTRHO-Ports provided plugins will be installable as packages in the next Ubuntu version already!)

DISTRHO-Ports has been reworked in a way so that we can keep the existing plugins untouched, while adding/supporting new plugins made with JUCE6.
The "legacy" plugins will have LV2 and VST2 formats, while new ones will support LV2, VST2 and VST3.
I plan to write a tutorial on how to add a plugin to this project, so that other people than me can contribute.
This will increase the number of ported plugins drastically, as it does not have to wait on me to to do it. (I have a lot on my plate already..)
Once we have a good number of new plugins, or the next release day comes (in 3 months), you can count on yet another release! :)

Regarding The WineASIO, it was ready for release for some time, so I did the release in more of a "why not?" state.
You can read more about this release here, but in short, I am now maintaining the WineASIO project. :)
This is because the previous maintainer wished to step down doing so, and I was already fixing WineASIO for packaging in the KXStudio repositories anyway, which basically involves maintaining it.
It is important to note that it is really only maintaining the code (so that it keeps working on new Wine versions).
So there is not going to be any new features added to it, only bug-fixes.

In other news, Carla 2.2 Release Candidate 1 is out.
It was a bit more rushed than I wished for, with a late release because I had to fight with some macOS incompatibility issues.. but that should not happen too much in the future.
I already have in mind what to focus on for version 2.3, but I really hope that with this 2.2 release I can kinda already leave Carla a bit on the side (which was already supposed to have happened in version 2.1 by the way), because other projects really need my attention right now.
The final Carla 2.2 release is just siting on a timer now in a way.
My target is to make it available for Ubuntu 20.10, so I will fix whatever bugs I can until the time arrives for Ubuntu 20.10 package freeze. (So final release in October 2020)

Unrelated to the release pact now, I am working on automated builds for a few projects, learning along the way how that is usually handled.
This is not that useful for Linux users, because distributions can build and package up stuff quickly; it is more for macOS and Windows users for whom it is much harder to build stuff.
The automated builds will cover plugins (distrho-ports, dpf-plugins and more), Carla and even JACK.
It is not completely ready yet, but very, very close to done. Expect a few announcements regarding this in the coming weeks!

Something I need to mention... I know people have been asking about an ardour package update (in KXStudio repositories).
I will get to it eventually, yes, sorry for the delay.
Ardour is a different kind of build, so I need to find a nice way of handling it. (I want to repackage the official binary, as authors are ok with it)
Previously it was all very manual work, it is better to avoid that this time around.
My focus in the past few weeks has been on Carla and now the automated build setups, so packaging got put aside for now.

And speaking of packages, here is the list of updates and additions in regards to June and July 2020:

  • helio-workstation added
  • new-session-manager added, replaces non-session-manager
  • fluajho updated to 1.6.1
  • lsp-plugins updated to 1.1.24
  • mod-host updated to latest git
  • patroneo updated to 1.6.1
  • sequencer64 updated to 0.96.8
  • vico updated to 1.2.1
  • x42-plugins updated to 20200714
  • zam-plugins updated to 1.13

That is all for now, stay safe and sane out there!

by falkTX at July 31, 2020 08:56 PM

July 30, 2020

Midichlorians in the blood

VMPK: MIDI by Network

This is only a quick and dirty article to link to the MIDI by Network page in the VMPK Wiki. It explains the basic concepts about ipMIDI and how to use it with VMPK.

The Wiki has also pages about the VMPK developing environment using Qt Creator and CMake.

by Pedro (noreply@blogger.com) at July 30, 2020 06:19 PM

July 22, 2020

News – Ubuntu Studio

Major Backports Update

For those of you using the Ubuntu Studio Backports Repository, we recently had a major update of some tools. If you’ve been using the Backports PPA, you may have noticed some breakage when updating via normal means. To update if you have the Backports PPA enabled, make sure to do... Continue reading

by eeickmeyer at July 22, 2020 07:38 PM