planet.linuxaudio.org

Impressions from last Saturday’s (20.April 2024) concert by Elektronengehirn in Aarhus. Pictures by Morten Slet.

Hi all,

qpwgraph v0.7.0 (spring'24) is out!

Change-log:

Whether to show the System-tray informational and/or active Patchbay warning messages, respectively on Close and/or Quit, is now optional (cf. Help > Enable System Tray Message and/or Help > Enable Patchbay Message, resp.)
Introducing the View/Thumbview option as a whole graph thumbnail overview helper.

Description:

qpwgraph is a graph manager dedicated to PipeWire, using the Qt C++ framework, based and pretty much like the same of QjackCtl.

Project page:

https://gitlab.freedesktop.org/rncbc/qpwgraph

Downloads:

source tarball:
qpwgraph-0.7.0.tar.gz
qpwgraph-0.7.0.tar.gz.sig
source package (openSUSE Tumbleweed):
qpwgraph-0.7.0-36.1.src.rpm
binary package (openSUSE Tumbleweed):
qpwgraph-0.7.0-36.1.x86_64.rpm
Flatpak package:
https://flathub.org/apps/details/org.rncbc.qpwgraph

Git repos:

https://gitlab.freedesktop.org/rncbc/qpwgraph.git (official)
https://github.com/rncbc/qpwgraph.git
https://gitlab.com/rncbc/qpwgraph.git
https://codeberg.org/rncbc/qpwgraph.git

License:

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

Cheers!

VCV Rack, the free and open-source virtual module platform, gets a tidy refresh with input cable stackings and cable color customization. That input stacking opens up more than you might think, too.

The post VCV Rack 2.5: powerful stackable inputs, cable color customization appeared first on CDM Create Digital Music.

Hey, Paul here. I’ve become a little concerned that the public impression of Ardour recently has been dominated by cases of entirely valid bug reports that go unnoticed and unresolved. Someone who is not quite connected to our development process might understandably get the sense that we’ve stopped working on the software.

This is absolutely not the case. Instead, what has been going on is that for the last several months, both myself and @x42 have been involved in work that has no immediate payoff for Ardour but we believe has long term significance. This has been going on in several development “branches”, and below I’ll go over these branches and what we’re up to:

“Pianorule” : this branch contains a massive refactoring and rearrangement of code so that we can implement MIDI editing anywhere we feel like it, without duplicating code. This is primarily focused on providing a MIDI editor for the cue (“clip”) page, but may later make it feasible to add a standalone “piano roll editor”. This branch is currently stuck because the changes have exposed that the (hidden) assumption that the left edge of the editor track canvas is zero on the timeline has turned into a much more pervasive part of our code than was ever intended.
“cliprec” : this branch is rather young but is a test bed for ideas about how to do clip recording in Ardour. This is surprisingly hard to do correctly, mostly because of assumptions and decisions that go back to the early 2000s. We have some good ideas though, and I’m optimistic that the experiments going on will land successfully.
“livetrax” : this is where @paul has been focused for much of the last month, and is a resuscitation of the ideas behind Waves Tracks Live, a commercial GPL’ed product from about 2015 that was based on Ardour. There is a vague idea that this will become an additional DAW available from both ardour.org and also from other commercial partners. The main idea for WTL is that is a “front-of-house” recording tool for live sound engineers. It has no plugin support, no MIDI support, and is massively simpler to use than Ardour. It also has a clever trick to help with so-called virtual soundchecks, where you use a recording of a previous live gig to do most of the work for a soundcheck at the current one.
“mode-clamping” : this is where experiments with adding ideas orbiting the concept of “this thing has a scale” are happening. This is much more complex than most people imagine when they voice their desire to “tell Ardour what scale I’m using”. Lots and lots of music from all over the world doesn’t work with scales in a simplistic way (even a lot of western pop). Currently the most promising idea is a heirarchy of objects that can each have their own scale, starting at the session level and going all the way down to individual regions. If a scale is not assigned, an object inherits one from its parent (ultimately the session).
“region-fx” : @x42 has been busy with adding per-region plugins in this branch, and it is currently being tested/evaluated by some of our early beta-testers.

On top of all this, both myself and @x42 were quite involved in the work done on Ardour to provide support for Dolby Atmos now present in Harrison Mixbus 10. Sadly because Atmos is proprietary technology, Ardour itself cannot use this work at present. Nevertheless, we designed things so that should somebody create something broadly equivalent that is GPL compatible, it would be relatively easy to make it work with Ardour.

So, that’s what’s going on in the background. All this stuff does tend to mean that most new bug reports are not being attended to, and many already-known bugs too. Obviously if we had a larger development group, we could be doing both types of things, but we don’t, and so we aren’t. I’m not offering to change what we do, but let us know what you think of this prioritization/allocation of resources.

12 posts - 9 participants

Read full topic

Every once in a while I get the urge to reminisce about a past project. So, today let’s look back on one of my favorite projects from my undergrad computer engineering degree:

Building a Custom CPU Because Writing Software Was Easier Than Designing Hardware

One of my lab courses focused on building a collection group projects with increasing complexity for each one. Most of them ended up being games with a focus on a FPGA development board, a serial connection, and some custom software running on a desktop computer. The individual projects that have stuck around in my mind are:

A GAL (Generic Array Logic) and discrete component based traffic light control system with a pedestrian button.
An etch a sketch application where the FPGA acted as a hardware controller and the desktop computer translated move operations and whether the cursor was depressed into a displayed image
A game of hangman where the hardware system read key events from a PS1 keyboard and then submitted full words as guesses to the computer for updating the display.
A signal capture tool using an ADC/DAC set of chips with an on desktop visualizer
A student selected project which for my team was a two player game of pong displayed on an analog oscilloscope.

The whole sequence of projects started out with a GAL+discrete logic based assignment. We were tasked with building up a system for a standard 4 way intersection with an set of pedestrian crossings and associated pedestrian crossing request button.

We had lookup tables in the GAL, counters, timers, logic to decode our state into which lights were on, binary to 7 segment decoder chips, it was a lot. As you might be able to see what we might have needed the most was some more rigor in terms of our wiring job, but we managed to complete the task. The project was a combination of loosely planning things and organically patching any mistakes we had made while watching the system through a logic squid. It was remarkable how much physical devices slowed down development.

The subsequent projects took us one step back from 80s style of physically building out logic and defining it in a hardware description language, namely VHDL. This sped things up considerably, though the tooling available to students was subpar at the time, so I wanted to make another technological leap and move into software. That required us to have a CPU of some sort and the assignments were always about turning in the hardware description of a system, so it couldn’t be imported from a project like OpenCores. I knew from my tinkering in open source software that the later projects would be either take less time or be more fun with a basic CPU that could be reused from project to project, so I set off and made one. Certainly it was creating something bespoke with no online resources, but at the time resources for VHDL were *sparse*.

The classes focused around state machines, so how much harder could it be to build up a programmable state machine? A computer or in our case a very very terrible minimal computer was born. The CPU itself was copied between projects with near zero changes and just enough custom peripherals were created per assignment to get the system over the finish line.

System Overview

The DE1 development board we worked with has a bunch of LEDs, some switches, a few momentary buttons, some RAM, and a few electrical connections to the rest of the world in the form of a serial port, a PS2 keyboard connection, and some general purpose IO pins. There are some other bells and whistles, but they aren’t particularly relevant.

The custom Mark 1 CPU was built to handle the orchestration between these peripherals and was as simple as you could reasonably get. At the time I was often tinkering around with some of the AVR processors and I enjoyed dealing with the simplicity of an 8 bit system, so I made the Mark 1 a fully 8 bit system. 8 bits of addressable memory, 8 bits of addressable program ROM, and only 4x8 bit or less registers. By the last project the instruction set had grown to 22 opcodes and it was running at a blazing fast 50MHz. It was certainly stripped down with no interrupts, no relative jumps, no pipelines, and no variable cycle instructions, but it worked well enough for the course.

Architecture

The CPU was thoroughly an 8-bit system, 8-bit addressable memory, 8-bit program ROMS, 8-bit operands, and four 8-bit or less registers.

the Status register (SR)
the general purpose register (REG)
the indexing register (IDX)
the program counter (PC)

SR stored system flags such as the is-equal flag, the is-zero flag, and other application specific flags. REG is used to for general loading from memory, arithmetic operations, comparisons, and temporary storage. IDX is used for stack management, indirect memory access, and iteration. PC is used to track the current position in the system ROM, which determines the current instruction; In other systems this is referred to as an Instruction Pointer (IP).

Memonic	Arg.	PC	SR	REG	IDX	ALU	Bus	Cycles	Notes
read	Ar	.	.	W	.	i..	R	2	$REG := (Ar)
load	V	.	.	W	.	i..	.	1	$REG := V
send	Ar	.	.	R	.	i..	W	1	(Ar) := $REG
test	V	.	W	.	.	i..	.	1	\$SR ⇐ $REG==V
jsrr	.	W	.	R	.	…	.	1	\$PC := $REG
goto	Ap	W	.	.	.	…	.	1	\$PC := Ap
brnz	Ap	W	R	.	.	i..	.	1	$PC := Ap if $REG!=0
brzz	Ap	W	R	.	.	i..	.	1	$PC := Ap if $REG==0
breq	Ap	W	R	.	.	i..	.	1	$PC := Ap if $SR.equal is true
brc0	Ap	W	R	.	.	i..	.	1	$PC := Ap if control 0 is true
brc1	Ap	W	R	.	.	i..	.	1	$PC := Ap if control 1 is true
addd	V	.	.	RW	.	i.F	.	1	\$REG := $REG + V
subx	V	.	.	RW	.	i.F	.	1	\$REG := $REG - V
spsh	V	.	.	.	RW	ii.	W	1	($IDX++) := V push V to stack
rpsh	.	.	.	R	RW	ii.	W	1	(\$IDX++) := $REG push $REG to stack
spop	.	.	.	W	RW	id.	R	2	$RED := (--$IDX) pop value to $REG
lspt	V	.	.	.	W	i..	.	1	\$IDX := V load stack pointer
sidx	V	.	.	.	W	i..	.	1	\$IDX := V set index
iidx	.	.	.	.	RW	ii.	.	1	\$IDX := $IDX+1
lidx	.	.	.	W	R	i..	R	2	\$REG := ($IDX)
swap	.	.	.	RW	RW	i..	.	1	swap(\$REG,$IDX)
trap	.	W	W	W	W	…	.	1	Reset system
noop	.	.	.	.	.	i..	.	1	Do nothing

R(ead), W(rite), .(nothing), V(alue), Ar(Address/RAM), Ap(Address/Program), ALU (PC-IDX-REG) i(ncrement ALU), d(ecrement ALU), F(ull ALU)

22 instructions in total for the final version of the Mark I that’s I’ve got code for considering lspt and sidx are identical. No opcode encoding work was done, that was left to the VHDL generation tools, but opcodes could easily be 8 bits to fit with the overall theme of the project

One challenge of working with this instruction set was that relative jumps are not in the instruction set which means that a list of destination addresses needed to be maintained. Most code modifications were painful if it shifted code by even one address, so the Mark I CPU even has an assembler, but I’ll get to that a bit later.

Peripherals

You might notice that the CPU only interacts with registers, the 256 bytes of memory, and a few control lines with those branch instructions. So how does it work with the rest of the IO world? Memory mapped peripherals. Similar to embedded microcontrollers if the CPU writes to a given 'magic' address it is going to be writing or reading values in a peripheral. Heck, even memory is a peripheral in our case. For most of the projects this CPU was used in we were required to use the SRAM chip on the DE1 board.

Since I’ve lost some of the code used with the Mark I based CPU projects I don’t have an exhaustive list, but I can find evidence of memory mapped peripherals for:

SRAM : General purpose memory
Debug interface : manually Stepping the CPU and visualizing the address/data lines
A timer : for accurately and regularly tending to tasks. This peripheral had to be polled since no interrupts exist in this CPU
A UART : for communicating to computers over a serial link
Beeper : for making sounds when a player has done an action in games
Vector graphics video driver with selectable VROM banks : For rendering graphics on X/Y mode oscilloscope outputs
PS2 keyboard driver : for typing in commands
A character LCD driver : for displaying what uses have typed
A seven segment display driver : typically for visualizing debug information
User input buttons : for binary user inputs or for stepping through the code at low speeds (It’s pretty hard to visualize things by eye at 50 MHz)

If I attempt to build another CPU in the future I expect a huge portion of the time will focus on the debug interface. I personally find them delightful. For a particularly good set of examples take a look at the Magic processor’s front panel or the currently available PDP-11 replica front panels by Obsolescence Guaranteed. In fact the user interface component is a delightful space to explore for complex systems whether that’s processors, synths, control systems, or some other complex system that needs to precisely communicate information to a skilled user.

Assembler & Examples

The assembler itself is pretty trivial with most of the point being tracking the addresses of assembled instructions. In fact almost all of the meaningful bits of it can be seen in these yacc/lex snippets:

asm.y The primary grammar of the assembler

program:
       program statement '\n'
       |
       ;
statement:
         express
         | label express
         | label
         | directive
         |
         ;
directive:
         EQU SYMBOL NUMBER {$2->val=$3;}
         | START {pass++;pc=0;}
         | SRC SYMBOL {if(pass>1) printf("--%s\n",$2->name);}
         ;

express:
       OPCODE          {line($1, 0x00);}
       | OPCODE SYMBOL {line($1, $2->val);}
       | OPCODE NUMBER {line($1, $2);}
       ;
label:
     SYMBOL ':'        {$1->val=pc;}
     ;

asm.lex the tokenization of the assembler

;.*         /*Ignore comments*/
[ ]+            /*Ignore whitespace*/
iidx|read|test|swap|spop yylval.string=strdup(yytext); return OPCODE;
load|send|nopp|goto|subx yylval.string=strdup(yytext); return OPCODE;
rpsh|rpop|spsh|trap          yylval.string=strdup(yytext); return OPCODE;
addd|brc[0-2]|jsrr|breq|sidx yylval.string=strdup(yytext); return OPCODE;
brnz|brzz|lidx yylval.string=strdup(yytext); return OPCODE;
#[0-9a-fA-F]+   sscanf(yytext+1,"%X",&yylval); return NUMBER;
%[0-9a-zA-Z]    yylval.number = (char) yytext[1];    return NUMBER;
[_a-zA-Z]+      yylval.sym=intern(yytext);    return SYMBOL;
^\.start        return START;
^\.equ          return EQU;
^\.src          return SRC;
:               return *yytext;
\n              return *yytext;

A program consists of a sequence of statements. Those statements are either labels for code to jump to, opcodes with optional arguments, definitions of constants, or definitions of functions which are printed as comments in the generated code. Easy enough for something as low level as an assembler, right?

So, what does a real program look like? Well, let’s look at a slightly modified assembly project. Before looking at the code this is from the project where a collection of analog values are read, then transmitted over a serial connection to be displayed on a PC.

To start off, let’s look at some constants:

Assembly section 1

;Define constants
.equ        UART_TX     #02
.equ        LEDS        #01
.equ        ADC         #06
.equ        STACKP      #21
.equ        STACK_H     #F0
.equ        BINTOASCII  #08
.equ        ASCII_H     #09
.equ        ASCII_L     #08
.equ        TMP_SEND    #A2
;brc0 is uart ready send

In this program the CPU has a few system peripherals: 1. A set of on board LEDs to display running values of our input memory mapped at 0x01 (write only) 2. The serial link to the computer (UART) memory mapped to address 0x02 (write only) 3. The analog to digital chip mapped at 0x06 (read only) 4. A binary to ascii-hex conversion ROM mapped at 0x08 (input) and 0x08..0x09 (output)

In addition the stack that is used to store data which is sent to the PC is 0x21..0xF0, which should correspond to 103 8 bit values (in hex) and a null terminator.

In addition, there is a set of comments that indicate that the UART is connected to the CPU’s control line 0 to signal when data can be sent.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INIT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
init:
            sidx STACKP     ;config stack
            spsh #4D        ;'M'

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        MAIN_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
main:
            goto inputs
in_ret:     goto outputs
out_ret:    goto delay
del_ret:    goto main

The beginning of the program initializes the array/stack which is used to store data which will be transmitted and then it establishes the main program flow. inputs are collected, the input is output to the computer, the system waits, and then it repeats the process.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        INPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
inputs:
            read ADC        ;Get analog value
            nopp

            send BINTOASCII ;Convert to ascii
            send LEDS
            read ASCII_H
            nopp
            rpsh            ;Push values onto stack (char*)
            nopp
            read ASCII_L
            nopp
            rpsh

            swap
            test STACK_H    ;Check for end of loop
            swap
            breq send_data
send_ret:   goto in_ret

Ignore the no-operation instructions here, but as the comments indicate data is read from the ADC peripheral. The data is converted into two bytes of hex-ascii (e.g. 0xfa), then stored on the stack. At the end we check to see if the stack pointer is at its maximal value with the test instruction and if it is at that value we go to the next stage, otherwise we keep gathering more input.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        SEND_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
send_data:
            spsh #0A        ;Add new line
            spsh #00        ;Add null terminator
            sidx STACKP     ;Set start of char*
send_loop:
            lidx            ;Read in next value
            nopp
            brzz send_exit  ;Check for null terminator
            send TMP_SEND
wait:       brc0 do_send
            ;do something useful while waiting
            read ADC
            nopp
            send LEDS
            goto wait

do_send:    read TMP_SEND
            nopp
            send UART_TX    ;Transmit data

            iidx
            goto send_loop

send_exit:
            sidx STACKP      ;reset stack
            spsh #4D         ;'M'
            goto in_ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        OUTPUT_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
outputs:    goto out_ret

Now with output we’re getting to point we have something more complex. In the first 3 instructions we establish that we have a null terminated string starting at the constant address STACKP. We now want to send this string byte by byte to the UART. This is done by the send_loop. When a character is sent we have to wait for the UART to be ready for the next byte at which point we stay in the wait loop until the control line 0 indicates we can send the next character. When we do send the data it is moved from the TMP_SEND address to the UART_TX memory mapped device and we repeat the process until the full string has been sent.

Rewritten in C this looks like:

uint_t *stack_pos;
volatile uint_t *led;
volatile uint_t *adc;
volatile uint_t *uart;

void send_data(void)
{
    uint8_t chr;
    (*stack_pos++) = '\n';
    (*stack_pos++) = '\0';
    stack_pos = STACKP;

    while(1) {
        chr = *stack_pos++;
        if(chr == 0)
            break;
        while(uart_busy())
            *led = *adc;
        *uart = chr;
    }
    stack_pos = STACKP;
    (*stack_pos++) = 'M';
}

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.src        DELAY_ROUTINE
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
delay:      load #00
delay_loop: addd #FF
            nopp
            nopp
            brnz delay_loop
            goto del_ret

The delay routine is the last one it counts from 0 to 256 (more or less) and we can calculate how long this should take to execute. The processor runs at 50MHz with one instruction per cycle, one loop is 4 instructions (add+2xno-op+branch). So, 256*4+1+1 (for the initial load and final goto), so roughly 20 micro-seconds. Not much time at all.

Quirks

The processor had its fair share of quirks and general limitations. While this is by no means a comprehensive list a few that were pain points at the time:

It was a 50MHz, all actions on risingedge of clock, nothing on falling edge. The speed was higher than was needed and the lack of falling edge operations resulted in several quirks around reads and writes bleeding into a 2 cycle instruction
No secondary register, so manually allocating the single register to various tasks was
No function call, so returns are verbose operations where the user had to save their variables before placing a return address on the stack and then making sure the called code ends with popping a value from the stack and unconditionally jumping to the current register value
Read is a multi-tick operation and multi-tick instructions do not exist, so no op instructions were manually inserted
Occasional bugs where on some revisions jumps would occur before the program counter was incremented.
256 instructions really isn’t a lot. For basic problems sure, that’s loads and when you can write arbitrary peripherals it’s workable, but I did run out of program space more than once in the development of the final project

Looking back

It’s pretty amazing looking back at the specs for the DE1 board. Those boards are still sold, but they’re a heck of a lot more powerful than they used to be. Reading the spec sheet of the individual FPGA on my board I’ve got 18,752 logic elements and the new FPGA simply specifies 77k logic elements which gives me the sense that students aren’t running into those situations where they’ve exhausted ever logic unit on one of these boards while doing classwork. The newer board doesn’t even need the effort of building a custom CPU since they’ve got a built in ARM core. Heck, the ARM core has access to a full GB of RAM, which is remarkable compared to the 8MB of SDRAM on my board and the 256 bytes of address space of the Mark I CPU.

The Mark I CPU worked, it did its job and while I haven’t made a CPU from raw transistors it got me a decent part of the way there. If I do go all the way to transistors I’m guessing I’ll go down to 4 bits or have the pcb fab assemble the ocean of transistors. Overall it’s a fun space and simple instruction sets are really interesting. I don’t play around with them as much as I used to, but it is a delight to read through ISRs like the z80 or AVR. There’s a beauty to them that is lost in the pragmatic full instruction sets you see in x86/arm/etc.

So, I’ll leave this article here for now. I may well get back to it and edit it some more or extend it, but this has been sitting in my drafts folder long enough that I should put it up on my website before it collects another layer of dust.

Ubuntu Studio remains the quickest one-shot way to get at Linux and free software for music, sound, video, media, and 3D. And they deserve some extra love now, especially since Apple Silicon has slightly deflated desktop Linux attention. Here's a look at the long-term support version that just hit beta, due later this month.

The post Ubuntu Studio in new LTS beta; still the easiest creative Linux distro appeared first on CDM Create Digital Music.

Ardour 8.6 has been released. This is a hotfix release for 8.5, primarily to fix a drawing bug that was not noticed/fixed before 8.5 was released. It also comes with a fix for a crashing bug that can occur when JACK2 is being used.

In all other ways, 8.6 is equivalent to 8.5, but 8.5 should be considered “blacklisted” - we don’t want anyone to have to deal with the drawing issue.

Full release notes (for 8.5 and 8.6) over here as usual.

ADDENDUM: turns out we introduced a bug that ONLY affects macOS Catalina on Intel hardware. The downloads for macOS intel have been updated to include the fix for Catalina. No other changes were made.

21 posts - 10 participants

Read full topic

Hi, twice again!

Now finally making the QStuff* third batch of the blooming season...

Qtractor 0.9.90 (spring'24 aka. v1.0.0-rc1) is released!

Change-log:

Prepping the unthinkable (aka. v1.0.0-rc1)
MIDI Controller mappings are now shown on floating tool-tips.
Custom color themes are now file based (*.conf); legacy still preserved ntl.
Add default GM, GS and XG standard instruments definition file.
Old generic "Portuguese" translation (pt) has been corrected to the more proper "Portuguese (Brazil)" locale (pt_BR).
Up and Down arrow-keys may now be used to change event values on the MIDI clip editor current selection (eg. note velocities).
MIDI clip editor now featuring lollipops for all kind of candy event values ;).
Make the minimum width of events on the MIDI clip editor larger, depending on screen resolution and horizontal zoom setting.
Avoid issuing equivalent MIDI track channel volume and panning via GM standard controllers (CC#7 and CC#10 resp.) to mitigate recursive or positive feedback loops.
Refined mouse-wheel control step size on the sliders of mixer strips and generic/stock plugin editor dialogs.
Fixed the build checks on whether to use old or newer style of LV2 include headers.
Introducing colored strips on the time ruler headers for loop and punch recording ranges.
Fixed an off-by-one(-pixel) mispositioning of selected events, while on the MIDI clip editor (aka piano-roll).

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:

https://qtractor.org

Project page:

https://sourceforge.net/projects/qtractor

Downloads:

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

source tarball:
qtractor-0.9.90.tar.gz
source package (openSUSE Tumbleweed):
qtractor-0.9.90-1.1.rncbc.suse.src.rpm
binary package (openSUSE Tumbleweed):
qtractor-0.9.90-1.1.rncbc.suse.x86_64.rpm
AppImage packages:
qtractor-0.9.90-1.1.x86_64.AppImage
Flatpak package (thanks to Hubert Figuière)
https://flathub.org/apps/details/org.rncbc.qtractor

Git repos:

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

Wiki:

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

static rendering:
https://qtractor.org/doc
user manual & how-to's:
qtractor-manual-and-howtos.epub
qtractor-manual-and-howtos.pdf

License:

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

Cheers && Keep having fun!

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu Studio 24.04 LTS, codenamed “Noble Numbat”.

While this beta is reasonably free of any showstopper installer bugs, you will find some bugs within. This image is, however, mostly representative of what you will find when Ubuntu Studio 24.04 is released on April 25, 2024.

Special Notes

The Ubuntu Studio 24.04 LTS disk image (ISO) exceeds 4 GB and cannot be downloaded to some file systems such as FAT32 and may not be readable when burned to a DVD. For this reason, we recommend downloading to a compatible file system. When creating a boot medium, we recommend creating a bootable USB stick with the ISO image or burning to a Dual-Layer DVD.

Images can be obtained from this link: https://cdimage.ubuntu.com/ubuntustudio/releases/24.04/beta/

Full updated information, including Upgrade Instructions, are available in the Release Notes.

Please note that upgrading before the release of 24.04.1, due August 2024, is unsupported.

New Features This Release

PipeWire continues to improve with every release and is so robust it can be used for professional and prosumer use. Version 1.0.4
Ubuntu Studio Installer‘s included Ubuntu Studio Audio Configuration utility for fine-tuning the PipeWire setup or changing the configuration altogether now includes the ability to create or remove a dummy audio device. Version 1.9

Major Package Upgrades

Ardour version 8.4.0
Qtractor version 0.9.39
OBS Studio version 30.0.2
Audacity version 3.4.2
digiKam version 8.2.0
Kdenlive version 23.08.5
Krita version 5.2.2

There are many other improvements, too numerous to list here. We encourage you to look around the freely-downloadable ISO image.

Known Issues

Ubuntu Studio’s classic PulseAudio-JACK configuration cannot be used on Ubuntu Desktop (GNOME) due to a known issue with the ubuntu-desktop metapackage. (LP: #2033440)
We now discourage the use of the aforementioned classic PulseAudio-JACK configuration as PulseAudio is becoming deprecated with time in favor of PipeWire. PipeWire’s JACK configuration can be disabled to use JACK2 via QJackCTL for advanced users.
Due to the Ubuntu repositories being in-flux following the time_t transition and xz-utils security issue resolution, some items in the repository are uninstallable or causing other packaging conflicts. The Ubuntu Release Team is working around the clock to help resolve these issues, so patience is required.

Official Ubuntu Studio release notes can be found at https://ubuntustudio.org/ubuntu-studio-24-04-LTS-release-notes/

Further known issues, mostly pertaining to the desktop environment, can be found at https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes/Kubuntu

Additionally, the main Ubuntu release notes contain more generic issues: https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890

How You Can Help

Please test using the test cases on https://iso.qa.ubuntu.com. All you need is a Launchpad account to get started.

Additionally, we need financial contributions. Our project lead, Erich Eickmeyer, is working long hours on this project and trying to generate a part-time income. See this post as to the reasons why and go here to see how you can contribute financially (options are also in the sidebar).

Frequently Asked Questions

Q: Does Ubuntu Studio contain snaps?
A: Yes. Mozilla’s distribution agreement with Canonical changed, and Ubuntu was forced to no longer distribute Firefox in a native .deb package. We have found that, after numerous improvements, Firefox now performs just as well as the native .deb package did.

Thunderbird has become a snap this cycle in order for the maintainers to get security patches delivered faster.

Additionally, Freeshow is an Electron-based application. Electron-based applications cannot be packaged in the Ubuntu repositories in that they cannot be packaged in a traditional Debian source package. While such apps do have a build system to create a .deb binary package, it circumvents the source package build system in Launchpad, which is required when packaging for Ubuntu. However, Electron apps also have a facility for creating snaps, which can be uploaded and included. Therefore, for Freeshow to be included in Ubuntu Studio, it had to be packaged as a snap.

Q: If I install this Beta release, will I have to reinstall when the final release comes out?
A: No. If you keep it updated, your installation will automatically become the final release. However, if Audacity returns to the Ubuntu repositories before final release, then you might end-up with a double-installation of Audacity. Removal instructions of one or the other will be made available in a future post.

Q: Will you make an ISO with {my favorite desktop environment}?
A: To do so would require creating an entirely new flavor of Ubuntu, which would require going through the Official Ubuntu Flavor application process. Since we’re completely volunteer-run, we don’t have the time or resources to do this. Instead, we recommend you download the official flavor for the desktop environment of your choice and use Ubuntu Studio Installer to get Ubuntu Studio – which does *not* convert that flavor to Ubuntu Studio but adds its benefits.

Q: What if I don’t want all these packages installed on my machine?
A: Simply use the Ubuntu Studio Installer to remove the features of Ubuntu Studio you don’t want or need!

Ardour 8.5 is available now for Linux, Windows, and macOS. This is another “small” release without major new features, largely because our two lead developers continue to be busy with things linked to future releases.

However, 8.5 does see a fix for a problem in 8.4 that affected many Linux users (a crash whenever a file selection dialog was opened, triggered by the presence of certain icon files on their version of Linux).

Full release notes over here as usual.

9 posts - 5 participants

Read full topic

Hi everyone, a new release for Cardinal is here, 24.04 which focuses on updating the base VCV Rack 2.4 and adds quite a few new modules, bringing the module count to 1193.

Cardinal is a free and open-source virtual modular synthesizer plugin.
It is based on the popular VCV Rack but with a focus on being a fully self-contained plugin version.

cardinal

Changelog

HostMIDI: Add option to force gaps between MIDI input notes
Fix build with latest liblo
Fix Linux VST2 exported symbols
Fix MindMeldModular in wasm/web builds
Force-redraw of all child widgets on dark mode change
Improve Ildaeil/Carla VST3 plugin handling
Improve Ildaeil plugin bridge handling for macOS
Improve Ildaeil plugin scanning
Several fixes for UI size with high-dpi screens
Stop using cardinal-specific settings::darkMode
Tweak default build flags to better match VCV Rack
Update base VCV Rack to v2.4
Use DPF for AU support instead of JUCE
Use GLES2 render target for linux ARM release builds

Module updates

Add Computerscare
Add CVfunk
Add DHE modules
Add Starling Via
Update Befaco
Update GrandeModular
Update HetrickCV
Update Sapphire
Update Surge XT
Update unless_modules
Update ValleyAudio

Downloads

The source code plus Linux, macOS and Windows binaries can be downloaded at https://github.com/DISTRHO/Cardinal/releases/tag/24.04.
Cardinal is released as CLAP, LV2, VST2 and VST3 plugin, plus AudioUnit and JACK/Standalone for certain systems.

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

The GStreamer team is pleased to announce another bug fix release in the new stable 1.24 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and security fixes and it should be safe to update from 1.24.x.

Highlighted bugfixes:

H.264 parsing regression fixes
WavPack typefinding improvements
Video4linux fixes and improvements
Android build and runtime fixes
macOS OpenGL memory leak and robustness fixes
Qt/QML video sink fixes
Windows MSVC binary packages: fix libvpx avx/avx2/avx512 instruction set detection
Package new analytics and mse libraries in binary packages
various bug fixes, build fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.24.2 release notes for more details.

Binaries for Android, iOS, Mac OS X and Windows will be available shortly.

Release tarballs can be downloaded directly here:

The GStreamer team is pleased to announce another bug fix release in the new stable 1.24 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and security fixes and it should be safe to update from 1.24.0.

Highlighted bugfixes:

Fix instant-EOS regression in audio sinks in some cases when volume is 0
rtspsrc: server compatibility improvements and ONVIF trick mode fixes
rtsp-server: fix issues if RTSP media was set to be both shared and reusable
(uri)decodebin3 and playbin3 fixes
adaptivdemux2/hlsdemux2: Fix issues with failure updating playlists
mpeg123 audio decoder fixes
v4l2codecs: DMA_DRM caps support for decoders
va: various AV1 / H.264 / H.265 video encoder fixes
vtdec: fix potential deadlock regression with ProRes playback
gst-libav: fixes for video decoder frame handling, interlaced mode detection
avenc_aac: support for 7.1 and 16 channel modes
glimagesink: Fix the sink not always respecting preferred size on macOS
gtk4paintablesink: Fix scaling of texture position
webrtc: Allow resolution and framerate changes, and many other improvements
webrtc: Add new LiveKit source element
Fix usability of binary packages on arm64 iOS
various bug fixes, build fixes, memory leak fixes, and other stability and reliability improvements

See the GStreamer 1.24.1 release notes for more details.

Binaries for Android, iOS, Mac OS X and Windows will be available shortly.

Release tarballs can be downloaded directly here:

A Crowning Achievement

As 24.04 LTS will represent the eighth Long-Term Support release of Ubuntu Studio and its 32nd release. For this release, we wanted to make sure we got some great representation from the community in terms of wallpaper, and while there weren’t as many entries as our previous competition, we were blown out of the way in terms of quality. While not every wallpaper could be included, all of the entries were solid, and narrowing it down to the best of the best was very difficult.

Revealing The Default

Our long-time art lead, Eylul Dogruel, worked diligently on making a quality textured default wallpaper that not only works well for traditional horizontal screens, but for vertical screens as well without losing quality. We have two variations: one with our logo, and one with the mascot that will be rotated-out for the next four releases.

Now to Crown the Winners!

As stated, this was a very difficult decision, but we would like to congratulate the winners of the competition! The full-quality images will be included in Ubuntu Studio 24.04 LTS and are already in our daily builds of Noble Numbat.

Ultranet is a protocol created by audio manufacturer Behringer to transmit up to 16 channels of 24-bit sound over a Cat-5 cable. It’s not an open standard, though: Behringer doesn’t offer an API or protocol description to build your own Ultranet devices. But that didn’t stop [Christian Nödig], thanks to a defective mixer, he poked into the signals and built his own Ultranet receiver.

Ultranet runs over Cat-5 ethernet cables but isn’t an ethernet-based protocol. The electrical protocols of Ultranet are identical to Ethernet, but the signaling is different, making it a Level 1 protocol. So, you can use any Cat-5 cable for Ultranet, but you can’t just plug an Ultranet device into an Ethernet one. Or rather, you can (and neither device should explode), but you won’t get anything out of it.

Instead, [Christian]’s exploration revealed that Ultranet is based on another standard: AES/EBU, the bigger professional brother of the SPD/IF socket on HiFi systems. This was designed to carry digital audio over an XLR cable, and Behringer has taken AES/EBU and tweaked it to run over a single twisted pair. With two twisted pairs in the cable carrying a 192 kbps signal, you get sixteen channels of 24-bit audio in total over two twisted pairs inside the Cat-5 cable.

That’s a bit fast for a microcontroller to decode reliably, so [Christian] uses the FPGA in an Arduino Vidor 4000 MKR in his receiver with an open-source AES decoder core to receive and decode the Ultranet signal into individual channels, which are passed to an ADC and analog output.

In effect, [Christian] has built a 16-channel mixer, although the mixing aspect is too primitive for actual use. It would be great for monitoring, though, and it’s a beautiful description of how to dig into protocols like Ultranet that look locked up but are based on other, more open standards.

A new version of rtcqs, a Linux audio performance analyzer, is now available. Most notable changes include:

Fixed inconsistent use of single and double quotes
Replaced audio group check with a group agnostic check (fixes #4)
Governor check can now deal with systems that have SMT disabled
Tickless check now deals with all CONFIG_NO_HZ* variants and with nohz being set on the kernel command line (fixes #8)
File systems check has been expanded
IRQ check now loops through /sys/kernel/irq instead of parsing /proc/interrupts
rtprio check now checks if a SCHED_FIFO priority can be set instead of a SCHED_RR priority
Improved preempt RT check, check if “preempt=full” is part of the kernel command line (fixes #7)
Refactoring, created separate classes for main app, resources and GUI
Moved all packaging directives into pyprojects.toml

While working on this release I found out PySimpleGUI is not open source anymore so rtcqs’ GUI has become a bit of a moving target. I’m looking at alternatives like pygubu or even popsicle but that will be something for in the long run. In the short run there are more improvements in the pipeline. The swappiness check needs some attention and same goes for the IRQ check. I’ve been working on a different project to automate prioritizing IRQs and I’m planning to to reuse some parts of that project for the IRQ check in rtcqs. The idea is to have rtcqs not only list the status of all audio related IRQs but also any audio devices attached to those IRQs.

rtcqs is available on Codeberg, PyPI and is also included in the AUR.

Ardour 8.4 is available now for Linux, Windows, and macOS. Nothing particularly significant in this release, because our two lead developers have been busy with things linked to future releases. (note: there was no 8.3 release due to a critical bug discovered after tagging 8.3).

From a project-level perspective, perhaps the most important change is that we have moved the source code of our GUI toolkit (GTK v2) into the Ardour source tree. This has no impact whatsoever on people using the builds provided at ardour.org.

However, this version of GTK is about to be deprecated by a number of Linux distributions, and without this change it will become more difficult for both individual users and Linux package maintainers to continue building Ardour. This also leaves us free to (slowly) strip down aspects of the toolkit that we do not use, and potentially modify it as needed in the future. It also means that even the distribution builds of Ardour for Linux will contain our patches to GTK, which has historically not been the case.

Meanwhile, we now have beta-level AAF import, some new MIDI device maps, a new color theme, a stack of UX/UI tweaks and several fixes for crashing and workflow bugs.

Full release notes over here as usual.

27 posts - 14 participants

Read full topic

You can do some wild things with sound waves, such as annoy your neighbours or convince other road users to move out of your way. Or, if you get into sonolithography like [Oliver Child] has, you can make some wild patterns with ultrasound.

Sonolithography is a method of patterning materials on to a surface using finely-controlled sound waves. To achieve this, [Oliver] created a circular array of sixteen ultrasonic transducers controlled via shift registers and gate driver ICs, under the command of a Raspberry Pi Pico. He then created an app for controlling the transducer array via an attached computer with a GUI interface. It allows the phase and amplitude of each element of the array to be controlled to create different patterns.

Creating a pattern is then a simple matter of placing the array on a surface, firing it up in a given drive mode, and then atomising some kind of dye or other material to visualize the pattern of the acoustic waves.

It could be a useful tool for studying the interactions of ultrasonic waves, or it could just be a way to make neat patterns in ink and dye if that’s what you’re into. [Oliver] notes the techniques of sonolithography could also have implications in biology or fabrication in future, as well. If you found this interesting, you might like to study up on ultrasonic levitation, too!

planet.linuxaudio.org

April 23, 2024

April 22, 2024

April 21, 2024

April 20, 2024

Building a Custom CPU Because Writing Software Was Easier Than Designing Hardware

System Overview

Architecture

Peripherals

Assembler & Examples

Quirks

Looking back

April 18, 2024

April 17, 2024

April 13, 2024

April 12, 2024

Special Notes

New Features This Release

Major Package Upgrades

Known Issues

How You Can Help

Frequently Asked Questions

April 11, 2024

Changelog

Module updates

Downloads

April 09, 2024

March 21, 2024

A Crowning Achievement

Revealing The Default

Now to Crown the Winners!

March 05, 2024

March 03, 2024

February 21, 2024

February 16, 2024

Subscriptions

Planetarium: