VCV has added a Compressor to the range of effects in the Pro version. That full range is a strong offering, but the unique flexibility of the Compressor might well put it over the top.
The post VCV’s new Compressor rounds out effects modules in VCV Rack Pro appeared first on CDM Create Digital Music.
The GStreamer team is pleased to announce another release of liborc, the Optimized Inner Loop Runtime Compiler, which is used for SIMD acceleration in GStreamer plugins such as audioconvert, audiomixer, compositor, videoscale, and videoconvert, to name just a few.
This is a minor bug-fix release, and also includes a security fix.
Highlights:
Direct tarball download: orc-0.4.39.tar.xz.
by herrsteiner (noreply@blogger.com) at July 19, 2024 12:20 PM
GStreamer Rust bindingsGStreamer Rust plugins
As usual this release follows the latest gtk-rs 0.20 release and the corresponding API changes.
This release features relatively few changes and mostly contains the addition of some convenience APIs, the addition of bindings for some minor APIs, addition of bindings for new GStreamer 1.26 APIs, and various optimizations.
The new release also brings a lot of bugfixes, most of which were already part of the bugfix releases of the previous release series.
Details can be found in the release notes for gstreamer-rs.
The code and documentation for the bindings is available on the freedesktop.org GitLab
as well as on crates.io.The new 0.13 version of the GStreamer Rust plugins features many improvements to the existing plugins as well as various new plugins. A majority of the changes were already backported to the 0.12 release series and its bugfix releases, which is part of the GStreamer 1.24 binaries.
A full list of available plugins can be seen in the repository's README.md.
Details for this release can be found in the release notes for gst-plugins-rs.
If you find any bugs, notice any missing features or other issues please report them in GitLab for the bindings or the plugins.
Hi y'all,
Change-log:
Description:
Project page:
Downloads:
Git repos:
License:
Cheers!
As of July 11, 2024, all flavors of Ubuntu 23.10, including Ubuntu Studio 23.10, codenamed “Mantic Minotaur”, have reached end-of-life (EOL). There will be no more updates of any kind, including security updates, for this release of Ubuntu.
If you have not already done so, please upgrade to Ubuntu Studio 24.04 LTS via the instructions provided here. If you do not do so as soon as possible, you will lose the ability without additional advanced configuration.
No single release of any operating system can be supported indefinitely, and Ubuntu Studio has no exception to this rule.
Regular Ubuntu releases, meaning those that are between the Long-Term Support releases, are supported for 9 months and users are expected to upgrade after every release with a 3-month buffer following each release.
Long-Term Support releases are identified by an even numbered year-of-release and a month-of-release of April (04). Hence, the most recent Long-Term Support release is 24.04 (YY.MM = 2024.April), and the next Long-Term Support release will be 26.04 (2026.April). LTS releases for official Ubuntu flavors (not Desktop or Server which are supported for five years) are three years, meaning LTS users are expected to upgrade after every LTS release with a one-year buffer.
Bitwig Studio, by default, has one love-it-or-leave-it color scheme. There are contrast controls, but that's it. Without an official, supported solution, users have banded together to create their own customization - and some of the themes they're producing look fantastic.
The post Bitwig Studio now has some gorgeous themes, thanks to user mods appeared first on CDM Create Digital Music.
Anklang is a digital audio synthesis application for live creation and composition of music. It runs on Linux and is Free Software.
I’ve created a small YouTube Video for the latest 0.3.0 release. You can watch this if you are curious about how Anklang looks and feels like.
Besides some cleanups and bugfixes, the 0.3.0 release contains
The full list of changes and the release itself can be found on the GitHub Release Page.
After almost a decade of silence, linux audio live is back with more than ever. More skills, more experience, and above all, more determined. Their stage gear has seen a tremendous upgrade: a year-2017 laptop powers a two-in-two-out audio interface. The current line-up counts with an electric guitar and eight midi pads and knobs.
Behind the scenes we can still see SooperLooper running, that beast of a live looping sampler! Guitarix, one of the new members, takes care of all guitar amplification needs. All audio is eventually channeled into jack_mixer, which displays and controls of every single sound going outside.
That roster has proven stable with less than 10 milliseconds latency and things are much easier than in the old times. The first post on linux audio live, in 2008, was a how-to set up real-time kernels, another post on the same topic followed in 2009. Today, real-time kernels work out of the box on all operating systems I’ve tried.
It is exciting to see what lal is going to bring on. There probably will be some visual redesigns, likely one or two new partners, and maybe even new colors and typefaces. Who knows? The table is set and everybody is waiting.
Hi all,
Change-log:
Description:
Project page:
Downloads:
Git repos:
License:
Cheers!
A new version, SpectMorph 1.0.0-beta1 is available at www.spectmorph.org.
The new features of this release are described in a YouTube Tutorial.
SpectMorph (CLAP/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.
The first lines of code for SpectMorph were written in 2009. I also worked full time on SpectMorph for my university thesis. There were many incremental improvements over the years, so at this point, the next stable release of SpectMorph will be 1.0.0. I’d like SpectMorph-1.0.0 to be as stable as possible, so if you test the beta1 version and have any issues with it, please let me know.
In this release, two formant preserving algorithms for repitching vocals were added to the WavSource operator. This means that for user defined vocal instruments, good sound quality over a large midi note range is possible with only a single sample as base. Also with these algorithms enabled, portamento will dynamically adjust the spectral envelope, which means that it sounds more natural.
There are a lot of instruments which have good sound quality only for a certain pitch range. For instance, a trumpet will sound great for high notes, but for low notes, a tenor trombone or bass trombone sounds better. The same is true for bass, tenor and soprano voices. A new KeyTrack operator was added to handle these cases by combining multiple instruments by midi note range. Note that this is not a simple key split, because slopes can be used to morph between the instruments for seamless transitions.
Finally, SpectMorph now supports arbitrary user defined curves. A new Envelope operator was added for modulation envelopes with user defined curves, and the LFO operator also supports them.
If you are interested in a detailed list of changes, you can look at the NEWS file.
If you are interested in even more details, some SpectMorph related issues were discussed in the regular Anklang/SpectMorph developer meetings.
If you missed the introduction of the Axis-49 and Axis-64 keyboards by C-Thru Music, you’re definitely not alone. At the time it was a new musical instrument that was based on the harmonic table, but it launched during the Great Recession and due to its nontraditional nature and poor timing, the company went out of business. But the harmonic table layout has a number advantages for musicians over other keyboard layouts, so [Ben] has brought his own version of the unique instrument to life in his latest project.
Called the Midihex, the keyboard has a number of improvements over the version from C-Thru Music, most obviously its much larger 98 playable keys and five function keys. The keys themselves are similar to Cherry MX keys but which use Hall-effect sensors. This style of key allows the device to send continuous key position information to the host computer, and since this is a MIDI instrument, this capability allows it to support a MIDI protocol called MIDI Polyphonic Expression (MPE) which allows each note to be more finely controlled by the musician than a standard MIDI instrument. The PCB is powered by a Teensy 4.1 at the core.
For any musicians that haven’t tried out a harmonic table before, an instrument like this might be worth trying out. The layout provides easier chord and scale patterns, and for beginner musicians it can have a much shallower learning curve than other types of instruments. If you can’t find an original Axis-49 or Axis-64 anywhere to try out, though, we actually posted a teardown of one way back in 2009 when the company was still producing instruments.
Sometimes, startups fail due to technical problems or a lack of interest from potential investors and fail to gain development traction. This latter case appears to be the issue befalling A3 Audio. So, the developers have done the next best thing, made the project open source, and are actively looking for more people to pitch in. So what is it? The project is centered around the idea of spatial audio or 3D audio. The system allows ‘audio motion’ to be captured, mixed and replayed, all the while synchronized to the music. At least that’s as much as we can figure out from the documentation!
The system is made up of three main pieces of hardware. The first part is the core (or server), which is essentially a Linux PC running an OSC (Open Sound Control) server. The second part is a ‘motion sampler’, which inputs motion into the server. Lastly, there is a Mixer, which communicates using the OSC protocol (over Ethernet) to allow pre-mixing of spatial samples and deployment of samples onto the audio outputs. In addition to its core duties, the ‘core’ also manages effects and speaker handling.
The motion module is based around a Raspberry Pi 4 and a Teensy microcontroller, with a 7-inch touchscreen display for user input and oodles of NeoPixels for blinky feedback on the button matrix. The mixer module seems simpler, using just a Teensy for interfacing the UI components.
We don’t see many 3D audio projects, but this neat implementation of a beam-forming microphone phased array sure looks interesting.
by herrsteiner (noreply@blogger.com) at May 24, 2024 01:33 PM
The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio 24.04 LTS, code-named “Noble Numbat”. This marks Ubuntu Studio’s 34th release. This release is a Long-Term Support release and as such, it is supported for 3 years (36 months, until April 2027).
Since it’s just out, you may experience some issues, so you might want to wait a bit before upgrading. Please see the release notes for a more complete list of changes and known issues. Listed here are some of the major highlights.
You can download Ubuntu Studio 24.04 LTS from our download page.
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 standard 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.
Minimum installation media requirements: Dual-Layer DVD or 8GB USB drive.
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 from 22.04 before the release of 24.04.1, due August 2024, is unsupported.
Upgrades from 23.10 should be enabled within a month after release, so we appreciate your patience.
In cooperation with the Ubuntu Desktop Team, we have an all-new Desktop installer. This installer uses the underlying code of the Ubuntu Server installer (“Subiquity”) which has been in-use for years, with a frontend coded in “Flutter”. This took a large amount of work for this release, and we were able to help a lot of other official Ubuntu flavors transition to this new installer.
Be on the lookout for a special easter egg when the graphical environment for the installer first starts. For those of you who have been long-time users of Ubuntu Studio since our early days (even before Xfce!), you will notice exactly what it is.
Now for the big one: PipeWire is now mature, and this release contains PipeWire 1.0. With PipeWire 1.0 comes the stability and compatibility you would expect from multimedia audio. In fact, at this point, we recommend PipeWire usage for both Professional, Prosumer, and Everyday audio needs. At Ubuntu Summit 2023 in Riga, Latvia, our project leader Erich Eickmeyer used PipeWire to demonstrate live audio mixing with much success and has since done some audio mastering work using it. JACK developers even consider it to be “JACK 3”.
PipeWire’s JACK compatibility is configured to use out-of-the-box and is zero-latency internally. System latency is configurable via Ubuntu Studio Audio Configuration.
However, if you would rather use straight JACK 2 instead, that’s also possible. Ubuntu Studio Audio Configuration can disable and enable PipeWire’s JACK compatibility on-the-fly. From there, you can simply use JACK via QJackCtl.
With this, we consider audio production with Ubuntu Studio so mature that it can now rival operating systems such as macOS and Windows in ease-of-use since it’s ready to go out-of-the-box.
Due to the maturity of PipeWire, we now consider the traditional PulseAudio/JACK setup, where JACK would be started/stopped by Studio Controls and bridged to PulseAudio, deprecated. This configuration is still installable via Ubuntu Studio Audio Configuration, but we do not recommend it. Studio Controls may return someday as a PipeWire fine-tuning solution, but for now it is unsupported by the developer. For that reason, we recommend users not use this configuration. If you do, it is at your own risk and no support will be given. In fact, it’s likely to be dropped for 24.10.
While this does not represent the latest release of Ardour, Ardour 8.4 is a great release. If you would like the latest release, we highly recommend purchasing one-time or subscribing to Ardour directly from the developers to help support this wonderful application. Also, for that reason, this will be an application we will not directly backport. More on that later.
Ubuntu Studio Audio Configuration has undergone a UI overhaul and contains the ability to start and stop a Dummy Audio Device which can also be configured to start or stop upon login. When assigned as the default, this will free-up channels that would normally be assigned to your system audio to be assigned to a null device.
In cooperation with Edubuntu, we have created a metapackage for music education. This package is installable from Ubuntu Studio Installer and includes the following packages:
Thanks to the work of Eylul and the submissions to the Ubuntu Studio Noble Numbat Wallpaper Contest, we have a number of wallpapers to choose from and a new default wallpaper.
As stated in the Ubuntu 23.10 Release Announcement, the Ubuntu Studio Backports PPA is now deprecated in favor of the official Ubuntu Backports repository. However, the Backports repository only works for LTS releases and for good reason. There are a few requirements for backporting:
If you have a suggestion for an application for which to backport that meets those requirements, feel free to join and email the Ubuntu Studio Users Mailing List with your suggestion with the tag “[BPO]” at the beginning of the subject line. Backports to 22.04 LTS are now closed and backports to 24.04 LTS are now open. Additionally, suggestions must pertain to Ubuntu Studio and preferably must be applications included with Ubuntu Studio. Suggestions can be rejected at the Project Leader’s discretion.
One package that is exempt to backporting is Ardour. To help support Ardour’s funding, you may obtain later versions directly from them. To do so, please one-time purchase or subscribe to Ardour from their website. If you wish to get later versions of Ardour from us, you will have to wait until the next regular release of Ubuntu Studio, due in October 2024.
You’ll notice that the menu links to our support chat and on our website will now take you to a Matrix chat. This is due to the Ubuntu community carving its own space within the Matrix federation.
However, this is not only a support chat. This is also a creativity discussion chat. You can pass ideas to each other and you’re welcome to it if the topic remains within those confines. However, if a moderator or admin warns you that you’re getting off-topic (or the intention for the chat room), please heed the warning.
This is a persistent connection, meaning if you close the window (or chat), it won’t lose your place as you may only need to sign back in to resume the chat.
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 also became a snap during this cycle 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: 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!
Ubuntu Studio, in cooperation with Kubuntu, will be switching to Plasma 6 during the 24.10 development cycle. Likewise, Lubuntu will be switching to LXQt 2.0 and Qt 6, so the three flavors will be cooperating to do the move.
Ubuntu Studio has been using the same theming, “Materia” (except for the 22.04 LTS release which was a re-colored Breeze theme) since 19.04. However, Materia has gone dead upstream. To stay consistent, we found a fork called “Orchis” which seems to match closely and will be switching to that. More on that soon.
The new system installer has the capability to do minimal installations. This was something we did not have time to implement this cycle but intend to do for 24.10. This will let users install a minimal desktop to get going and then install what they need via Ubuntu Studio Installer. This will make a faster installation process but will not make the installation .iso image smaller. However, we have an idea for that as well.
We are going to research what it will take to create a minimal installer .iso image that will function much like the regular .iso image minus the ability to install everything and allow the user to customize the installation via Ubuntu Studio Installer. This should lead to a much smaller initial download. Unlike creating a version with a different desktop environment, the Ubuntu Technical Board has been on record as saying this would not require going through the new flavor creation process. Our friends at Xubuntu recently did something similar.
A wonderful way to contribute is to get involved with the project directly! We’re always looking for new volunteers to help with packaging, documentation, tutorials, user support, and MORE! Check out all the ways you can contribute!
Our project leader, Erich Eickmeyer, is now working on Ubuntu Studio at least part-time, and is hoping that the users of Ubuntu Studio can give enough to generate a monthly part-time income. Your donations are appreciated! If other distributions can do it, surely we can! See the sidebar for ways to give!
Huge special thanks for this release go to:
When I started out working on Ubuntu Studio six years ago, I had a vision of making it not only the easiest Linux-based operating system for content creation, but the easiest content creation operating system… full-stop.
With the release of Ubuntu Studio 24.04 LTS, I believe we have achieved that goal. No longer do we have to worry about whether an application is JACK or PulseAudio or… whatever. It all just works! Audio applications can be patched to each other!
If an audio device doesn’t depend on complex drivers (i.e. if the device is class-compliant), it will just work. If a user wishes to lower the latency or change the sample rate, we have a utility that does that (Ubuntu Studio Audio Configuration). If a user wants to have finer control use pure JACK via QJackCtl, they can do that too!
I honestly don’t know how I would replicate this on Windows, and replicating on macOS would be much harder without downloading all sorts of applications. With Ubuntu Studio 24.04 LTS, it’s ready to go and you don’t have to worry about it.
Where we are now is a dream come true for me, and something I’ve been hoping to see Ubuntu Studio become. And now, we’re finally here, and I feel like it can only get better.
-Erich Eickmeyer
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.
a “new” DAW focused on front-of-house operations : 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.
26 posts - 18 participants
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, or as I like to call it:
One of my lab courses focused on building a sequence of group projects with ever increasing complexity. Most of them ended up being games with a focus on an 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, etc. 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 into the era of defining our systems in a hardware description language, namely VHDL. This sped things up considerably, though the tooling available to students was subpar at the time (or at least that was the case at my university), 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 an external 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.
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 four 8-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.
As mentioned before, 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. Those registers were:
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).
Our instruction set can be summarized below:
| 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)
In total these 22 opcodes were in the final VHDL version of the CPU that I was
able to locate (technically 23, but 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.
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 that’s wired onto the main bus. 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
A 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
A vector graphics video driver with selectable VROM banks : For rendering graphics on X/Y mode oscilloscope outputs
A 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.
As mentioned before, the processor does not have relative jumps which makes program modifications tedious if we don’t have an assembler. 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:
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;}
;;.* /*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 from an external chip, then transmitted over a serial connection to be displayed on a PC.
To start off, let’s look at some constants:
;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 sendIn this program the CPU has a few system peripherals:
A set of on board LEDs to display running values of our input memory mapped at 0x01 (write only)
The serial link to the computer (UART) memory mapped to address 0x02 (write only)
The analog to digital chip mapped at 0x06 (read only)
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 mainThe 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_retIgnore 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_retNow 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:
uint8_t *stack_pos;
volatile uint8_t *led;
volatile uint8_t *adc;
volatile uint8_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_retThe 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+2x no-op+branch). So, 256*4+1+1 (for the initial load and final goto), so roughly 20 micro-seconds. Not much time at all.
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 rising edge 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 fiddly
No function call/return opcodes, so subroutine calls 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
It’s pretty amazing looking back at the specs for the DE1 board. Those boards are still sold, but an updated revision. The newer revision is 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 every single logic unit on one of these boards while doing classwork. The newer board don’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 accomplished my personal goal of making 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 and arm.
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.
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.
32 posts - 14 participants
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.
10 posts - 6 participants
A touch of music
Audio – Stefan Westerfeld's blog
Audio, Linux and the combination
Blog - Ardour
FreqRush - experiences with shared audiosoftware
GStreamer News
Home on Libre Arts
Hometracked
Internet Archive - Collection: osmpodcast
JACK Audio Connection Kit News
KXStudio News
Linux Archives - CDM Create Digital Music
Linux Audio Conference 2018
Linux Recording
LinuxMuso
MOD Audio website
Midichlorians in the blood
Musings on maintaining Ubuntu
News – Ubuntu Studio
Nothing Special
OpenAV
PipeManMusic
Robin Gareus
SFZ Format news
SFZTools news
Testbit
Thorwil's
Using Open Source Software For Creative Purposes
aubio
blog4
cSounds.com
digital audio hacks – Hackaday
drobilla.net - LAD
fundamental code
harryhaaren
joebutton.co.uk
linux-audio « WordPress.com Tag Feed
linux_audio – autostatic.com
m3ga blog
process();
rncbc.org
Last updated:
July 27, 2024 03:02 AM
All times are UTC.
Powered by:
