Mixxx

Google Summer of Code 2026, Up-Mixxx your skills with Google

2026-02-24T16:19:24+01:00

We're very proud to announce that Mixxx has been accepted again this year as a mentoring organization for Google Summer of Code 2026, a global program focused on bringing new contributors into open source software development. This means we are ready to welcome candidates and guide them with their first step^s in open source software and through the process of developing a sound proposal. We then devote all our energy to supporting the selected and accepted candidates, hoping their proposals will be successful. Again this is a great opportunity for us to attract new contributors, as they will receive a stipend sponsored by Google. More info about past GSoC projects can be found in other News-posts, eg. about the 2025 project of Anmol: Converting Demucs v4 (Hybrid Transformer) AI model to ONNX format. We look forward to welcome you and discuss possible projects together.

How Does GSoC Work?

Google Summer of Code is a program that enables students to work on open-source projects over the summer, typically lasting between 3 to 12 weeks. Participants are matched with mentoring organizations like Mixxx, where they collaborate on various projects under the guidance of experienced mentors. For more information, check out the Google Summer of Code Contributor Guide.

Contributors will gain hands-on experience by working on an open-source project used by DJs worldwide. This will enhance their skills in software development, collaboration, and project management, which are highly valuable in the professional live. They are supported by experienced mentors and a community of developers and DJs who will help to get the right things done and are ready to clear out any obstacles when they arise.

How to Get Involved?

You will find the GSoC 2026 Project Ideas for Mixxx in our wiki, but your own ideas are also more than welcome. Taking a look at our GSoC advice page is recommended if you're planning to apply, on this page you can find out how to get accepted as a candidate. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our codebase.

You could also help us, even if you are not a GSoC candidate yourself. Simply print out a flyer and post it on the bulletin board of your local university.

If you are interested in past projects, take a look at the blog posts of Anmol Mishra, Antonio Giordano, Armaan Chowfin, their work still needs some fine tuning and adaptation before it can be integrated in the Mixxx-codebase. The work of Antoine Colombier, Daniel Fernandes, David Chocholatý and Fatih Emre YILDIZ has been successfully integrated into Mixxx.

The official application period will start on March 16th and ends on March 31th, so have your applications ready in time. Potential GSoC contributors should start discussing their application ideas on our Zulip now. Just start a new topic in the #gsoc stream. Please understand that we only engage with potential contributors via the respective channels in the #gsoc stream on Zulip or via the official GSoC application process.

Join us in improving Mixxx and contributing to free DJing worldwide!

Mixxx 2.5.4 Released

2025-12-14T22:54:46+01:00

Mixxx 2.5.4 Release Announcement: bundling improvements at the end of the year.

We're proud to share our early Christmas present with you: Mixxx version 2.5.4, a new stable release of Mixxx. This version bundles corrections, improvements and fixes for the issues you reported.
We'd like to emphasize the importance of reporting issues and bugs and testing nightly builds of the beta (bugfix) and alpha (development) versions. This quality control ensures Mixxx continues to improve and ensures stress-free end-of-year sets for every Mixxx-DJ and Mixxx-broadcaster. Thank you for bookmarking our github, forum and zulip.
If you want to join our test-panels, leave a note in the appropriate zulip-topic:

A lot of new users have found their way to Mixxx, all sharing the same passion for music in all forms: tango, techno, experimental electronic, merengue, dubstep, ... For every specific genre DJs are searching for an optimized controller mapping, adapted Auto DJ transitions or effects. Others are still searching their way in the silent darkness, you can help them by sharing your Mixxx experience, your illuminating fire can lead them to Mixxx.
We welcome all users, we want you to DJ your own way.

Have a nice Mixxx.

Highlights: important fixes in 2.5.4

Some examples of improvements and fixes, more fixes have been included to keep everything stable, up and running, and as they were required by operating system updates or Qt improvements. The complete changelog can be found here.

Controller Mappings

Mappings were improved and updated for Korg Kaoss DJ, Numark-NS6II, Pioneer DJ CDJ, Reloop Beatmix 2/4, Traktor S4Mk3.

Library

Playlists: polish code for moving selected Tracks #15454
Playlists: disable all modifying actions when locked #15456
Playlists: improve performance when activating a playlist #15465
Track view header: avoid narrow columns after restoring header with hidden columns #15331 #10325
Computer: fix "Refresh directory tree" action #15301
Library scanner: make Cancel button work again #15320 #14940
Library scanner: fix an issue when verifying remaining tracks #15346

Preferences

Library: reset library font/row height when closing without apply #15455
Decks: fix Restore Defaults for rate slider direction and track time display #15443 #15444
Sound Hardware: don't allow closing preferences with faulty Sound Hardware config #14576 #6077

Target support

Update macOS (Intel) runner for building Mixxx to macOS Sequoia 15 #15391
Welcome Ubuntu 26.04 LTS Resolute Raccoon #15588
debian_buildenv.sh: assert for bash #15274 #15273
debian_buildenv.sh: use /etc/os-release instead of the obsolete /etc/lsb-release #15298
debian_buildenv.sh: fix for Ubuntu Noble (24.10) #15292
Support building with Qt 6.10: Add Qt6::GuiPrivate #15502 #15485
Touchscreen on Windows 11: disable touch -> mouse event translation #15547 #15546

Misc

Cover Art: Fix a rare issue causing an infinite loop and high CPU load when fetching a cover art from metadata failed unexpectedly #15451 #15199
Network Clock: fix writing wrong number of silence after a long underrun #15400
Menu bar: fix showing/hiding via Alt #15352 #15350 #15396 #15385
SoundSourceFFmpeg: Fix opening files with non ASCII characters #15700 #15681

Mixxx Zulip Chat Exceeds 3,000 Members

2025-11-17T11:42:04+01:00

Mixxx Zulip Chat Exceeds 3,000 Members

Since moving our community discussions from our mailing list to Zulip in 2018, we have never looked back. This month, for the first time, we have more than 3,000 registered users in our Mixxx Zulip community!

We now exchange around 4,000 messages every month, something a mailing list could never handle effectively. The community continues to grow steadily, both in users and in activity, with over 60 individuals actively participating in discussions every month.

Zulip has become a solid foundation of our community: a place where developers, translators, designers, and testers meet and collaborate.

Moving to Zulip

Before Zulip, we used Mailman for our mailing list and an IRC channel for instant messages for years, but we ran into several challenges: - Cluttered threading and confusing message flow - No shared cloud storage for files and images - No video chat

As the project and number of contributors grew, we needed a platform that could keep conversations organized and accessible to everyone.

Zulip, which was open-sourced in 2015, was very promising and convinced us after a short evaluation period. Its unique thread system was the ideal solution to replace structured email threads and instant chat rooms.

Whenever a topic drifts, we can split it into a new thread, so conversations stay focused and are easy to follow. This approach makes it possible to collaborate asynchronously across time zones without missing important context. No need to hang around in chat rooms to avoid missing an important conversation.

Thanks to Zulip, it’s now much easier to stay up to date. Our team collaboration and community engagement have both improved significantly. Zulip works particularly well for open-source projects where many topics run in parallel, and where structure and focus are key to success.

In addition to the web interface, Zulip has also a nice mobile app for Android or iOS. It has recently received a major update, a full Flutter rewrite with fast natively compiled code. This allows us to stay in touch easily while commuting or when away from a desktop.

We enjoy unique features, like the time widget, which is always showing local time, the poll widget for fast decision making, and the pronouns field that helps people address others correctly when the gender associated with their name isn’t clear.

New contributors might be sceptical of using a niche FOSS tool like Zulip. But we got feedback that they later consider it as one of the best tool for managing communication across projects. The growing number of members confirms this.

Conclusion

The introduction of Zulip was the right move for us. If you are in the same situation and still using a mailing list or chat rooms, give Zulip a try. You can self-host or use Zulip’s hosted service, and you don’t depend on a single provider for all your services.

If you'd like to join us on Zulip, create an account and say hello at introduce-yourself

Thanks

Finally, we’d like to thank the Zulip contributors and organization for building and hosting our community instance. Your work makes open collaboration possible for the now > 3,000 Mixxx contributors around the world at no cost.

GSOC 2025 - Converting Demucs v4 (Hybrid Transformer) AI model to ONNX format

2025-10-27T07:50:04+01:00

Imagine loading any track in Mixxx and instantly isolating the vocals, drums, bass, or instruments live, in real time. This is the vision behind our Google Summer of Code 2025 project: "Converting Demucs v4 (Hybrid Transformer) AI model to ONNX format".

Mixxx 2.6 will support playback of stem files containing separate channels for different instruments. These stems can come from the original studio recordings (or DAW exports), or be generated using modern AI-based stem separation tools when the original stems aren’t available.

Demucs v4 is a state-of-the-art open-source music stem separation model developed by Alexandre Défossez [1]. It uses deep neural networks to "unmix" songs into separate instrument tracks - such as vocals, drums, bass, and others - by learning patterns from thousands of examples of how these instruments sound in isolation. While it provides exceptional quality in separating songs into stems, it is currently implemented in Python and therefore cannot be used directly in C++ applications or run efficiently on hardware accelerators.

This project is a step towards supporting real-time stem separation within Mixxx, by exporting the Python-based Demucs model to ONNX - the Open Neural Network Exchange format. ONNX is an open standard for representing machine learning models, allowing them to run on many platforms and hardware accelerators through compatible runtimes such as ONNX Runtime (ORT).

The key contributions of this project are:

Preparing the Demucs code for ONNX export by rewriting non-exportable operations
Validating all the modified parts with numerical tests to ensure export of existing model weights without the need for retraining.
Scripts for exporting ONNX and ORT compatible formats of the model.
Example scripts for deployment of ONNX model with C++ using ONNX Runtime.
Benchmarking the exported model for performance and separation quality.
Upstream PR with our modifications to the Demucs repository
Conference talk to be delivered at the ADC 2025

Introduction

Source separation models are typically developed using Python-based libraries such as PyTorch or TensorFlow, which require a Python runtime to execute machine learning models. This dependency can make it challenging to use these models in environments where Python is not available or practical, such as audio plugins, which are often written in C++. To address this, ONNX (Open Neural Network Exchange) has become a widely adopted representation format, enabling language-independent deployment of machine learning models.

While both PyTorch and TensorFlow provide straightforward ONNX export for simple models, complex audio models like Demucs often present significant hurdles. This is primarily due to their use of complex tensors and custom implementations of operations like Short-time Fourier Transform (STFT) and Inverse Short-time Fourier Transform (ISTFT), which are not natively supported by ONNX. As a result, previous attempts to export Demucs to ONNX have typically bypassed these operations, requiring developers to reimplement STFT/ISTFT in every target language, a process that is both error prone and time consuming.

In this project, we successfully exported Demucs v4 as a fully self-contained ONNX model, by rewriting the STFT and ISTFT operations to be ONNX compatible. This means the model can be used directly in any language that supports ONNX, greatly simplifying integration for audio developers and enabling broader adoption of source separation technology.

A key part of our approach was to diagnose and address each export issue step by step, developing custom numerical tests to ensure that our ONNX-compatible replacements matched the original PyTorch calculations as closely as possible. This was crucial, as retraining the model was not a viable option: Demucs was originally trained on a large private dataset over weeks using multiple GPUs, and reproducing those results without the dataset and computational resources would be extremely difficult. We verified the rewritten layers against the original PyTorch implementation to ensure equivalence (mean squared error(MSE) < 1e-4). By focusing on numerical fidelity, we ensured that the exported model retained the high performance of the original, without the need for retraining.

Understanding the Math Behind Audio

Before diving into transforms and neural networks, it helps to review how audio is represented mathematically and why complex numbers and Fourier transforms are so central to signal processing.

Real Numbers (Time-Domain Audio)

Digital audio is simply a sequence of real numbers — samples taken at regular time intervals.

Example: a 44.1 kHz stereo track stores 44,100 real values per second per channel.
Each value (e.g. 0.25, -0.67) represents instantaneous amplitude (air pressure or voltage).

Complex Numbers (Frequency Representation)

To analyze frequencies, we extend real numbers to complex numbers. A complex number represents both amplitude and phase of a frequency - like a small arrow (vector) that encodes how strong a frequency is and how it’s shifted in time.
In audio processing, complex numbers appear when converting sound waves into their frequency components using the Fourier Transform.

$$ z = a + bi $$

Where:

$a$: real part, $b$: imaginary part, $i^2 = -1$

Complex numbers are often represented in polar form:

$$ z = r e^{i\theta} $$

Where:

$r = \sqrt{a^2 + b^2}$ (magnitude)
$\theta = {atan2}(b, a)$ (phase angle)

Conversions:

$r = \sqrt{a^2 + b^2}$, $\theta = \operatorname{atan2}(b, a)$, $a = r \cos\theta$, $b = r \sin\theta$

In signal processing:

Magnitude → strength of each frequency component.
Phase → timing/offset of that frequency’s oscillation.

Complex numbers allow us to represent both amplitude and phase, making them perfect for describing sound in the frequency domain.

From Time to Frequency: FFT, STFT, and ISTFT

Fourier Transform (FT)

The Fourier Transform expresses a signal as a sum of sine and cosine waves of different frequencies.

For digital (sampled) signals, we use the Discrete Fourier Transform (DFT):

$$ X[k] = \sum_{n=0}^{N-1} x[n] \, e^{-2\pi i \frac{kn}{N}} $$

Its inverse reconstructs the signal:

$$ x[n] = \frac{1}{N} \sum_{k=0}^{N-1} X[k] \, e^{2\pi i \frac{kn}{N}} $$

Where:

$x[n]$ is the time-domain signal (length $N$)
$X[k]$ is the frequency-domain representation (DFT coefficients)
$n$ is the time index, $k$ is the frequency bin

For example, with a 4-sample input:

Input: $[1, 2, 3, 4]$
DFT: $[10, -2+2i, -2, -2-2i]$ (frequency components)
IDFT: Reconstructs the original signal from its DFT.

Short-Time Fourier Transform (STFT)

A single DFT gives the overall frequency content but ignores when things happen. To capture time-varying frequency information, we use the Short-Time Fourier Transform.

Steps:

Split the signal into short, overlapping frames (e.g. 2048 samples).
Apply a window (Hann/Hamming) to each frame.
Compute the FFT of each windowed frame.

Mathematically:

$X(m,\omega) = \sum_n x[n] \, w[n - m] \, e^{-j \omega n}$

$m$: frame index (time)
$\omega$: frequency bin
Output: complex spectrogram showing how frequency content evolves over time.

A spectrogram is a 2-D matrix (time × frequency) of complex values - often visualized by plotting magnitude in dB.

Inverse STFT (ISTFT)

To go back to the time domain:

Compute inverse FFT for each frame.
Multiply by a synthesis window if required.
Overlap-add frames to reconstruct the waveform.

Errors here cause audible artifacts (clicks, smearing, or phase shifts).

Understanding HTDemucs and the Challenges with ONNX Export

To understand the export process, it’s important to look closely at how HTDemucs (Hybrid Transformer Demucs) is structured, and why its architecture introduces challenges when converting to the ONNX format.

Figure 1. Architecture of the HTDemucs model (source: facebookresearch/demucs, licensed under MIT License).

HTDemucs Explained

Unlike text-based AI models like Open AI's GPT that learn language patterns, Demucs is an audio model trained to recognize patterns in sound waves. It doesn’t understand lyrics or meaning - instead, it detects subtle spectral and temporal cues that distinguish instruments, like how the human ear can separate a singer from the drums.

Hybrid Transformer(HT) Demucs or Demucs v4 is a hybrid model - it combines two parallel processing branches:

Time-Domain Branch

Operates directly on the raw waveform (real-valued input).
Uses temporal convolutions and Transformer blocks to learn how each instrument evolves over time.

Time-Frequency Domain Branch

Operates on the signal’s spectrogram, obtained by applying a Short-Time Fourier Transform (STFT).
The STFT produces a complex-valued tensor, representing both magnitude and phase across time and frequency.
The model immediately converts this to a magnitude spectrogram, a purely real-valued representation, which is then processed by convolutional and Transformer layers.
At the end of this branch, an Inverse STFT (ISTFT) is applied to reconstruct the real-valued waveform.

These two branches are then fused to produce the final stem-separated outputs (vocals, drums, bass, and others).

The ONNX Export Problem

The key difficulty in exporting HTDemucs lies in ONNX’s lack of support for complex tensors.

In the time-domain branch, all operations are real-valued and export cleanly to ONNX.
In the time-frequency branch, two specific operations, STFT and ISTFT, involve complex numbers.

The rest of the model (all convolutional, transformer, and linear layers) operates purely on real numbers, and therefore poses no export issue.

ONNX, as of current opset versions, does not fully support:

Complex-valued tensors as native types - PyTorch Issue
Complex FFT operations (torch.stft, torch.istft) from PyTorch - PyTorch Issue

As a result, a direct torch.onnx.export() call on HTDemucs fails, since the exporter encounters unsupported complex operations.

Our Solution

Real-Valued STFT and ISTFT Rewrites

Because complex tensors appear only in the STFT and ISTFT stages, we reimplemented these operations using pairs of real-valued tensors that store the sine and cosine components separately.
Mathematically, this represents the same information as complex numbers (real + imaginary parts), but it avoids using complex datatypes that ONNX does not support.

1. STFT Rewrite

Instead of using torch.stft(), we expressed the Fourier transform as a set of 1-D convolutions with precomputed sine and cosine kernels.

This allows us to compute: $\text{Re}(X) = x * \cos(\omega)$, $\text{Im}(X) = -x * \sin(\omega)$

Thus, we can store the real and imaginary parts as separate real-valued tensors, fully ONNX-compatible.

2. ISTFT Rewrite

Similarly, for inverse reconstruction:

The original ISTFT combines complex values through real + imaginary synthesis.
We reconstructed the time-domain signal by performing the same series of overlap-add and cosine/sine inverse convolutions, again using only real-valued tensors.

By carefully ensuring numerical equivalence to PyTorch’s implementation, we achieved perfect parity (MSE < 1e-4) between the original and rewritten layers.

Final Export

The only problematic parts were the STFT and ISTFT layers, and once these were rewritten with real-valued math, the model exported fully and cleanly to ONNX — no retraining required.

This approach made it possible to:

Preserve the original model weights.
Ensure perfect numerical equivalence.
Achieve seamless ONNX export compatible with ONNX Runtime (ORT) and C++ deployment.

Unified Benchmarking: Timing and SI-SDR

To evaluate the exported ONNX model, we developed benchmarking scripts for both PyTorch and ONNX/ORT backends. Key features:

Separation Backend:
PyTorch: Runs separation using the original Demucs model.
ONNX: Runs separation by invoking the ONNX CLI tool via subprocess, matching the workflow of the provided example scripts.
Timing:
The script records detailed timing for each track, printing and saving the results.
SI-SDR Evaluation:
Computes the SI-SDR (Scale-Invariant Signal-to-Distortion Ratio) for each separated track using the torchmetrics library.
Output:
Results are saved in timestamped folders, with timing and SI-SDR metrics output to JSON files named according to the backend (e.g., benchmark_results_cpp.json).

How to Run the Benchmark

Download MusDB dataset following the instructions in documentation
For C++ benchmarking, ensure the CLI tool is built and ONNX model has been exported.
Run the benchmark script:

python benchmark-pytorch.py/benchmark-cpp-onnx.py --musdb-root /path/to/musdb-hq/

Review the JSON results for timing and SI-SDR metrics.

Benchmark Results

The quality of the model is expected to be equal or slightly worse when exported to ONNX. While there are plenty of ways of measuring the benchmarks models (another blog post incoming), we've chosen to measure our models with SI-SDR metric, Scale Invariant Signal To Distortion Ratio, on the MusDB dataset. This is the standard metric on which researchers report their source separation model's performance.

We conducted comprehensive benchmarking on both CPU and GPU platforms, evaluating 50 tracks from the MusDB test dataset (approximately 3.46 hours of audio).

CPU Performance Comparison

Metric	PyTorch Model	C++ ONNX Model	Improvement
Total Processing Time	5,380.35 sec	4,415.30 sec	17.94% faster
Processing Time for 1 min input	25.89 sec	21.24 sec	17.94% faster

GPU Performance Comparison

Metric	PyTorch Model (GPU)	Python ONNXRuntime (GPU)	Difference
Total Processing Time	354.13 sec	386.40 sec	8.35% slower
Processing Time for 1 min input	1.70 sec	1.86 sec	8.35% slower

Audio Quality Results

Stem	PyTorch Model (dB)	ONNX Model (C++) (dB)
drums.wav	9.46	9.47
bass.wav	7.76	7.77
other.wav	4.69	4.65
vocals.wav	7.84	7.83
Overall	7.44	7.43

Table: SI-SDR (dB) comparison for each stem and overall, using torchmetrics. Results are shown for the native PyTorch model and the exported ONNX model running in C++. Higher SI-SDR values indicate better separation quality (less distortion).

Typical high-performing models achieve around 7–9 dB on vocals in the MusDB benchmark - with 0 dB meaning no separation improvement over the original mixture.

Key Findings:

CPU Performance: The C++ ONNX model delivers significant performance improvements (17.94% faster) while maintaining equivalent audio quality
GPU Performance: PyTorch maintains a performance advantage on GPU (8.35% faster), likely due to optimized CUDA implementations
Audio Quality: Both implementations produce nearly identical separation quality across all stems (< 0.1 dB difference)

Now that we have a running platform independent high quality ONNX Demucs model that can utilize hardware acceleration and be deployed with C++, we plan to integrate this into Mixxx DJ for future. We've prepared example scripts for running the exported Demucs model, which can be used following the instructions documented in our READMEs.

Plans for future integration into Mixxx

Here's a list of all the PRs that document our incremental changes towards exporting Demucs:

Task	PR Status	PR Link
ONNX Computation Path	Merged	PR #1
STFT Rewrite	Merged	PR #2
Inverse STFT Rewrite	Merged	PR #4
ONNX Export Scripts	Merged	PR #5
CI for model export	Merged	PR #6
Example C++ Scripts	In Review	PR #7
Benchmarking Scripts	In Review	PR #9

We've raised a PR with all our Demucs modifications to the upstream here - Demucs PR Link.

A talk will be presented on this project at the Audio Developers Conference 2025 in Bristol.

Finally, we've created this EPIC to track all issues related to merging Demucs to Mixxx. Feel free to join the discussion and get involved with supporting real time stems separation inside Mixxx.

🙏 Acknowledgements

This project would not have been possible without the extraordinary support and mentorship of Jörg, whose guidance, thoughtful reviews, and timely feedback shaped the project from start to finish. His expertise and encouragement were invaluable throughout every stage.

A huge thank you also to Antoine, who not only mentored me during the project but also integrated the exported ONNX model into his open-source tool Stemgen, deploying it using Rust and ONNX Runtime. Seeing the model already being used in a real-world application is deeply rewarding.

Finally, I would like to thank the entire Mixxx community and Google Summer of Code program for providing me the opportunity to undertake this challenging endeavour and the right environment to support its successful completion.

References

[1] A. Défossez, “Hybrid Transformers for Music Source Separation,” arXiv preprint arXiv:2211.08553, 2022.
Available: https://arxiv.org/abs/2211.08553

Mixxx 2.5.3 Released

2025-09-03T01:00:35+02:00

Mixxx 2.5.3 Release Announcement: Back to School, back to DVS.

We're proud to announce a new stable release of Mixxx: version 2.5.3, this version not only contains updates and fixes for some issues reported by users, but it also contains improvements to the Digital Vinyl System (DVS) support. These improvements are the result of some bright new insights of developers spinning the wheel instead of sunbathing. Since these improvements drastically improve the vinyl experience, we have chosen to backport ¹ it to the 2.5 series instead of integrating it in future alpha & beta versions.

Have a nice Mixxx.

Digital Vinyl System - Timecode System.

An introduction to Digital Vinyl Systems and timecode can be found in this article on the site of Digital DJ Tips, and in our own news archive: How Does Timecode Vinyl Actually Work? (Pt. 1), How Does Timecode Vinyl Actually Work? (Pt. 2) and How Does Timecode Vinyl Actually Work? (Pt. 3).

Mixxx plays the song by following the signal on the timecode media, which gets internally converted to actual timeframes. So the DJ controls the playback of the digital music by manipulating vinyl or CDs.

In order to create a vinyl-like feeling, the song needs to follow the signal as closely as possible (low latency, fast responsiveness) for e.g. scratching or backspins. There is no 'standard' signal - each manufacturer uses its own code. One thing all manufacturers have in common is that the code is modulated onto a sine wave. The code is used for absolute positions e.g. after needle drops, but it is not suitable to handle pitch (e.g. the playback speed) or playback direction. For this the sine wave needs to be processed by a filter that detects phase differences and converts it into pitch information.

Mixxx has integrated the xwax library for timecode support, which uses an Alpha-Beta Filter for pitch detection. This filter provides a good feeling during scratching, but isn't able to provide a stable pitch during normal playback. In PR #15194 developers have replaced the Alpha-Beta Filter with a more advanced Kalman-Filter equivalent.

Kalman-Filters have many application as GPS navigation and weather forecast models. In Mixxx the Kalman-Filter uses a probabilistic model of the vinyl movements to predict the velocity, very similar to the Alpha-Beta Filter. This predicted speed is compared with the noisy crackling input signal. The deviation ² is fed back into the filter and slightly alters its internal state for the next prediction.

If the vinyl is, say, spinning at 33 1/3 r/min, that value is used as the initial assumption on which the next prediction is based. If the next measurement returns 40 r/min, the value is not fully trusted, because such a high acceleration is unlikely. This measurement will be used with a low trust. However, if the following measurements detect 40 r/min as well, the filter gradually adjusts to approximate 40 r/min in further predictions.

By using this model, Mixxx is able to properly and more accurately represent e.g. the pitch control slider on the turntable or CD-player.

Another improvement has been made to the measurements which are fed to the Kalman filter PR #15217. The current model only takes rough measurements of the position on the sine wave. Furthermore these measurements work on the assumption to always be correct. A new check was added to detect if measurements were skipped or larger than assumed. This improves backspins where the deviation of estimation and measurement suddenly become very high.

These changes are major improvements for all DVS users. Too good to wait for Mixxx 2.6.
Get all Mixxx-ed up and join our testing-force for more upcoming features.

Controller Mappings

Mappings were updated for

Icon P1-Nano MIDI 1
Traktor Kontrol S4 Mk3
Traktor Kontrol S3
Numark NS6II

2.5.3 Changelog

More fixes have been included to keep everything stable, up and running. The complete changelog can be found here

Back porting is integrating new work into previous releases in order to let those releases profit from the new development. ↩
The Deviation in Kalman filters is called Innovation. ↩

How Does Timecode Vinyl Actually Work? (Pt. 3)

2025-08-27T11:54:12+02:00

Since its release in 2011, the Traktor Control Vinyl MK2 has sparked curiosity among digital DJs and audio developers alike. Its timecode format stands apart from Serato’s, which we explored in the previous posts. With the MK2 system, Native Instruments introduced a more advanced timecode that boosts resolution and accuracy by applying advanced cryptographic techniques.

In this post, we’ll break down how it works at a basic level and how Mixxx is processing the signal.

Recap: How Serato Timecode Works

Serato’s timecode is built around a Linear Feedback Shift Register, modulated onto a 1 kHz carrier using amplitude modulation (AM) - a legacy technique from radio transmission.

The demodulation process is relatively simple: when one stereo channel crosses the x-axis, the other hits a peak. If that peak exceeds a certain threshold, the system reads it as a 1, if not, it’s a 0.

We covered this in more detail in DVS Internals Pt. 1 and Pt. 2.

The Traktor MK2 Signal

Below is a signal that resembles what you’ll find on the Traktor MK2 Control vinyl/CD, which has been specifically generated for this blog post by using a Raised-Cosine Filter to modulate a random sequence onto the carrier.

The carrier wave operates at 2500 Hz, a significant increase from Serato’s 1000 Hz.

Advantage: The higher carrier frequency allows for 2.5× greater resolution.

Upon inspection, this waveform clearly doesn’t use amplitude modulation - the amplitude remains constant. Instead, it appears to be offset-modulated, where the signal is shifted vertically from the x-axis. This is a non-standard technique not commonly used in typical modulation schemes.

On the original vinyl version (not shown here due to copyright), the offset can be so large that the signal floats entirely above the x-axis for multiple cycles - making zero-crossing detection impossible.

Even when that doesn’t happen, the offset causes the time interval $\Delta t$ between zero-crossings to become irregular, introducing audible pitch flutter.

To decode the signal, we must solve:

How to filter the signal to enable pitch detection
How to demodulate this non-standard modulation
How to decipher the code that is modulated onto the carrier

Pitch Detection

Note: If you're unfamiliar with pitch detection in DVS systems, revisit DVS Internals Pt. 1.

Our goal is to produce a signal that oscillates evenly around the x-axis. This filtered waveform can then be processed by the existing pitch detection algorithm.

A simple discrete derivative operation achieves this:

$$ y[n] = x[n] - x[n-1] \tag{1} $$

$\text{where:}$
$\text{- x[n]: Input sample}$
$\text{- x[n-1]: Delayed input sample}$
$\text{- y[n]: Difference of both values}$

When applied to the offset-modulated signal, we get:

The resulting waveform oscillates cleanly around zero, which is ideal for analysis. It also makes it easier to pinpoint the half-cycle peaks needed for bit detection.

Demodulation Techniques

To extract bits from the signal, we detect the zero-crossings and sample the amplitude of the sinusoid at those moments.

You may notice that the derivative’s zero-crossings don’t align perfectly with the original peaks. That’s due to a delay introduced by the filter. Smoothing the signal first, then compensating for the delay (e.g., by selecting $x[n-3]$), yields better results.

For greater accuracy, one could analyze the phase response $\phi(\omega)$, which shows how filter delay varies with input frequency - but for this use case, a fixed delay works well enough.

The filtered signal can cross the x-axis in two directions-positive to negative or vice versa. Based on the direction, we determine which half-cycle contains the encoded bit. In this example we only use the upper half-cycle for decoding, but you can also decode the signal from the lower half-cycle.

Demodulation is then as simple as applying a threshold: amplitudes above it are 1, and below it are 0.

On actual vinyl, the physical behavior of the needle causes the offset to decay over time, because the needle slowly drifts back to the middle. This decay complicates bit extraction.

To compensate, we analyze the slope between subsequent readings by reusing the derivative equation in $\text{(1)}$.

$$slope[n] = reading[n] - reading[n-1]$$

$\text{where:}$
$\text{- x[n]: Current reading}$
$\text{- x[n-1]: Last reading}$
$\text{- y[n]: Difference of both values}$

We then decode a positive slope to toggle the bit to 1 and a negative slope to toggle the bit to 0.

This method helps isolate the encoded signal from the floating zero line caused by mechanical drift.

The Code

Note: A deeper explanation of LFSRs can be found in DVS Internals Pt. 2

Interestingly, the Traktor MK2 system also uses a Linear Feedback Shift Register - but with different properties. While Serato’s LFSR has a 20-bit length, Traktor’s uses a 110-bit register with a minimum run length of two symbols. The generator polynomial of the LFSR was found by using the Berlekamp-Massey algorithm.

The number of unique states an LFSR can generate is:

$$n_{max} = 2^m -1$$

Hence for the Serato timecode

$$n_{serato} = 2^{20} -1 = 1\,048\,575$$

and for the Traktor MK2 timecode

$$n_{mk2} = 2^{110} -1 = 1.298 \cdot 10^{33} = 1\,298\,074\,214\,633\,706\,907\,132\,624\,082\,305\,023$$

That’s an astronomically high number-far beyond what’s required for this application.

But how many states are actually needed? With a 2500 Hz carrier, you get 2500 bits per second.

For 12 minutes of timecode:

$$12 \text{ min} \cdot 60 = 720 \text{ s}$$

$$720 \text{ s} \cdot 2500 \text{ states/s} = 1\,800\,000 \text{ states}$$

which exceeds the maximum state range of Serato’s 20-bit LFSR by far.

However, a downside appears: each 110-bit state must be stored in 128 bits (4 × 32-bit integers).

So for the A-side with 12 minutes:

$$1\,800\,000 \text{ states} \cdot 128 \text{ bit} = 230\,400\,000 \text{ bit} = 28\,800\,000 \text{ byte} = 27.46 \text{ MB}$$

And for a 25-minute CD:

$$4\,500\,000 \text{ states} \cdot 128 \text{ bit} = 576\,000\,000 \text{ bit} = 72\,000\,000 \text{ byte} = 68.66 \text{ MB}$$

Disadvantage: The memory footprint is large - even a single side of timecode can exceed 27 MB.

This makes storing a full lookup table impractical in production software.

It's important to point out that the current implementation is naive, because it treats the Traktor MK2 code as if it were Serato code. Since Mark Hills designed the xwax library, which is used by vinyl control in Mixxx, for exactly this style of timecode, changes would have to be made to make the decoder more modular.

Nonetheless, the current technique works and it represents the current state of the decoder in Mixxx.

Conclusion

Fortunately, there are mathematical methods to reduce the memory requirements. This requires diving deeper into the crypthographic theory.

First tests show that this can possibly be achieved by applying a fixed tap pattern (e.g. every 5th bit) to a 110-bit LFSR window - a form of structured decimation or undersampling. This collapses the sequence into a 22-bit Gold code, whose two sequences alternate. The implementation of this technique is far more complex and not completed yet.

We’ll explore those strategies in the next part of this series.

GSoC 2025 - Multi-Genre & Autocompletion Support Implementation

2025-08-13T14:05:26+02:00

Hello everyone! I'm Antonio Giordano, and I'm excited to share the results of my Google Summer of Code 2025 work on Mixxx. We've introduced true multi-genre support with smart autocompletion, a cleaner editing experience, and tools to migrate your existing library without breaking your flow.

Project Vision & Evolution

Our goal was to give DJs flexible, reliable control over genres beyond a single free-text field. In earlier versions, you could type multiple genres (e.g., Dance/Electronic/House), but Mixxx treated that as plain text. It couldn't understand or manage individual tags.

To get this right, we started with a solid multi-genre foundation that's fast, consistent, and future-friendly. This foundation paves the way for richer features like hierarchical genres.

What's New

Single-Track Genre Editing (Chip UI + Autocomplete)

The Track Properties dialog now shows genres as compact chips with a white x to remove, plus autocomplete to add existing genres quickly.

Clean look & feel: compact chips, thin scrollbar, readable contrast.
Autocomplete: type a few letters and pick from existing genres.
No more long strings: add/remove individual genres directly.
Always consistent: the track table shows human-readable names everywhere.

Note: If you type a genre that doesn't exist yet, Mixxx keeps it as a literal. You can map it later using the Orphan Genres tool (see below).

Multi-Track Editing (Experimental)

You can now edit genres across multiple tracks in one go (experimental):

Common view: shows the intersection of genres shared by all selected tracks.
Batch operations: add or remove genres for the whole selection.
Safe by design: unique per-track genres are preserved.

A Smarter Library: Tree, Counts, and Drag & Drop

Genres now live in a tree. Each node shows track count and total duration. When you select a track, the genres it belongs to become bold in the tree crate-like ergonomics for quick navigation.

Drag & drop: drag tracks from the Tracklist onto a genre to assign it.
Quick menu: right-click a track then Genres to (de)select on the fly.
Rename safely: renaming a genre changes the name, not the ID, so tracks keep their associations.

Clean Migration: "Orphan Genres"

If your library contains free-text genres, Mixxx detects orphans and helps you clean them up:

Right-click the root of the genre tree then Edit Orphan Genres.
Add a new genre or Link a string to an existing one.
Multi-word strings appear as both a full string and individual tokens; add the full string first if you want to keep it as a single genre.

Why This Matters for DJs

Before:

One free-text field. No understanding of individual genres.
No autocomplete.
Editing meant retyping a whole string.
Inconsistent naming ("Electronic" vs "electronic").
No real bulk editing.

Now:

True multi-genre: each tag is a first-class citizen.
Autocomplete: fast, consistent tagging.
Visual editing: add/remove with chips.
Bulk-friendly: multi-track editor (experimental) for common operations.
Library-aware: a genre tree with counts, duration, and drag & drop.
Backwards-compatible: your library keeps working; migrate at your pace.

How to Use It

Single Track

Right-click a track, Properties.
In Genre, start typing and pick from autocomplete.
Click the x to remove a tag.
OK or Apply to save.

Multi Track (Experimental)

Select multiple tracks then right-click then Properties.
See the common genres across the selection.
Add or remove tags in bulk.
Save: Mixxx preserves track-specific genres.

Clean Up Old Text Tags

In the genre tree, right-click the root then Edit Orphan Genres.
Add new genres or Link strings to existing ones.
Repeat as needed, your sets keep running.

Under the Hood (Brief)

Stable IDs for genres and a fast join table (genre_tracks) so filtering and counts are snappy.
A central Genre DAO (data access layer) that maps between IDs and names and normalizes raw data.
The UI always shows human-friendly names; the storage format stays robust behind the scenes.

Demo video (quick tour)

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

This short video bundles all demos: single-track tag chips, multi-track bulk edit, the Genre Tree with drag-and-drop and F2 rename, and the Edit Orphan Genres flow

What's Next

This foundation unlocks a lot of potential. Based on community input, we're exploring:

A full hierarchical genre tree with multi-level editing.
Fuzzy autocomplete to handle typos gracefully.
Search that also matches genre names.
Smarter import/export of genre structures (share your taxonomy).
Better metadata export across formats for multi-genre fields.
Optional auto-conversion of known strings to stable IDs on import.

Thank You

Huge thanks to the Mixxx mentors and community for guidance, reviews, and real-world feedback. This is a big step forward, and we'll keep refining it together. Please try it and tell us what works for you.

Learn More

For comprehensive project details:

Complete Project Documentation: Full development journey, technical decisions, and lessons learned
GSoC Project Page: Official Google Summer of Code project details

Feedback & Support:

Report issues on GitHub, share ideas on the forums, or chat with us on Zulip. We'd love to hear about your experience with the new genre features:

Report Issues: GitHub Issues
Share Feedback: Community Forums
Join Discussion: Zulip Chat
Feature Requests: Help shape future enhancements!

Happy mixing!
Antonio Giordano
GSoC 2025 Contributor

Announcing the new shape of Mixxx 3.0 - take part in the future of Open Source DJing

2025-08-06T16:50:59+02:00

We are thrilled to announce an exciting new chapter in the evolution of Mixxx. We are embarking on a comprehensive redesign of the Mixxx user interface, transitioning from QWidget to QML. This significant update aims to enhance customization, improve performance, and ensure better accessibility for a variety of hardware, including tablets and touchscreen laptops, but also to users with vision deficiency thanks to built-in capabilities of QML. Further details on the original proposal can be found here.

Here is a preview of the current look we have designed during the proposal. Of course, as always with design work, the final version will likely look a little different, but this helps as a general guideline and goal to something we like, and hopefully you will to!

Why We Are Redesigning Mixxx

The current user interface of Mixxx has served us well, but as technology evolves, so must we. The shift to QML will simplify customization and maintenance, allowing us to focus more on innovative features and less on upkeep. This transition will also enable us to phase out our homemade theme system, streamlining our development process.

Key Features of the New Design

Modernized Library and Waveform Views: We are introducing a fresh look for the Library and Waveform views, making them more intuitive and user-friendly.

Enhanced Support for Lightweight Platforms: The new design will be optimized for tablets, smartphones, and touchscreen laptops, ensuring a seamless experience across all devices.
Improved Search Capabilities: The new search experience will offer better usability of advanced search options, making it easier to find and manage your tracks.

Interactive Settings and Preferences: We are introducing more interactive settings for audio routing, controllers, and waveforms, providing a more dynamic and user-friendly experience.

Get Involved

We are calling on developers and testers to join us in this exciting journey. Whether you are a seasoned developer or a passionate DJ looking to contribute, there are many ways you can help us.

This significant project offers a fantastic opportunity to make a substantial impact from the ground up. By helping implement the new QML interface, fixing bugs, and adding features, you can shape the future of a widely-used DJ software. Your Qt/QML expertise will be crucial in this transition. Whether you're beefing up your portfolio or just want to give back to the open-source community, contributing to Mixxx is a great way to truly make a difference!

For Developers

Code Contributions: Help us implement the new QML interface, fix bugs, and add new features. Your expertise in Qt/QML will be invaluable as we transition to this new technology.

Pro tip

Contributing to Mixxx enhances your coding skills and connects you with a vibrant community, providing real-world impact and career opportunities. Many contributors have advanced their careers through Mixxx, gaining valuable experience and recognition. Join us to collaborate with passionate developers and open doors to exciting tech industry opportunities.
Review and Feedback: Review our code, provide feedback, and suggest improvements. Collaboration is key to our success, and your insights will help shape the future of Mixxx. Code review is currently our biggest struggle and your help could be a real success factor for the project!

For Testers

Beta Testing: Join our beta testing program to try out the new features and provide feedback. Your input will help us identify and fix issues, ensuring a smooth and stable release.
User Experience Feedback: Share your thoughts on the new design and user experience. Your feedback will help us refine and improve the interface, making it more intuitive and user-friendly.

Heads up

We especially want to gather feedback from the visually impaired and blind communities to ensure that the next generation of Mixxx is the most accessible it has ever been!

How to Get Started

Join our community: Connect with us on our chat platform Zulip. Stay updated on the latest developments and contribute to discussions.
Check out the progress: Check out our GitHub repository and more precisely the QML project. You can also help us testing the ready merge requests, or even help with review in case you are familiar with QML!
Follow us on our socials: We have committed to increase our presence on YouTube and provide regular updates on Mastodon and Bluesky. Follow us and help us reaching out to more contributor to make this project successful.

Closing Thoughts

The future of Mixxx is bright, and we are excited to have you on board. Together, we can create the best DJ software experience for our community. Join us in this journey and help us shape the future of Mixxx and DJing!

Stay tuned for more updates and happy mixxxing!

GSOC 2025 Work Product - Resampling Options for Mixxx

2025-08-04T17:42:53+02:00

Presenting the latest additions to Mixxx:
issue#9328: Additional interpolation options for scratching
issue#10611: Custom output samplerates for recording and broadcast.

The scratching engine now supports a sinc-based resampler with three quality settings, and the original linear resampler is now twice as fast. Additionally, outbound audio is resampled before encoding for recording or streaming. This can improve compatibility with limited or fixed-rate sound cards.

Introduction

Mixxx uses the SoundTouch and RubberBand time-stretching libraries for resampling during a keyLock operation. However, these libraries are unsuitable for scratching due to the fast changing tempo and pitch. Currently a faster, handcrafted linear interpolation algorithm is used - but there have been reports of suboptimal audio quality.

Digital Signal Processing (DSP) theory tells us that linear interpolation is not ideal, and that a sinc-based resampler will always return interpolated values identical to the original analog signal, under certain theoretical constraints. However, practical implementations of sinc resampling are computationally heavy and generally unsuitable for low-latency realtime software such as Mixxx. Therefore...

One objective of this GSoC project was to explore the feasibility of using sinc interpolation for scratching. To this end, the libsamplerate and libzita resample latencies were evaluated.
Another focus was to investigate and improve the performance of the current linear resampler. Here, we observed that the libsamplerate linear interpolator outperformed our own, reducing per-buffer resample latency from 20µs to 10µs.

Theoretical Foundations

Although much of the work during GSOC involved integrating external C and C++ libraries into Mixxx, understanding the interpolation algorithms requires an overview of some foundational ideas in DSP.

Keywords

Periodic Sampling: The process of generating a digital audio representation from an analog signal by recording amplitude at uniform intervals. The length of the time interval is termed the sample-period (its reciprocal - the sampling rate - is more commonly used while describing digital audio). Analog audio is usually sampled at rates of 44.1KHz, 48Khz or 96Khz, ensuring the Nyquist criterion is met for frequencies in the audible range for humans [20Hz - 20kHz]

Time and Frequency Domain: Two representations of the same signal. The time domain representation describes how signal amplitude changes with time, and the frequency representation describes the spectral content of the signal. All DSP operations have a time-domain and frequency domain effect.

Nyquist Frequency: A digital signal contains all frequencies up to the Nyquist frequency, which is half the sample-rate (f_s/2). All spectral components below this frequency can be reproduced exactly during signal reconstruction. Frequencies above cannot be represented and must be removed before sampling to not cause aliasing noise.

Digital Filter: Filtering refers to a process whereby a time-domain signal is processed to cause a change in that signal's spectral content. A filter allows certain frequencies to "pass", and attenuates the rest. In digital form, the differential equations describing analog filters are replaced by discrete-time equivalents, which are implemented as convolution sums or, in block form, as matrix multiplications. Filters are of two kinds: Finite Impulse Response (FIR) and Infinite Impulse Response (IIR),and may be implemented in software, programmable chips, or dedicated ICs.

Impulse Response: The impulse response of a filter is its time-domain output when a unit impulse is applied as input. It encapsulates the behaviour of the filter, and may be a finite or infinite sequence depending on the filter type. For FIR filters, the impulse response is treated as the set of filter coefficients which is convolved with the input to generate the time-domain output. In practice, a very short rectangular wave is used as input, since it contains all frequencies.

Analog-to-Digital and Digital-to-Analog

Summary:

Every digital signal has a time-domain representation (sample sequence) and frequency-domain representation (replicated spectrum).
Filters implemented in hardware are called analog filters, those implemented in software are called digital filters.
In theory, ADC performs periodic sampling by multiplying an analog input signal with a unit impulse train.
In theory, DAC performs signal reconstruction by applying an analog Low-Pass Filter to the sample sequence. This is implemented via a continuous-time convolution
In theory, DAC signal reconstruction will be perfect if the original analog signal was Low-Pass filtered to lower than the Nyquist Frequency before ADC sampling.

An analog signal is a continuous-time, continuous-amplitude function. The Fourier theorem states that any analog signal can be viewed as the infinite sum of time-domain sinusoid components of varying frequency and amplitude. The set of components gives the spectrum of the signal. A signal's continuous spectrum is generally represented by an Amplitude-Frequency graph.

Its digital counterpart is a discrete-time sequence formed by sampling the analog amplitude at uniform time intervals, called sample-periods. In the time domain, sampling is represented as multiplying an analog signal with an impluse train. In practice, time-domain sampling is performed by electrical circuits in an Analog to Digital converter (ADC).

Periodic Sampling in the Time Domain

Figure 1: Mathematical Impulse-Train Sampling

Figure 2: ADC Sample-and-Hold Circuit

In the frequency domain, sampling with any frequency f_s always creates replicas of the spectrum of the original signal, centered at integer multiples of f_s. In the figures below, the left-hand side polygon represents the assumed spectrum of the time-domain signal in Figure 1. Its highest frequency component is B hz, and the range [-B, B] is referred to as the baseband of the analog signal.

Periodic Sampling in the Frequency Domain

Figure 3: Spectral replication without overlap.

Figure 4: Spectral replication with overlap

The purpose of sampling an analog signal is to create a representation that can be stored and manipulated by digital computers. However, these digital representations are only valuable if they can eventually be perceived in the real world. The process of converting a sampled signal back into a continuous-time analog signal is called signal reconstruction. Depending on the relative values of B and f_s, the spectral replicas created during sampling may overlap in the baseband, resulting in additive distortion. This phenomenon is termed aliasing and is perceived only on signal reconstruction.

Aliasing in the Time Domain

Figure 5: When a sine wave is sampled below the Nyquist rate, multiple analog sinusoids can fit the same set of samples. The figure shows two possible original signals that are consistent with the sampled data.

In theory, signal reconstruction is performed by applying an analog low-pass filter to the input sample sequence, to eliminate the spectral replications that were created during sampling. This leaves only the spectral components in the baseband. If f_s > 2B as in Figure 3, the baseband spectral component after sampling still represents the original spectrum. This criterion is formalized by the Shannon-Nyquist sampling theorem, which states that an analog signal must be sampled at at least twice the frequency (called Nyquist rate) of its highest-frequency component to ensure no aliasing upon signal reconstruction.

Low Pass Filter in the Frequency Domain

Figure 6: Ideal Low pass (Brick Wall) filter, no aliasing. The reconstruction low pass filter in the DAC assumes that the input meets the Nyquist criterion.

Figure 7: Failure to meet Nyquist criterion results in aliasing.

If f_s < 2B as in Figure 4, implying that the original signal has some higher-than Nyquist Rate/2 components, filtering would yield in a distorted baseband due to the "folding-back" of higher frequency sinusoid components. Therefore it is important to pass the analog signal through an analog low-pass filter before it is sampled by the ADC to restrict its frequency content.

The principle behind signal reconstruction is the continuous-time convolution process. Here, the impulse response h(t) of a First-Order Hold (FOH) filter stays stationary while the sampled sequence x_flipped slides over it. While the FOH filter reconstructs an analog signal, it is clearly an approximation. In fact, the impulse response for perfect reconstruction can be derived mathematically, and it turns out to be a sinc function.

Signal Reconstruction via continuous-time convolution

Figure 8: Convolving an input sample sequence with the continuous-time impulse response of a FOH filter. At each time step nT, (where T is the sample-period) the sample x_flipped(n) scales the triangular impulse response h(t-nT). The reconstructed signal y(n) is the sum of all such shifted, scaled responses. DACs implement FOH filter in their circuits.

Figure 9: Sinc reconstruction kernel. In theory, convolving this function with a sample sequence implements a brick-wall filter.

To conclude:

Convolving a sample sequence with a continuous normalized sinc function is equivalent to applying a brick wall filter over its spectrum. In the time domain, this process results in reconstruction of the analog signal.

Sample Rate Conversion

It is often necessary to change the sample-rate f_s of previously sampled analog audio. Re-recording from the source is quite impractical, and this has led to the development of software-based techniques to modify the sample-rate of digital audio.

Digital sample-rate conversion should be simple: Implement the DAC convolution on the digital samples to "recreate" the analog signal in software, and then implement an operation analogous to ADC sampling in software at the desired sample-rate.

The problem: Discrete-time convolution generates a discrete output sequence. While discrete-time convolution is the natural digital analogue to the continuous-time DAC convolution, its output is not continuous, and so cannot be sampled at arbitrary time instances.

Discrete-Time Convolution

Figure 10: Convolving a 5-tap impulse response h(k) of an averaging filter with a digital signal x(nT), where T is the sample-period. Outputs y(n) are obtained by sliding the input sequence over the stationary coefficients.

Figure 11: 9-tap and 19-tap sinc impulse responses h(k) of a lowpass filter.

The Solution: Model the original analog signal as a weighted sum of ideal, infinite, time-shifted sinc kernels, each centered on a known sample. This is effectively a snapshot of the DAC continuous-time convolution.

In theory, the continuous signal is reconstructed using an infinite number of sinc kernels:

but in practice, sinc algorithms approximate using a truncated window:

This windowed sinc interpolation algorithm can generate samples of the analog signal at arbitrary time instances. Resampling then reduces to generating a series of sample-values corresponding to a different set of time-stamps than the original. In Figure 11 below, the interpolated amplitude is the signed sum of the amplitudes of the 5 sincs at t = 0.2T.

Sinc Interpolation

Figure 11: Resampling via sinc interplolation. Here, a N=5 tap window around t = 0 is chosen to interpolate the sample amplitude at point-of-interest t = 0.2T. Each sinc function is centered on a sample in the symmetrical size 2T window around t = 0, and scaled by its corresponding sample amplitude.

For a given point-of-interest in time:

If the time is an exact integer multiple of the original sample period, each sinc function evaluates to zero except the one centered at that point, which evaluates to 1. This ensures that the reconstructed signal (weighted sum) perfectly matches the original sample value — there is no interference from neighboring sinc functions.
For other, arbitrary times, the sinc interpolation algorithm first chooses the known sample at the integer multiple of the sample period closest to the point of interest. It then selects a finite set (typically N=2M+1 taps) of nearby samples, scales the corresponding sincs, and computes a sum at the point of interest.

Interpolation libraries such as libzita and libsamplerate precompute sinc values in a high-resolution lookup table of fractional sample-period offsets to speed up computations. However, these are still far more computationally expensive than a linear interpolator, which uses only two adjacent samples and computes a simple weighted average based on the fractional offset.

Audio Engineering in Practice

While the section on theoretical foundations gives important intuitions on the correctness and meaning of certain digital audio procedures, developing high-performance implementations are an engineering problem, constrained by the design of digital audio hardware and processing software.

Keywords:

Audio Encoding:
Digital computers quantize analog amplitudes using fixed-precision floats during sampling. To distribute a digital record, it is compressed (lossy or lossless) using well-known algorithms that effectively wrap the float sample-sequence in headers. MP3, WAV, AAC are some standard audio encoding formats.

Audio Frame:
Sample sequences are treated as a series of logical frames for multichannel audio. An audio frame is an array containing k copies of the current sample value, where k is the number of output channels (mono:1, stereo:2).

Audio Interface:
A gateway for audio to enter or exit a processing system. The human ear is a biological audio interface. The ADC and DAC are technological/physical audio interfaces.

Sample Rate:
For a digital record, its sample rate in Hz defines how many frames make up one second of the track. The DAC sample-rate specifies how many outbound frames must be consumed per second of real-world (wall-clock) time during playback to avoid buffer underruns. Common rates are 44.1KHz, 48Khz or 96Khz.

Audio Buffer:
Audio frames, i.e. float arrays are transported to various parts of the audio processing stack in units of audio buffers. DSP libraries often expect multi-channel audio buffers to be interleaved - i.e. each frame with k floats is placed adjacently to build the audio buffer.

Buffer Underrun:
An audio distortion that may be observed during playback. During playback, the role of audio processing software is to prepare a certain amount of frames per unit time - decided by the DAC sample-rate. Delays in preparing the required number of frames results in intervals of silence, observed as audio pops and cracks.

The Mixxx Audio-Playback Stack

The Mixxx audio playback stack consists of components in Mixxx userspace that interact with the Linux audio subsystem using the PortAudio API. PortAudio interfaces with JACK - a low-latency linux sound server that mixes audio buffers from multiple sources. This enables DJs to design more involved workflows - for example running Mixxx decks into a live effects generator before playback. JACK interfaces with the DMA-based ALSA driver in the kernel, which finally triggers audio-buffer writes from RAM to the DAC FIFO during playback.

While JACK is essential to allow multiple real-time applications to talk to each other, a DJ performing a basic set will use Mixxx as her standalone audio source. PortAudio can also interface directly with the ALSA backend - causing Mixxx to be the sole owner of the soundcard. This provides a minor latency improvement.

The Need for Sample-Rate Conversion

Input audio must be resampled in two cases:

When there is a sample-rate mismatch between the input track and the DAC sample-rate:
While buffer underruns occur due to DAC starvation regardless of the buffer contents, this audio distortion arises when the DAC receives the wrong sequence of frames in its FIFO.

If a 96kHz record is played back on a DAC operating at 48 kHz without resampling, only 48k input frames are processed each second—meaning less than a full second of the outbound audio is played back per second. This results in an unintended slowdown.
Conversely, if the DAC sample rate exceeds the input sample rate, more than one second of the original recording is heard every second, creating the perception of sped-up and pitch-shifted playback.

Unintended tempo ramping

Your browser does not support the audio element.

Base (96kHz input, 96kHz DAC)

Your browser does not support the audio element.

Speedup (96kHz input, 192kHz DAC)

Your browser does not support the audio element.

Slowdown (96kHz input, 48kHz DAC)

In these scenarios, resampling is a corrective procedure that transforms audio sampled at the input sampling rate to match the DAC’s expected output rate.

When there is tempo change induced by the user:
For a record sampled at 96kHz with a DAC also at 96kHz, scaling tempo by a factor of 3 means we want to pass 3x the frames to the DAC on each callback than we would during standard playback.

Without resampling, writing 3x frames per callback in an attempt to increase tempo would overfill the Mixxx-ALSA buffers. In the worst case, the excess frames would be dropped. Either way, the DAC would still consume only 96k frames per second instead of the entire 3 * 96k — nullifying the intended tempo increase.
For accurate tempo-ramping, we must represent a longer amount of track duration using less frames, while ensuring that there are enough remaining frames for accurate reconstruction. That is, every second, we need to represent 3 * 96k frames using 96k frames only. This corresponds to an downsample, where we decrease the number of frames per second of input audio, i.e. decrease its sample rate.
Conversely, upsampling is used when decreasing track tempo, by increasing its sample rate. Here, interpolation is used to generate frames at non-integer multiples of the sample-period.

Mechanics of resampling in Mixxx

The Linux kernel can perform sample-rate conversion if required, using ALSA's internal resampler if necessary. Depending on kernel configuration, the resample could use linear or sinc-based interpolation provided by PipeWire or ALSA. The primary use case for such in-kernel resampling is to playback audio using aplay or ffplay via commandline.

Mixxx performs real-time manipulation of audio: live mixing, tempo changes, effects, scratching, and more. In fact, due to the low-latency requirement of these workflows, it is necessary to avoid the in-kernel resample. Therefore, Mixxx performs sample-rate conversion in userspace using a variety of external interpolation libraries.

Mixxx provides an abstract EngineBufferScale class, which is subclassed to implement resamplers using various time-stretching libraries. EngineBufferScaleST, EngineBufferScaleRubberband, EngineBufferScaleSRC, EngineBufferScaleZita implement resamplers that use the SoundTouch, Rubberband, SampleRate and libzita-resampler library APIs respectively.

During a live DJ set where the end result is an audio output, the resampling step happens in the player - between the soundsource and the engine. The exact flow is as follows, where T is the rack sample-rate and E is the Engine (DAC) sample-rate:

i. Sound source (T)
ii. Read ahead manager (T)
iii. Resample #1 (T -> E): scaleBuffer()
iv. Engine buffer (E)
v. Engine mixer (E)

With the new additions from this GSOC project, additional resampling occurs in the sidechains during recording and broadcast, where R is the recording/broadcast sample-rate:

vi. Sidechain (E)
vii. Record/Broadcast (E)
viii. Resample #2 (E -> R): scaleBufferOneShot()
ix. Encoding (R): encodeBuffer()

Emulated Vinyl Scratching

This GSOC project was derived from reports suggesting sub-par audio quality during scratching. In audio-enginieering terms, scratching simply amounts to a short-duration tempo change. As discussed in the previous section, this requires a sample-rate conversion, i.e. a resample.

A scratch can triggered by spinning the jog wheels of a MIDI controller. The architecture of Mixx ensures that the associated change in tempo ratio is made available to the resampler between DAC callbacks at the earliest. Mixxx acts on buffer chunks, for example 20 ms. The scratch control command is taken into account between these buffers. To have a steady tempo without clicks and pops, a ramp is applied. For example, if a user changes tempo from 1x to 2x, one additional buffer is used to slowly change the tempo from 1x to 2x.

The scratch control command directs the chosen resampler to adjust the quantity of input frames it requests from the Read-Ahead Manager and then interpolate to the desired output frame count. This emulates scratching - i.e. playback of high/low-frequency output due to sudden tempo change. Our empirical tests have revealed the following per-buffer resample latencies for each resampler:

Resampler	Per-Buffer Latency
SampleRate Linear	10 µs
Handcrafted Linear	20 µs
SampleRate Fastest Sinc	57 µs
SampleRate Highest-Quality Sinc	448 µs

Contributions

mixxxPR#15081: Custom samplerates setting for recording.
Status: Merged

This PR introduces an improved user experience in the recording preferences page. No more error messages for incompatible formats. The GUI maintains the necessary format+sample-rate invariants. This PR also introduces libsamplerate to the build system along with a base resampler class using the libsamplerate src_process API.

Key Files

GUI Changes

Before

After

mixxxPR#15160: Custom samplerates setting for broadcasting. Status: Unmerged

This PR allows users to choose custom samplerates for each broadcast profile, independently of the engine samplerate.

Key Files

Users can now pick custom samplerates for both recording and broadcasting, independent of the engine samplerate.

GUI Changes

Before

After

mixxxPR#15005: Support for low-latency scratching using the libsamplerate callback API Status: Unmerged

This PR implements a resampler class using the libsamplerate Callback API. We observed a reduction in per-buffer resampling latency from 20us to 10us - a 2x improvement over the handcrafted linear interpolator.

Key Files

GUI Changes

Before

After

Future Work

Benchmarking the latency and CPU usage of the various resamplers during scratching.
Creating a test-suite for various scratching patterns.

Acknowledgements

I thank Daniel Schürmann, Evelynne Veys, Ronny, and Jörg Wartenberg, who have spent considerable time reviewing my PRs and offering assistance anytime I needed it.

Mixxx 2.5.2 Released

2025-06-13T17:53:30+02:00

Mixxx 2.5.2 Release Announcement

We're proud to announce a new stable release of Mixxx: version 2.5.2, this version contains updates and fixes for some issues reported by users. We'd like to thank all users for giving feedback as we would like to emphasise once again the importance of testing.
Please join our testing-force.
This update also contains updates to controller-mappings and improvements in the building procedures.
Have a nice Mixxx.

Important updates and fixes in 2.5.2

The Midi wizard kept on waiting for a button press.
An issue with the detection of the keyboard layout on linux prevented the functionality of some shortcuts.
There was an issue sorting tracks while browsing files in 'computer'.
Another track then intended was loaded when a symlink was dragged and dropped.
Some skins were missing the loop-control anchor.

2.5.2 Changelog

The complete changelog can be found here

Controller Mappings

Mappings were updated for Denon MC7000, DJ TechTools MIDI Fighter Twister, Hercules DJControl Inpulse 500, Numark Mixtrack Platinium FX, Traktor S2 MK3, Traktor S4 MK2 and Traktor S4 MK3.

Library

Fixes for playlist export (when name contains a dot), loading the wrong track via drag and drop when using symlinks, byte order in hotcue comments imported from rekordbox, keyboard mappings with non-ASCII characters on Linux, Browse feature (enable initial sorting during population)

Controller Backend

Updates the Control picker (allow to learn MIDI Aux/Mic enable controls), Make [Main],headSplit CO persistent across restart, fix MIDI Controller button learning, fix learning with "No Mapping" selected, Unit tests for engine.beginTimer.

Target support

Fix building with:
- a CMake multi-config setup
- with gcc >= 14 with LTO and clang >= 19 (fpclassify)
- gcc -Warray-bounds= in fidlib by using a flexible member
Added:
- Linux Mint Codenames to debian_buildenv.sh
- hidden [Config],notify_max_dbg_time setting to reduce warnings in developer mode
- Detect arch and fail early if not supported when installing buildenv

Misc

Added and updated:
- Vinyl Control: Reduce sticker drift
- Fix infinite number of pop ups of the "No Vinyl|Mic|Aux|Passthrough input configured" dialog
- Reduce CPU usage with Trace log messages
- Fix adjust Gain after adopting it as ReplayGain only in requesting player
- Skins: add loop anchor toggle to Deere, Shade, Tango
- Sound Hardware preferences: add manual link for Mic monitoring modes

Mixxx 2.6 beta Released

2025-05-11T22:17:07+02:00

Mixxx 2.6 beta Release Announcement

We're proud to announce a new beta release of Mixxx, version 2.6. This is a beta release containing a lot of new features, we offer this release in order to get it tested by the most possible users. We look forward to the feedback of all users.

Mixxx needs testers for the new 2.6 beta release. If you would like to contribute to your favorite DJ program (translate, add a mapping, add a feature, test) Get Involved.

Enjoy Mixxx 2.6 beta

STEMS STEMS STEMS

To explain what STEMS are all about, we take a sentence from the introduction of this post, a regular text and convert it to a STEMS-text. In this example we extract 4 TEXT-STEMS that represent each a particular part of that sentence that only result in the original text when they are combined they result.

In the Text stems example here you can play with the mute and effect buttons. With the MUTE button you can make the Channel disappear, with the Effect button you can add an effect to the Channel. To see the original text each Channel needs to be un-muted and without effect.

Channel 1 Consonants + punctuation

Channel 2 All 'a'

Channel 3 All 'e'

Channel 4 other vowels

Wouldn't it be nice if we could do this tricks with music? This possibility exists and is called STEMS. Stems are audiotracks that contain 4 stems-tracks: Drums, Bass, Melody (or other) and Vocals (or Vox).

STEMS in Mixxx

With Mixxx starting with this 2.6 beta release you can control the Volume and Effects for each of these Stem-tracks independently. At the moment you need to create the STEM-Tracks with 3rd party tools, but once added to the Mixxx-library you can control them like - create an a cappela: Play Drums, Bass and Other "Normal" + mute the Vocals - create a drum pattern: Play Drums normally, mute Bass, Other and Vocals - remix a track: set the volume of the Drums on 100%, the bass on 90%, the other on 50% and the vocals on 60% - add effects to the vocal only: set the volume of all stems to a value of your choice + add reverb effect only to the vocals.

Mixxx wouldn't be Mixxx if these controls weren't available for your controller, so they are. To control the Stems you need for each channel, depending on your choice - 4 buttons if you want to use the 'mute' functions - 4 encoders to control the Volume - 4 buttons to activate the effect - 4 encoders to control the effect level.

Find more info about Stems in Mixxx in Antoine Colombier's GSoC Article

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

CUES CUES CUES

What if you wanted to add an extra cue, that logically should be between the 2nd and 3rd cue you created? In 2.6 beta this problem is solved. You can move a cue to another position without the need to re-create the cue. It's also possible to rearrange all cues according to their position in the track.

You can also use a menu action to re-order the hot cues according to their position in the track.

Before, cues played as long as you pressed them, to continue the playing you needed to press the play button. That's now possible with only a mouse: click and hold the cue, drag & drop it on the play button and ... tada, the track keeps playing.

2.6 beta Changelog

The complete changelog can be found here This is a selection of the changes and new features.

STEM file support

A lot of changes needed to be made to introduce STEM support.

Library

Add color coding for Key column
Add Key Color Palettes
Add overview column with small waveform
Search: add BPM lock filter bpm:locked
...

Waveforms

Simplify waveform combobox in preferences
Add minute markers on horizontal waveform overview
Rendergraph: Add rendergraph library and use if for waveform rendering
Improve apperrance of marks on the waveforms
...

Controller Mappings

Mappings were updated for Behringer DDM4000 & BCR2000, Herrcules DJ Control Starlight, Numark Mixtrack 3, Traktor S3

Controller Backend

Add screen renderer to support controllers with a screen
Settings: Add a file and color controller setting types
Allow to enable MIDI Through Port in non-developer sessions
...

Engine

Fix: sync rate using the current BPM instead of the file one
...

Preferences

Mixer: Show 'real' crossfader configuration
Mixer: Fix crossader graph
...

Skins

Allow swapping hotcues via dragging and dropping hotcue buttons
Add controls to order Hotcues by position in the track
Drop Hotcue onto Play button to latch play
Always show tooltips if Ctrl key is pressed
...

Target support

a lot of updates, please take a look at the changelog.

Misc Refactorings

a lot of updates, please take a look at the changelog.

Mixxx 2.5.1 Released

2025-04-27T12:43:25+02:00

Mixxx 2.5.1 Release Announcement

We're proud to announce a new stable release of Mixxx, version 2.5.1. It is recommended that all users update to this new version. Thanks to your feedback, this release contains a lot of improvements, fixes, new and improved controller-mappings. We would like to emphasize the importance of testing new versions. You don't have to be a programmer to contribute to Mixxx. Translating, testing new features and checking for possible regression is just as important. If you would like to contribute to your favorite DJ program, click on contribute.

Enjoy Mixxx

2.5.1 Changelog

The complete changelog can be found here

Controller Mappings

Behringer DDM4000 & BCR2000: Update mappings to 2.5 #14232 #14349
DJ TechTools MIDI Fighter Spectra: Add controller mapping #14559
Hercules DJControl Inpulse 300: add toneplay, slicer, and beatmatch functionalities #14051 #14057
Hercules DJControl Inpulse 500: New mapping #14491 #14510
Hercules DJ Console Mk1: Fix pitch bend buttons #14447
M-Vave SMC-Mixer: Add controller mapping #14411 #14448 #14457 #14458
M-Vave SMK-25 II: Piano keyboard mapping #14412 #14484
Numark Mixtrack Platinum: Fix VU Meters #14575
Numark NS6II: New mapping #11075
Numark Platinum FX: New mapping #12872
Pioneer-DDJ-SB3: Fixes slip mode and adds missing knob controls #11307
Reloop Digital Jockey 2 IE: New mapping #4614 #14328
Traktor S4mk3: Set 4 decks, avoid CO warnings for decks 3/4, eg. VU meter #14249
Traktor S4mk3: Smooth xfader curve for Const Power mode #14305 #14329 #14103
Traktor S4mk3: stop wheel led blinking when track is over/stopped #14028 #13995
Traktor Kontrol S3: Use pitch absolute mode as described in the manual #14123
Stanton SCS.1m/d; Keith McMillen QuNeo; EKS Otus: use playposition instead of non-existent visual_playposition #14609 #14603

Controller Backend

Controllers: Avoid timer warning on button release #14323
Controller preferences: Fix notify of pending changes when closing preferences #14234 #14220
Controller preferences: Fix broken overwrite dialog ('Save as..' not working) #14263
Controller preferences: Don't break support link texts #14079
Controller preferences: Fix wrong mapping change confirmation request caused by MidiController::makeInputHandler() #14281 #14280 #14292
Controller mapping info: Fix cropped description text #14332 #14117
MIDI controller learning: Make control box search usable #14260
MIDI controller learning: Don't reload mapping after learn #14253
MIDI controller learning: Correct skin control for mic/aux section #14221
MIDI controller learning: Add more cue controls for samplers #14419
MIDI controller learning: Continue after the maximum learning time is over #14429
Allow midino 0 in `MidiController::makeInputHandler() #14266 #14265
Fix: provide incomingData to MIDI sysex mappings #14368 #13133
Fix log spam when using Midi for light mapping #14326 #14327 #14333 #14338 #14371
Fix for TypeError in midi-components-0.0.js #14203 #14197
Fix crash due to concurrent access in MidiController #14159

Skins

Deere/LateNight (64 samplers): Bring back library in regular view #14101 #14097 #14700
Fix crash when hiding waveforms in Deere #14170
Waveform Overview: Abort play pos dragging if cursor is released outside the valid area #13741 #13732
Waveform Overview: Also render analysis progress when triggered by track menu or analysis feature #14150
Don't show 'menubar hide' dialog when switching skins #14254
Key Wheel: Move to View menu and make it a floating tool window #14256 #14239
Center effect parameter names #14598
Track menu: highlight row when hovering checkbox #14636 #14680

Library

Add Ctrl+Shift+C to copy the content of the selected cell(s) (The Mxxx 2.4 behaviour of Ctrl+C). #14114 #14065
Fix MusicBrainz lookup on Windows and macOS #14216
Library scanner: Update cached 'missing' flag when file is redicovered #14250
Hidden Tracks: Allow 'load to' via track context manu #14077
Update to libdjinterop 0.24.3 - support for Engine 4.1/4.2 #14172 #14289
Fix writing metadata via symlink #13711
Library menu: change "Engine DJ Prime" to "Engine DJ" #14248 #14682
Fix file extension handling during playlist export #14381
Fix manual key metadata editing in track properties dialog #14022 #14400 #14295 #14294
History: Don't allow joining with locked previous playlist #14401 #14399
Track info dialog: fixed cover label (max) size #14418
Track Menu: Reset eject after moving track file to trash #14402
Fix AutoDJ "Remove Crate" action #14426 #14425
Fix scrolling issue with coverart columns visible #13719 #14631
Developer Tools: multi-word search, no Tab navigation in controls table #14474
Analyze feature: respect New / All selection when searching #14660 #14659
Stop populating Computer library feature when Mixxx should close #14573
Tracks: apply played/missing text color also to selected tracks #13583
Tracks: show_track_menu at index position #14385
Search related menu: improve checkbox click UX #14637
Avoid false missing tracks due to db inconsistency #14615 #14513
Fix automatic trimming of search bar text #14497 #14486
Avoid crash after removing Quick Link #14556 #8270

Other Fixes

Enable R3 time-stretching with Rubberband 4.0.0 API version numbers #14100
Preferences Effects: add Hide/Unhide (move) buttons to Effects tab #13329
Preferences Effects: left/right key in effect lists trigger hide/unhide #14205
Fix beat sync in Flanger effect #14351
Apply talkover ducking after main effects to allow using a compressor effect #13844 #12451
Fix sporadic deadlocks when closing Mixxx or changing sound devices #14208 #14055
PositionScratchController: Fix loop wrap-around case #14379
Allow seeking to a hotcue during waveform scratching #14357 #13981
Reset saved loop when toggling off after switching cue type #14661 #14657
Fix leaks from fid_design() #14567 #9470

Target support

Allow to build with git "showSignature = true" #14115 #12997
Support building with Qt 6.8/6.9 #14080 #14071 #14200 #14204 #14440 #14518
Welcome Ubuntu Plucky Puffin; Good bye Mantic Minotaur #14148 #14158
Add more translations to Linux desktop file #14153 #14169
Debian: recommend qt6-translations-l10n #14147
Update FindFFTW3.cmake to not find version 2 #13937 #13931
Allow building without tests-tools via new CMake options BUILD_TESTING and BUILD_BENCH #14269
Fix and improve "missing env" error message #14321
Qt 6.8: Ensure Mixxx uses "windowsvista" Qt style on Windows #14228
Raise macOS target version to 11 (Qt 6.5 requirement). #14440
Fail early when building on WSL #14481
Remove useless udev rule #14630
Handle new " / " from taglib 2.0 #12854 #12790

Demand for cooperation in an AI-Research Project

2025-04-01T01:12:32+02:00

Mixxx has been asked to cooperate in an AI-Research Project 'Observe & Serve the Audience'.

Mixxx has been contacted by a joint research project between a university and a major AI company with the question if Mixxx wants to cooperate by asking DJs to help them. On benevolent behalf of all our users, Mixxx agreed. The research project wants to improve the detection of human sentiments, more particularly individuals located in a crowd. As most of the project is still under embargo, we can only give a small description:

They are looking for ~25 DJs that want to participate in the research project by installing the research gear on their gigs.
The DJs would receive a computer with two heat-detecting cameras, one regular camera and a HQ microphone.
The cameras need to be pointed at the public.
Observing the audience, DJs would get some on-screen demands to play cheerful / sad / uptempo or slow music, the cameras will observe emotions.
At some point, the system can even demand to play a complete other genre than the public wants (to detect disappointment and happiness).
DJs will have to install the research gear at least five times.
DJs will be rewarded for their cooperation. How is not communicated to us.
The Public needs to be warned that their emotions can be recorded for research.
Audience members agree to have their likeness and appearance recorded and analyzed for the purpose of generating updated models.
Audience members agree to be replicated and replaced as deemed necessary by the project.

If the research works out well, Mixxx will have the possibility to integrate the results in a new feature, with which Mixxx could predict the best records to play at the moment.

Appeal

We insisted on keeping the coordinates of our users/DJs private during the selection, so if you want to cooperate with this research, please send us a message on our Zulip chat. We will create a dedicated topic under #General. The researchers will contact you through our Zulip as well. The research program is looking for ~25 DJs, preferably of different countries (max 2 per country).

Google Summer of Code 2025, Get Googled, Get Mixxx-ed, Get Involved

2025-03-05T12:30:00+01:00

Last year Antoine created the STEM mixing support and Daniel gave us the Harmonic Mixing Enhancements as projects of GSoc 2024.This year Mixxx is accepted again as a mentoring organization for Google Summer of Code 2025, a global program focused on bringing new contributors into open source software development. Again this is a great opportunity for us to attract new contributors, as they will receive a stipend sponsored by Google.

How Does GSoC Work?

How to Get Involved?

You will find the GSoC 2025 Project Ideas for Mixxx in our wiki, but your own ideas are also more than welcome. Taking a look at our GSoC advice page is recommended if you're planning to apply. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our codebase.

You could also help us, even if you are not a GSoC candidate yourself. Simply print out a flyer and post it on the bulletin board of your local university.

If you are interested in past projects, take a look at the blog posts of Antoine Colombier, Daniel Fernandes, David Chocholatý and Fatih Emre YILDIZ. Their work has been successfully integrated into Mixxx.

The official application period will start on March 24th and ends on April 8th, so have your applications ready in time. Potential GSoC contributors should start discussing their application ideas on our Zulip now. Just start a new topic in the #gsoc stream. Please understand that we only engage with potential contributors via the respective channels in the #gsoc stream on Zulip or via the official GSoC application process.

Join us in improving Mixxx and contributing to free DJing worldwide!

Mixxx 2.5 Released

2024-12-24T15:25:19+01:00

All I want for DJ-ing is ...

Home alone? Scrooged? The sound of music? Die hard? Change plans: this year you will be having something better to do than watching old Christmas movies.

Mixxx is now your secret "Santa comin' to town", our elves had "good hearts with the burning desire to work hard", to get you "Rockin' around the Christmas tree at the party hop" with "something mighty sweet to see". "For the present, look high, not low": Mixxx's "presents 'neath the tree"

So this is the last goodbye ...

Important: OS-Support. macOS versions earlier than 11 can have a "Last Christmas". Windows versions earlier than version 10 build 1809 can be "Driving home for Christmas". For Ubuntu versions earlier than 22.04 "Christmas Will Break Your Heart".

By stepping over from Qt5 to Qt6 Mixxx is forced to increase the minimum system requirements to match those mandated by Qt. That's why the support has been dropped for macOS earlier than 11, Windows versions earlier then version 10 build 1889 and Ubuntu earlier then 22.04.

Let's cheer for the elves

Ho Ho Ho, our sleigh is filled with many shiny presents:

A red box filled with improvements to waveforms: 'SlipMode waveform' gives you visual aid while scratchin':

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

The 'beats until next marker' helps you to never miss the break:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

The GL ES support makes the waveforms run smooth:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

With a nice yellow bow around it, the new Skin & Interface features: the menubar can be hidden, reworked toggles (fullscreen, cue popup, vinyl control), improved tooltips, improved controls and checks (AutoDJ, effects), new command line interface options...

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Our engine became a V8 sleigh: undo function for BPM/beats, beatloop anchor, rate tap button...

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

"Rudolph, the Red-Nosed Reindeer" will sound much better with the compressor and glitch effects and the improved backend, which now supports also native Audio Unit (AU) effect plugins on macOS.

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Your "Jingles" and "Bells" can be sorted and found easier with the new library features: Cut, Copy and Paste in tracklists:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Tracks can be moved with Alt+Up/Down/PgUp/PgDn:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

With a summary containing the number of tracks and the total duration added to the name of crates, playlists and historylists makes it easy to find the right list:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

The searchengine received new BPM filters, an 'OR'-operator, new import possibilities, custom track colors for missing or played tracks...

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

"Santa Tell Me" what's new in preferences: some improved layout, the fetching of the soundcard's sample rate is fixed, a new setting for 'first hotcue', multiple options can be selected in the MIDI input editor.

Many "Days Of Christmas" full of improved Controller Mappings for Denon MC7000, Numark Scratch, Pioneer DDJ-FLX4, Traktor Kontrol S4 MK3 and MIDI for light.

A Controller Backend as a "Fairytale of New York" to map your controller: sysex, deck's track menu, support for bulk devices. We also dropped the lodash dependency.

Qt5 will Be Home For Christmas because Mixxx is using Qt6 now, a lot of work has been put in study, preparation, testing, upgrading procedures, adapting routines, dialogs, widgets, libraries. Upgrading to Qt6 wasn't just sitting "underneath the Mistletoe" but now Mixxx is in "Winter Wonderland". "Thank you Santa" Developers!

So many rafactorings have been made, improvements of the code by progressive insight, because of new possibilities in C++ and Qt, because of studies in acoustics, user experiences... The list is too long to write or make a selection here, it would be failing all contributors, you can find the complete list further in this announcement, full of "Christmas Lights".

So this is Christmas

"Baby, It's Cold Outside", so our present will be lots of fun exploring this new version. You'll need quiet some time to get used to all new features, discover the real possibilities, to get some adapted workflow with new handles. Mixxx whishes you a "Wonderful Christmas Time".

Mic drop, "Light the Candles All Around the World"

... and a happy 2.5

Start using your brand new toy, grab it from the Download page. Unwrap your gift, the complete changelog 2.5.0 Here some sparkles:

Modernized Platform: Update to Qt6

Mixxx is now using Qt6, offering improved performance and enhanced compatibility with modern systems. #11863 #11892
Build system defaults to Qt6. Qt5 build support will be dropped with Mixxx 2.6 #11934
Drop support for macOS versions earlier than 11
Drop support for Windows versions earlier than Windows 10 build 1809
Drop support for Ubuntu versions earlier than 22.04
Require a C++20 compiler
Support GCC 14 #13504 #13467
DlgAbout: Add Qt version to the dialog #11862

Engine

Beats: allow undoing the last BPM/beats change #12954 #12774 #10138 #13339
Add beatloop anchor to set and adjust loop from either start or end #12745 #13241
Add Rate Tap button #12104
Store/restore regular loop when toggling rolling loops #12475 #8947
Looping/Beatjump: use seconds if track has no beats #12961 #11124

Skins / Interface

Toggle the menubar with single Alt key press (auto hide) #11526 #13301
Allow to edit track title and artist directly within the decks via a delayed double-click #11755 #13930
Add type toggle to cue popup #13215
Effect Meta Knob: draws arc from default meta position #12638 #12634
Command line interface: Add option --start-autodj to start Auto DJ immediately after Mixxx start. #13017 #10189

Effects

Add Compressor effect #12523
add Glitch effect #11329
Add backend for Audio Unit (AU) plugins on macOS #12112 #13938

Library

Shortkeys Cut, Copy, Paste for track list management #12020 #13361 #13364 #13958 #13100
Playlists: move tracks with Alt + Up/Down/PageUp/PageDown/Home/End #13092 #10826 #13098
Search: Add special BPM filters #12072 #8191
Search: Add "OR" search operator #12061 #8881
Search: Add 'type' filter #13338
Search: Add 'id' filter #13694
Search related Tracks menu: Allow to use multiple filters at once #12213 #12211
Add multi-track property editor / batch tag editor #12548 #9023 #13299 #13609 #13597 #13631
Computer feature: add sidebar action "Refresh directory tree" #12908
Add 'Shuffle playlist' sidebar action #12498 #6988
Tracks: Custom color for missing tracks #12895
Tracks: Custom text color for played tracks (qss) #12744 #5911 #12912 #13538

Preferences

Decks: Add load point option 'First hotcue' #12869 #12740
MIDI Input editor: allow selecting multiple Options #12348

Controller Mappings

Denon MC7000: Add optional jog wheel acceleration to the controller mapping #4684
Denon MC7000: Unify parameter button logic and add customizable modes #13589
Denon MC7000: Add sampler options to mapping settings #13950
MIDI for light: Implement new Active deck heuristic #13513
MIDI for light: Add settings GUI #13721
Numark Scratch: Add controller settings #13404
Pioneer DDJ-FLX4: Mapping improvements #12842
Traktor Kontrol S4 MK3: Add setting definition for #12995
Traktor Kontrol S4 MK3: Software mixer support and default pad layout customisation #13059
Traktor Kontrol S4 Mk3: Rework jogwheel speed compute and motorized platter #13393
Traktor Kontrol S4 Mk3: Revert QuickEffect preset offset #13997
Traktor Kontrol S4 Mk3: Correct wheel timestamp wrap-around #14016

Waveforms

Visualize slip mode position by splitting waveform (RGB GLSL only) #13002 #13256 #10063
Show beats and time until next marker in the waveform #12994 #13311 #13953 #13314
Allow changing the waveform overview type without reloading the skin #13273
Overview: Update immediately, when the normalize option or global gain changed #13634

Quoted Christmas songs

All I want for Christmas (Mariah Carey)
Baby, It's Cold Outside (Ella Fitzgerald & Louis Armstrong)
Cheer for the Elves (Gwen Stefani)
Christmas Lights (Coldplay)
Christmas Present (Andy Williams)
Christmas Will Break Your Heart (LCD Soundsystem)
Driving home for Christmas (Chris Rea)
Fairytale of New York (The Pogues & Kirsty MacColl)
Feliz Navidad (José Feliciano)
Happy New Year (Abba)
Have yourself a merry little Christmas (Frank Sinatra)
I'll be home on Christmas day (Blue Blot)
I'll Be Home For Christmas (Bing Crosby)
Jingle Bells (version Diana Krall / version Johnny Cash )
Last Christmas (Wham)
Let it snow! Let it snow! Let it snow! (Dean Martin)
Light the Candles All Around the World (traditional)
Player’s Ball (Christmas Radio Mix, Outkast)
Presents for Christmas (Solomon Burke)
Rockin' Around the Christmas Tree (Brenda Lee)
Rudolph, the Red-Nosed Reindeer (The Ray Conniff Singers)
Santa Clause is Coming to Town (version Bruce Springsteen)
Santa Tell Me’ (Ariana Grande)
Sleigh Ride (The Ronettes)
So this is Christmas (John Lennon)
Thank You Santa (Phineas and Ferb)
The Twelve Days of Christmas (traditional)
Underneath the Mistletoe (Kelly Clarkson)
Winter Wonderland (Bing Crosby)
Wonderful Christmas Time (Paul McCartney)
8 Days Of Christmas (Destiny's Child)

Mixxx 2.4.2 Release Announcement

2024-11-27T07:56:41+01:00

Winter and Summer are coming

Contrasts. As the leaves fall and the first snowflakes start drifting down in the North, while the southern skies start warming up with summer sun, we are thrilled to finally release Mixxx 2.4.2! "Finally" because a bit later than planned, perfection can take some time. So we are proud to present you this release, a major bugfix-release for the 2.4 series before stepping over to a new number. Don't be scared, development won't hibernate.

Testing and translating

A special thank you to everyone who takes the time to test alpha and beta versions, to who report issues and proposals and to those who propose features and improvements. Your feedback is invaluable. A lot of new users and contributors have joined our community the past months, we'd like to welcome them all, spin it up, your energy and fresh ideas have already left a mark. Everybody can contribute to Mixxx. Did you find an error on the website, an incomplete subject in the manual, an error in translation?

Contribute.

Treasure hunt

When you dive into the code to add a feature or when you are looking for a function when you want to customize a mapping, you can discover small little snippets, real pearls, the intensive work of someone to make a function smoother, to let an algorithm work some milliseconds faster, to offer a conversion of a value to another without having to write it all over again. For all these little snippets, for all these forgotten pearls: thank you to all who ever contributed.

What's in the 2.4.2-bag?

All new and shiny: the complete changelog 2.4.2 This new stable release can be downloaded from the Download page.

Problems that were solved:

Handle not supported files when dragging to waveforms and spinnies #13208 #13271 #13275
Fix Sqlite 3.45 builds by using only single quotes for SQL strings #13247 #13257
LateNight: Use default colors for sampler overviews (like main decks) #13274
Library: Allow to drop files to decks with unsupported or no file extensions #13209 #13204
Update build environment with libdjinterop 0.21.0 #13288
Move to GitHub workflow runner macos-12 #13296 #13248
Recording: with empty config, save default split size immediately #13304
Allow to drop files with supported MIME type regardless off the file extensions #13209 #13204
Add support for Ubuntu Oracular Oriole and remove Lunar Lobster #13348
Recordbox: Fix string decoding issues #13293 #13291
Mixer preferences: Don't update EQs/QuickEffects while applying #13333
Hardware preferences: Fix UX when applying config with missing/busy devices #13312
Fix minor 64 bit CPU performance issue #13355
Fix clicks at loop-out when looping into lead-in #13294
Fix wrong pitch value on startup, caused by components.Pot #11814 #13463
Engine Prime: Fix build-failure #13397
Engine Prime: Friendlier error message if export fails #13524
macOs: Fix Keyboard shortcuts by not catching num key modifier #13481 #13305
Skins: fix time display to allow AM/PM #13430 #13421
Fix detection last sound if track does not end with silence. #13545 #13449
Remove false positive critical warning related to library columns #13165 #13164
Fix reading metadata for files with wrong extensions #13218 #13205
History: remove purged tracks, auto-remove empty playlists #13579 #13578
Synchronize AutoDJ next deck with top track in queue #12909 #8956
Playlists: Update play duration and bold state in sidebar when dragging tracks into the playlist table #13591 #13590 #13575
Playlists: Keep correct track selection (# position) when sorting #13103
Track file export: Various fixes #13610
Controller engine: Unify/improve logging, expand error dialog's Details box #13626
Fix quantization in the effect engine (metronome effect) #13636 #13733
Musicbrainz: Improved messages #13672 #13673
Fix ReplayGain detection in case of short tracks #13680 #13676 #13702 #13703
Track menu: Avoid crash and UX issues with track nullptr #13685
Disable Properties shortcut in Computer feature views #13698
Overview waveform: Add tooltip info about left-click dragging #13739
Make hotcue_focus_color_next/_prev COs ControlPushButtons to allow direct mappings #13764
Scaled svg cache to speed up drawing in hidpi mode #13679
Update to libdjinterop 0.22.1 for Enigine Prime 4.0.1 support #13790
HID: Avoid repeated error messages from hid_write()/hid_read() in case of errors #13692 #13660
Fix unnecessary painting with covers in library #13715

Updated Controller Mappings: Denon MC7000, Korg Kaoss DJ, Novation Dicer, Novation Launchpad X, Numark PartyMix and Scratch, Pioneer DDJ-400 and DDJ-FLX4, Reloop Beatmix 2/4, Mixage MK1 and MK2, Sony SIXAXIS

GSoC 2024: Adding STEM mixing support

2024-08-26T12:00:00+02:00

Disclaimer: The blog post primarily serves as the documentation for the Google Summer of Code 2024 project: "Multi channel mixing support (STEMS)".

Explore New Creative Horizons with Mixxx's Latest Feature: Stem Mixing

We're excited to bring a powerful new feature to Mixxx: Stem Mixing. While the concept of stems — separate audio tracks for different elements of a song — has been a staple in digital audio workstations (DAWs) for years, it’s now making its way into live DJing. Typically, a song is divided into stems like drums, bassline, harmony, and vocals. In a DAW, these individual tracks allow producers to have granular control during the production process.

Now, with Stem Mixing in Mixxx, you can take that same level of control into your DJ sets. Built on top of Native Instrument' Open Specification This feature enables you to isolate and manipulate these elements in real-time, allowing for live remixing, mashups, and creative edits on the fly. Whether you’re blending two tracks together or creating entirely new soundscapes, Stem Mixing offers a new dimension of flexibility and creativity for your performances.

Mixxx now supports Native Instruments stem files, the current public specification for this format. Whether you're an amateur DJ eager to experiment with new techniques or a professional looking to enhance your performances, Stem Mixing in Mixxx offers powerful new capabilities to elevate your mixes.

For example, it becomes piece of cake to mixxx the vocals of track with another instrumental version.

It is also possible to load a single stem or set of them into sampler.

Coupled with saved loop, it makes it pretty trivial to isolate that catchy voice line or a great saxophone sample!

Please note that although we worked on improving the engine performance, stem mixing is still very resource-greedy, so do make sure your machine has enough CPU power to perform live stems mixing.

Empowering open standards

Over the past few years, many DJing solutions have introduced their own proprietary standards for stems. While most of these formats can be reverse-engineered with relative ease, we wanted to support and encourage the open-source approach introduced by Native Instruments. We've extended the scope of that standard in Mixxx, allowing for more flexibility in audio formats. Unlike the original specification, which only supported AAC and ALAC, Mixxx now supports a broader range of codecs. These include all the formats already compatible with Mixxx, such as AIFF, MP3, Opus, WAV, and WV. The only requirement is to use the same codec across all stems, keep the sample rate consistent parameter and use stereo.

However, there are still some issues and limitations with the current standard, such as the lack of internationalization for labels. Rather than creating yet another standard, we would prefer to contribute to improving the existing open specification from Native Instruments. If you are part of the NI team and are open to collaboration, we would love to help refine and expand this standard. Please feel free to get in touch with us.

Paving the Way for AI-Generated Stems

The introduction of Stem Mixing in Mixxx is just the beginning of a revolutionary journey in DJing technology. This feature not only enhances your current capabilities but also sets the stage for future innovations, particularly in the realm of AI-generated stems. The Mixxx community is actively exploring ways to integrate artificial intelligence to create stems on the fly, pushing the boundaries of what’s possible in live DJ performances.

Competitors like Virtual DJ and Algoriddim’s djay Pro AI have already implemented AI-driven stem separation, allowing DJs to extract individual elements from any track in real-time. These advancements highlight the potential and ambition we have for Mixxx. Our goal is to provide DJs with the most cutting-edge tools to unlock new levels of creativity and performance.

Imagine being able to instantly isolate vocals, drums, or other components from any track in your library, regardless of its original format. This capability would not only streamline the preparation process but also open up endless possibilities for live remixing and mashups. As the Mixxx community continues to develop and refine AI-driven features, we are committed to bringing these powerful tools to our users, ensuring that Mixxx remains at the forefront of DJing technology.

However, there is still a long journey for it to be ready, especially because of the challenge with supporting hardware acceleration, needed to perform stem separation in real-time. This topic is currently very active and hotly debated in our community chat on Zulip. If you are interested in contributing to this effort or just want to stay updated on the latest developments, we invite you to join the discussion. Your input and enthusiasm can help shape the future of Mixxx.

How to quickly get started

Currently, Mixxx does not yet support generating stems on the fly. However, there are ongoing discussions about enabling real-time stem creation or adding functionality to generate stem tracks directly within Mixxx.

For now, you will need to create the NI stem files yourself. Fortunately, there are several ways to do this. If you're an audio producer, you can build the stems directly. Native Instruments provides a tool for generating Stem files from a pre-mastered track along with the four stems that compose it. Note that while Native Instruments allows exporting unmastered stems with embedded mastering (limiter and compressor) applied on the fly, Mixxx does not yet support this feature. For better results in Mixxx, it is recommended to export your stems pre-mastered and disable the embedded mastering option.

If you would like to convert your existing library, there are various options available online, often built around Meta's demucs model. Unfortunately, many of these projects have licensing issues or significant limitations. While developing the stem feature, I created a small command-line tool for generating stem tracks. It currently works on Linux and should also function with Linux containers on other platforms. I plan to continue maintaining it, with future goals of developing a more complete solution with a user interface and native support for Mac and Windows.

Generate stems from stereo tracks using stemgen and Docker

Docker is a platform that allows you to run applications in isolation from your system. Note that stemgen is available only as a Linux container. Linux containers are the default on Mac and Linux, but you will need to enable them on Windows.

Step 1: Download the Container

First, you’ll need to download the stemgen container to your machine. Open your terminal and run the following command:

docker pull aclmb/stemgen:latest

Please note that this container includes PyTorch for running Meta's model, as well as NVIDIA's CUDA libraries for GPU support. As a result, the container is quite large, so ensure you have at least 4 GiB of free space on your machine.

Info:
If you are using a Linux machine with an NVIDIA graphics card, make sure to install the NVIDIA container toolkit.

Step 2: Run the Stem Generation Process

Once the container is downloaded, you can generate the stem file with the following command:

docker run -v /path/to/music/folder/:/path/to/music/folder/ -it --rm aclmb/stemgen:latest stemgen "/path/to/music/folder/My Music - Title.ext" /path/to/music/folder

If you are using the NVIDIA container toolkit, you can add the --gpus all option after --rm like this:

docker run -v /path/to/music/folder/:/path/to/music/folder/ -it --rm --gpus all aclmb/stemgen:latest stemgen "/path/to/music/folder/My Music - Title.ext" /path/to/music/folder

Tip:
You can customize the generated stem file using various command-line options. To see a list of available options, run the following command: sh docker run -it --rm aclmb/stemgen:latest stemgen --help

Step 3: Enjoy Your New Stem File

That’s it! You should now have a file named /path/to/music/folder/My Music - Title.stem.mp4 on your machine, ready to be played in Mixxx. If you encounter any issues, feel free to start a new discussion on the project.

What features are supported already?

Here is a table that summarize the new stem features. Note that you may find more details and also get involved with the work in the Github epic dedicated to stem mixing.


File support	Releasing in 2.6	PR #13044
Engine support	Releasing in 2.6	PR #13070
Multithreaded scaling	Releasing in 2.6	PR #13143
Analyser support	Releasing in 2.6	PR #13106
Gain control	Releasing in 2.6	PR #13086
Quick FX	Releasing in 2.6	PR #13123
Loading as sampler	Scheduled in 2.6	PR #13268
UI	Scheduled for 2.6	PR #13537
Deck splitting	Planned

Releasing implies that the PR is merged, Scheduled implies work in progress, near completion and Planned implies that this still left to do.

If you wish to try the stem capabilities before the 2.6 beta gets released, you may build Mixxx using the CMake option FFMPEG and STEM.

GSoC 2024 Project Report - Harmonic Mixing Enhancements

2024-08-24T07:50:11+02:00

Introduction

Welcome to the GSoC report for the Harmonic Mixing Enhancements project, which aims to make finding compatible tracks a breeze with these new features:

Color coding the Key column of the track list.
New Track Similarity Column, which uses the Key and BPM to compute how well two tracks work together.

In this post, I will share what this process has been like, the current state of things, and where you can try the merged features out.

Project Planning

We used Zulip to get feedback and find use cases from the community to better understand the needs of Mixxx' users, which was important for solving some open questions. We particularly wanted to find clarity for the Track Similarity Column. After some discussion I drafted a design doc which gave us a concrete plan to improve on and made it easier to decide the finishing details.

mixxxdj/proposals#5 (draft)

Color Coding the Key Column

In this part, we color the key column such that, keys that work well together have similar colors. We also wanted to provide alternative color palettes, for accessibility and personal preference.

We started with designing how the key colors will be shown. It was a bit tricky, because the tracks also have their own 'Color' property, so we had to make sure that these colors don't clash.

Using feedback from the community, we iterated over a few designs, finding out what looked best but also met our needs. Here are some of these iterations:

And here's how the final design looks in the app:

This design preserves the readability of the text, while being a subtle hint for compatibility without interfering much with the track color.

Implementation

A KeyDelegate was created to override the default behavior for the key column. It retrieves the Key Color to draw a recentangle to the left of the text.

A Mixxx Key Color Palette was also created, based on the colors from the Mixxx Keywheel.

To allow users to turn the feature off, a checkbox was added to toggle the Key colors.

mixxx#13390 (merged)
mixxx#13475 (bugfix, merged)

Key Color Palettes

We added several color palettes for the key column that you can choose from. This includes palettes from third party software, so you can keep using the colors you're used to, as well as accessible color palettes optimized for the three broad types of color blindness: Protanopia (red-blind), Deuteranopia (green-blind), and Tritanopia (blue-blind).

We used 1/3 of hues for each palette, changing the hue vertically and changing the brightness and saturation horizontally when the colors are arranged in a circle. This ensures that every region on the circle has a distinct color, and that the change in colors is nearly uniform.

You can find the code written to generate these palettes here.

We have tested that these work well in simulators. However, we are not done until we get feedback / confirmation from the users who would benefit from these palettes. If that's you, please reach out!

Implementation

The color palettes were added along with a dropdown to choose between them. Translation support was also added for all palette names.

mixxx#13497 (merged)
mixxx#13571 (bugfix, merged)

Where to try it out

The Key Colors feature is available in the Alpha versions of Mixxx. We would greatly appreciate any testing, and if you find bugs, please do let us know in the GitHub Issues.

Track Similarity [WIP]

You've probably noticed that in your collection there are pairs of tracks, with seemingly incompatible keys and different BPMs, that still work beautifully when played together, without the need for Keylock. This is possible, because when we sync the tempo of both tracks, the pitch of one track is shifted relative to the other in just the right way, that they both end up in similar keys.

Wouldn't it be cool if Mixxx could show you exactly which tracks work nicely this way? As a first step to making that happen, we needed a method for computing such similarity between two tracks.

I decided to prototype the algorithm in Python, and then port it into C++ for Mixxx. Fortunately, Mixxx stores all its data in an SQLite file, so I was able to export my library with the sqlite CLI tool and test the prototype on it.

I iterated on the prototype by testing out the results in Mixxx, and making notes so I can understand what to tweak. The final version of the algorithm that I settled on, can be found as a Jupyter notebook. It takes in the Key and BPM of two tracks, and outputs a single similarity value for how well the tracks will work.

With the algorithm settled on, it was time to port it to Mixxx.

Implementation

The function trackSimilarity() was implemented in KeyUtils. Some helper functions were added, including trackSyncPitchDifference() which returns the pitch difference between two tracks, when they're played at the same BPM.

To test that it's working, the similarity of each track is computed against a "dummy" track in C Major at 100BPM and is displayed as a tooltip on the Key column. The output from the prototype and the C++ implementation in Mixxx are identical.

This feature is behind a CMake flag as it is currently still in development.

mixxx#13563 (WIP, not merged)

Next steps

After finishing the Similarity Algorithm, the output needs to be used in a new "Similarity Column". For this, a system for determining the target track to be used is needed. More details on the rules for choosing the target track are discussed in the proposal PR.

For the Key Colors feature, we need to color the Key label on the decks, disable the Key Palette setting if Key Colors are disabled, and have the key column update when also clicking "Apply" on the preferences and not just after closing the preferences window.

My experience and the things I learnt

It was the Mixxx manual that introduced me to Harmonic Mixing a few years ago, and it got me excited about DJing. Since then, I started thinking about ideas like Track Similarity, but I never thought I'd get to actually work on making them real! I'm truly grateful for this experience.

Mixxx was the first real world C++ project I worked on, and I learnt a lot of things that will help me for years to come. I learnt how to make project plans, and keep myself on track. It was specially helpful to break tasks down into smaller tasks, and make "mini-deadlines" for each of them. I learnt to brainstorm with others, and saw how ideas can evolve. On the technical side, I got lots of opportunities to use and understand Git more deeply, and also to navigate through and work on a large codebase.

Acknowledgements

Mixxx has an amazingly helpful and enthusiastic community behind it, and everyone I've worked with is so awesome!

Firstly, I'd like to thank my mentor Daniel Schürmann for guiding me right from the very initial planning and brainstorming stages, and all the way to reviewing and getting the PRs merged. He made sure that I was never stuck on anything, and took great care that things go smoothly. He has been very helpful and supportive!

I'd like to thank ronso0 for his valuable design ideas and for guiding me with helpful feedback and testing during the code review. I'd also like to thank Swiftb0y for his valuable feedback and suggestions and for helping me make my code easier to read and efficient.

A special thanks to everyone participating in the discussions and testing for these features, it has been a very essential part of the process and was also quite fun!

Finally, I'd like to thank Google and the GSoC team for this one of a kind opportunity which introduced me to the awesome and collaborative world of open source.

Controller API declarations for JavaScript mapping developers

2024-08-18T16:57:58+02:00

If the support of a DJ controller requires more than the semantic 1:1 mapping of MIDI codes, Mixxx offers the possibility to use freely programmable Javascript code to implement such more complex functionalities.

The Mixxx internal Application Programming Interface (API) for such controller scripts was previously only partially documented, in the Mixxx Wiki.

This has changed with Mixxx 2.4, now there are formal TypeScript declarations for each individual API class/method. These can be read by any code editor with Language Server Protocol (LSP) support, to be visualized to the developer while typing his controller scripting code. Popular editors and IDEs with LSP support are Atom, Eclipse, Sublime Text, Visual Studio and Visual Studio Code.

In addition to the inline visualization of the documentation, the syntax is also checked against the TypeScript declarations. Usage errors are reported directly when writing the code in the editor.

How to use it?

Development of mappings and controller scripts is usually done in the subdirectory controllers of the Mixxx Settings Directory, while the common files (like common-controller-scripts.js) which comes with Mixxx, are store in the subdirectory controllers of Mixxx installation directory, or ./mixxx/res/controllers if you built Mixxx yourself. This is also the location, where the TypeScript files with the declarations of the Mixxx controller API are stored. The LSP language server need to know the location of all of them. To tell the LSP server general settings and the locations of these files, you need to create a file with the name jsconfig.json placed next to your JavaScript controller script file, in the controllers directory in your Mixxx Settings Directory.

The jsconfig.json must have a content like this:

{
"compilerOptions": {
    "target": "es6",
    "checkJs": true,
    "lib": [ "ES2016" ]
},
"include": [
    "./filename_of_your_controller_script.js",
    "C:/Program Files/Mixxx/controllers/common-controller-scripts.js",
    "C:/Program Files/Mixxx/controllers/common-hid-packet-parser.js",
    "C:/Program Files/Mixxx/controllers/engine-api.d.ts",
    "C:/Program Files/Mixxx/controllers/color-mapper-api.d.ts",
    "C:/Program Files/Mixxx/controllers/console-api.d.ts",
    "C:/Program Files/Mixxx/controllers/hid-controller-api.d.ts"
]
}

The content of the jsconfig.json:

The compilerOptions section contains information about the JavaScript engine. Especially it overwrites the default included libraries, which only apply to JavaScript in webbrowsers
The first file entry in the include section is the controller script under development, located next to the jsconfig.json
common-controller-scripts.js is a JavaScript library used in most controller scripts, and is part of the Mixxx installation.
common-hid-packet-parser.js is also JavaScript library but only for controllers using the HID protocol
engine-api.d.ts, color-mapper-api.d.ts and console-api.d.ts are part of the Mixxx installation and contain TypeScript API declarations, which should be added for any controller script development
hid-controller-api.d.ts is also such a declaration file, but specific to the communication protocol, because the APIs for HID and MIDI use the same symbols
- For HID controllers use hid-controller-api.d.ts
- For MIDI controllers use midi-controller-api.d.ts

The .js files listed in the include section of the jsconfig.json must exactly match the files in the <scriptfiles> section of the controller mappings .xml file. But, note that the .xml only contains the file names, while the jsconfig.json requires the full paths (relative to the position of the jsconfig.json file).

Once you have the jsconfig.json file in place, you only need to open the folder containing the file in your editor, and all listed files will be found and read by the LSP server.

Midsummer Mixxx

2024-07-31T17:18:23+02:00

Let the Mixxx shine

Summertime, partytime. In the middle of the festival season you are maybe playing a sunny vibes gig somewhere. Or you are relaxing on the beach or at the pool with a cocktail in the hand checking the long list of music you had to discover. Both ways will give you inspiration and energy. Who thinks Mixxx-devs are laying in the sun can't be more wrong, we're having a crowded github-festival ourselves.

Let the Mixxx in

A lot of new contributors found their way to our mapping parties on the discourse forum, our coding raves at github, and the development zulip dancehall. You are all welcome and we'd like to thank you for all kind of input. With your feedback on the 2.5 beta version the coding team is on track for gold, the bugs and errors teams are already defeated.

I'm going on a holiday and …

While you're enjoying a well deserved vacation the Mixxx team is preparing new features. Not all new features are already for bundling in an official release but you can find everything about them in the partie venues.

The new visual aids for key and bpm will be astonishing, it needed quite some adaptations but the project is in pole position for gold.

The color integration will give you intuitive directions of matching tracks for harmonic mixing, also for people who suffer off color-blindness. Soon you will be able to discover a 'heat column' in the library which will give you hints on tracks that are compatible with the current playing track, based on the Key and BPM. And BPM coloring will be added to show tracks with a BPM close to the current tempo. This will be our first step in Intelligent Assistance, it can inspire you to make surprising Mixxx-es with tracks that slipped your mind. And these features will later be used later for some QOL features, like an improved suggestions algorithm, search ranking based on similarity, and adding key color ticks on the rate sliders. Fill the floors!

Our marathon stem project is fantastic, a peek behind the curtain: Playing with stems changes the whole idea of DJ-ing. If stems are new for you I would like to invite you to do some research. In brief: stems are regular music files that are separated in 4 stem-tracks by the original producer or with the aid of AI. Mostly those tracks are drums, bass, melody and vocals. Together with the original track are those 4 new tracks combined in a new container, a .Stem.MP4 or .Stem.M4A file, lossy or lossless (depends also on source). While other DJ software will only support lossy stem files, we choose to support both. These combined files can be 'remixed' on the fly, with other words: the volume of the tracks can be individual controlled, a track can also be muted e.g. if you mute all tracks except the vocals you are actually playing an a capella.

Without stems you need the beats to be synced, even if the intermediate beat would fit better to cover bass/drum sounds, you need to work hard with the eq's to camouflage bass left-overs. With stems you can just completely hide the unwanted tracks.

Remark: The quality of the stems is of course very important, a lot of stem creators are showing up everywhere. Some need you to upload your original file, some can use your GPU, some use well trained AI models, others don't. On Zulip I wrote a report about my quest for stems.

In development Mixxx is already at the point that lossy and lossless stems can be played and controlled as stems, stem controls are already working and can be experimental mapped in controller mappings.

DJ-ing with stems is a gamechanger, it takes away limitations, gives your creativity a boost. A hint: controlling stems with the mouse is rather difficult, some controllers are already stems-ready which means they incorporated volume potentiometers and mute buttons for the different stem tracks. But don't throw away your valuable controller. I have experimented successful creating a OSC midi controller to control stems (and samplers) from a tablet, when finished the files will be available. Or you can start looking for an extra midi-controller that has enough potentiometers to control the volume and mute buttons of the stems (advice: 4 volume potentiometers, 4 mute buttons maybe 4 potentiometers for the effect on the stem-track and buttons to select the deck).

If you're waiting for an official release with stem support, you'll have to be more patient.

Ceremonie protocollaire

A golden medal will be awarded to everyone who contributes to Mixxx. Have a crazy Mixxxy summer.

Mixxx 2.5 beta released

2024-06-25T07:17:16+02:00

It's springtime, and baby birds recently hatched from their eggs are looking out of their nests deciding if they are ready to fly. So too it is with Mixxx, and version 2.5 is almost ready to greet the world. A bit late for Easter but it is a magnificent giant gift filled with smaller gifts: Mixxx 2.5 beta! You can find the details about the new version below.

Appeal

Before releasing 2.5 as the next stable release, we need it to be tested thoroughly, something we can't do all on our own. After some time looking at the same release and searching for solutions, we might overlook minor bugs or problems.
That's why we need YOU to help us. The more people testing this beta and reporting eventual bugs to the bug tracker, the faster the beta can be promoted to stable.
In case you're scared of messing up your neatly configured PC and losing your holy data is your Halloween nightmare, read the new wiki article Safeguard Your Mixxx Data. It explains how to create a timestamped image, how to back up your data, and other tips and tricks.
A beta release contains the solutions for problems that occurred and were notified by users who tested the alpha release. The beta release is a general check before the new version can be released.
The Mixxx database and settings of Mixxx 2.4.x stable are equal to those in Mixxx 2.5 beta, which means you can install the 2.5 over the 2.4 and vice versa without a problem.
After you have successfully tested this 2.5 beta for yourself, you can continue using this version in your bedroom or even during live DJ-ing, and thus benefit from the new features.
Please join Mixxx. In Mixxx, we (can) trust.

Highlights

In version 2.5, Mixxx moves from depending on Qt 5 to Qt 6. This will improve hardware support and will enable Mixxx to be compatible with latest operating systems and hardware. However, this upgrade necessitates the discontinuation of support for older operating systems, specifically macOS versions earlier than 11, Windows 7 and 8.1 and Ubuntu 20.04 "Focal Fossa" and older.
Controller mapping settings can now be adjusted directly in the preferences, compared to previously where they would have to be manually edited in script files. Controller settings are only available for JavaScript mappings. We will remain open for mapping contributions to 2.5 which add setting definitions. An example on how to do so can be found on this pull request for the S4 Mk3.

Here are some more highlights:

Display the number of beats and the time until next hot-cue or loop in the waveform #12994
Visualization of Slip Mode when using the RGB GLSL waveform #13002
An option to hide the main window menu bar #11526
A command line option --start-autodj to start Auto DJ immediately after Mixxx starts. #13017
A beatloop anchor to set and adjust loop from either start or end #12745
New effects: A Compressor #12523 and Glitch #11329
Support for Audio Unit (AU) plugins on macOS #12112
Modify properties on multiple tracks at once #12548
An experimental QML Skin that can be tested via the --qml command line option #13152

What's else new / changed / corrected in 2.5 beta

The full list of changes can be found in the ChangeLog

You can download the new release from the Download page.

Mixxx 2.4.1 released

2024-05-09T15:07:38+02:00

Dear Mixxx-ers

The Mixxx developers started the year with good intentions and therefore imposed some deadlines on themselves. That is why only three months after version 2.4, version 2.4.1 has been released. This version delivers solutions for minor bugs and issues that came with 2.4.

What's new / What's changed / What's corrected in 2.4.1

You can download the new release from the Download page, the list of changes can be found in the ChangeLog

Controller Mappings

Behringer DDM4000 & BCR2000: Fix exception in JS code #12969
Denon DJ MC6000MK2: Fix mapping of filter knob/button #13166
Denon DJ MC7000: Fix redundant argument and migrate to hotcue_x_status #13113 #13121
Hercules Inpulse 200: Configure shift-browser knob to scroll the library (quick) #12932
Pioneer DDJ-FLX4: Add waveform zoom and other mapping improvements #12896 #12842
Traktor Kontrol F1: Fixes for hid-parser and related script #12876
Traktor S2 Mk1: fix warnings #13145
Traktor S3: Fix mapping crash on macOS #12840
Controller I/O table: sort action column by display string #13039

Target Support

Fix various minor build issues #12853 #12847 #12822 #12892 #13079 #12989
CMakeLists: Always prefer OpenGL framework on macOS #13080

Skins

Deere: make sampler rows persist #12928
Tango: Remove unneeded waveform Singleton #12938
Prevent possible crash in customs skins using parallel waveforms #13043 #12580 #13136
Slider tooltip: consider orientation for up/down shortcut tooltips + add support for WKnobComposed #13088
Tooltips: update 'hotcue' with saved loop features #12875
Animate long press latching of sync button #12990
Polish fx chain controls #12805

Library

Sidebar: show track count and duration of History playlists #12811 #13020 #13019 #12788 #12880 #12882
Computer feature: update removable devices on Linux #12893 #12891
Playlists: Prevent removing tracks from locked playlists #12927
History feature: Fix removing deleted tracks after export #13016 #13000
BPM display uses decimal separator of selected locale #13067 #13051
Fix relink directory when migrate between Linux/macOS and Windows #12878
Allow adding new directories while watched directories are missing #12937 #10481
Require a minimum movement before initiating the drag&drop of tracks #13135 #12902
iTunes/Serato/Traktor/Rhythmbox: Print error if library file could not be opened #13012
Playlists: improve table update after deleting (purging) track files #13127
Fix Color column width issue #12852
Tracks: select track row when clicking the preview button (only when starting preview) #12791
Library track menu: show Hide action also in Playlist & Crates #11901

Miscellaneous

Remove unnecessary unpolish operation of the style, before polish the new style #12445
Developer Tools: Initially sort controls by group name, ascending #12884
Waveforms: Fix scratching crossing loop boundaries #13007
Prohibit un-replace when deck is playing #13023 #12906
Track Properties dialog: Prevent wiping metadata when applying twice quickly #12965 #12963
AutoDJ: Fix button state after error message about playing deck 3/4 #12976 #12975
Tagfetcher: Cache fetched covers #12301 #11084
Avoid beats iterator being one off and DEBUG_ASSERT in Beats::iteratorFrom #13150 #13149
Show hint if resource path in CMakeCache.txt does not exist #12929
Always calculate the auto value for colorful console output. #13153
Fix FLAC recording on macOS and Windows #10880 #13154

What happened?

I would like to share some memorable moments from the Zulip-chat that are significant for the atmosphere and motivation of the Mixxx team:

Not giving up...

Ten days ago a Mixxx-er posted a problem that he struggled with for over a year. He was unable to make a MIDI-connection between his Pioneer DJM-750MK2 Mixer with Mixxx and then activate the DVS (Digital Vinyl System) to work with Mixxx's Vinyl Control. A Mixxx developer took the challenge and during 2 weeks you could see the messages flying over: log-files, screenshots, debugging-info, tooltests, capturing communication, a new pull request... I think I've seen over 100 messages. Trying things, fail, one step forward, two steps back ... After two weeks the Mixxx developer managed to get it fixed. All from a distance, not having the hardware available, putting a lot of time in it. It was fantastic to be a witness of this magic.
Shout out to Niko/Swiftb0y !

Wow!

About three weeks ago a Mixxx developer proposed a new feature: showing the remaining beats till the next cue point in the waveform. After some writing, testing, rewriting ... he created a feature I couldn't do without anymore. If you make a hotcue at eg. a climax, or a loop, or an intro start in a song, you can see the remaining time (or number beats) until this point in the waveform. Once a DJ has used this feature, they can't live without it. This feature will be available in the next stable version 2.5
Shout out to m0dB !

What's going on in the Mixxx team?

At the moment some people are trying to get Mixxx ready for stems. Stems are a new multi-channel format of audio files with which DJ's can 'remix' the song on-the-fly.
A lot of people are improving controller-mappings to support more hardware with more features.
Research is ongoing to make Mixxx able to share its database over a network.
There's someone very keen on giving Mixxx the ability to support Spatial Audio.
Translators are very busy adapting the manual and interface.
Developers continue improving features, correcting minor bugs, and adapting code to support more machines and operating systems.
On daily basis Mixxx-ers are given adequate support for small or big problems. Every question is taken seriously.

There is no cure for the spreading Mixxx-virus, everyone is invited to join the Mixxx team.

Appeal

I want to take the opportunity to make an appeal to all Mixxx-ers: As we try to explain Mixxx's features in an optimal way and try to give the best possible support to every user, not everyone understands the English language as well as others. Especially when the language contains technical terms it can get confusing for not native speakers. If you understand the English manual well and you notice missing translations in your own language, please take the time to translate a/some part(s). It needs a little effort in the beginning, but you can make a huge difference for other users. We are available to get you started. Translators Wanted

Who's writing this?

Music was my first love and it will be my last. I like music, from Aaliyah to ZZ Top, from A Capella and Classical Aria's to Zouk, as long as it has a soul. Since I was very young I discovered the power of music, it can strengthen or change emotions. When I was thirteen (in the 80's) I started making my own radio show for myself, playing discs I found in my fathers (huge) collection. A family party started my DJ-career, I felt the joy of sharing music, making people happy with it, make them want to dance.

In the late 90's I got involved with BPM Studio, a superb but dated program. Dated because it was only compatible with MP3 and WAV. Soundquality was and is very important for me, the term audiophile describes me very well, so I don't want to make a compromise in the audio quality. Believe me, in the 90's, early 00's harddrive space wasn't that obvious and WAV-files took a lot of space.

BPM development stopped about ten years ago and Traktor worked fine for me until a couple of years ago. I could no longer trust and rely on Traktor for live gigs and I rediscovered Mixxx, with the versions 2.3.5/6 a big step was made.

I found a controller-mapping file (+10 years old) for my Denon HC4500 that worked fine. My first test: Auto-DJ (autopilot in Traktor) The software must be able to play music for days without an error = test of hardware and software. Mixxx passed the test gloriously. So started playing around with Mixxx, I started importing my live-library, playlists, crates and history, found some minor bugs which I discussed on the forum and in bugreports.

I got more and more interested. I found some translation problems so I offered to make the Dutch translate of the Mixxx-application. Meanwhile I started diving and swimming in the code to tweak some minor things, like exporting statusfiles, nowplaying, writing a new cpontroller-mappingsfile. To give something back to the Mixxx-community I answered questions about little problems in the forum, I translated the manual and I offered to write this announcement that became a sort of testimony.

And that all in about 12 weeks since I did the Auto DJ test.

Mixxx Plans to Acquire AlphaTheta, Serato and Native Instruments

2024-04-01T11:32:09+02:00

The Mixxx Board of Directors in pleased to announce plans to acquire the AlphaTheta Corporation (formerly known as Pioneer DJ), Serato Audio Research Ltd. and Native Instruments.

"This exciting consolidation of brands will reshape the DJ software market as we know it", Mixxx CEO Scrooge McScratch said after the decision was made. Some trademarks such as Rekordbox®, Serato® and Traktor® will likely be dropped to archieve a lean portfolio and focus on the popular Mixxx brand.

The move will lead to new synergies and enables Mixxx to benefit from the know-how of its former competitors. "Our new subsidiaries have a track record in profitable partnerships with hardware manufacturers.", McScratch commented. "We want to leverage their expertise on locking down DJ hardware artificially and ensure that the majority of DJ equipment in the market will only work with Mixxx. We are committed to our customers, so it's only fair to demand that they stay committed to us as well."

Google Summer of Code 2024, Get Involved

2024-02-29T13:35:00+01:00

Mixxx has been accepted as a mentoring organization for Google Summer of Code 2024, a global program focused on bringing new contributors into open source software development. This is a great opportunity for us to attract new contributors, as they will receive a stipend sponsored by Google.

How Does GSoC Work?

How to Get Involved?

You will find the GSoC 2024 Project Ideas for Mixxx in our wiki, but your own ideas are also more than welcome. Taking a look at our GSoC advice page is recommended if you're planning to apply. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our codebase.

You could also help us, even if you are not a GSoC candidate yourself. Simply print out a flyer and post it on the bulletin board of your local university.

If you are interested in past projects, take a look at the blog posts of David Chocholatý and Fatih Emre YILDIZ. Their work has been recently integrated into our new Mixxx version 2.4.

The official application period will start on March 18th and ends on April 2nd, so have your applications ready in time. Potential GSoC contributors should start discussing their application ideas on our Zulip now. Just start a new topic in the #gsoc stream. Please understand that we only engage with potential contributors via the respective channels in the #gsoc stream on Zulip or via the official GSoC application process.

Join us in improving Mixxx and contributing to free DJing worldwide!

Improved Scrolling Waveforms in Mixxx 2.4.0

2024-02-23T21:18:57+01:00

One of the major improvements in Mixxx 2.4 is a revision of the scrolling waveform implementation, to achieve smoother animation at a higher frame rate (60 fps), with fewer frame-drops and a lower CPU load.

The revision consists of an optimized rewrite, not only of the actual waveform drawing, but also of the additional overlapping layers, i.e., the beat grid, the looping-, intro- and outro-ranges, the markers and the end-of-track indication. The improvements apply to all supported platforms and are particularly noticeable on macOS.

New waveform types

The new waveform types are marked "(GLSL)" in the Waveforms section in the settings dialog. When upgrading from older versions of Mixxx, the GLSL waveform type that best matches the old configuration will be selected automatically, as well as a frame rate of 60 fps.

Visually, the new waveforms follow the design of the legacy waveforms, with some minor tweaks. Note for example the semi-transparently filled triangles pre- and post track. This also serves as a quick indication that you are using the new waveforms.

The newly implemented GLSL waveforms have been beta-tested for several months now and are considered stable and recommended. The old waveform types remain available, just in case, as an option in the Waveforms section of the settings dialog, marked with "(legacy)", and might be removed in future versions. If you experience issues with the new waveform types, you are encouraged to file a bug report!

Improved marker layout

Additionally, the markers layer has been improved: Multiple markers at the same beat grid location or sample position that would previously overlap and obscure each other, are now automatically stacked, placed at a respectively increased or decreased vertical offset. This applies to (hot) cue markers, intro- and outro-markers and loop-markers, and should be a big improvement for DJs that make heavy use of these markers.

Some technical insights

Mixxx uses the Qt software framework for its user interface. Originally the layers that form the scrolling waveform display were rendered on the now deprecated QGLWidget through a combination of QPainter and legacy OpenGL function calls. Profiling showed that this combination was a performance bottleneck, particularly on macOS.

With the rewrite, all the layers mentioned above are now implemented using modern OpenGL code: All different waveform types, i.e, Simple, Filtered, HSV, RGB and RGB L/R, are now hardware accelerated using GLSL shaders. In addition to the waveforms, the Spinny widgets and VU-meters code has been revised with the same approach.

The deprecated QGLWidget has been replaced by a custom solution using a QOpenGLWindow inside a QWidget using the createWindowContainer() call. Qt also offers QOpenGLWidget to replace QGLWidget, but the QOpenGLWindow solution resulted in better performance and integrated better with the existing source code. This change will also facilitate the migration to Qt 6, planned for Mixxx 2.5.

New display synchronization mode

To avoid visual jitter, the rendered waveform has to be displayed at the right moment. This is achieved by synchronising the scrolling waveform animation with the display refresh rate. As a last minute addition, an alternative mode to do so has been introduced, using a so-called phase-locked-loop (PLL). This mechanism attempts to track the actual refresh rate and timing of the display automatically. On particular hardware, the default periodic timer-based approach can result in jitter and frame drops, and the PLL may give better results. The PLL has been made the default on macOS, where the improvement was most noticeable; on other platforms your mileage may vary. See instructions to change the V-Sync mode if you want to try which mode works best for you. Note that this setting does not effect the audio control performance.

Official Flatpak now available on Flathub

2024-02-21T00:00:00+01:00

An unofficial Mixxx Flatpak package for Linux users has been available on Flathub since Mixxx 2.2.1. Today, all major technical issues with the Flatpak have been resolved, so we have decided to officially support this Flatpak package with Mixxx 2.4.0 and verify Mixxx on Flathub.

In the past, upstream Mixxx builds for Linux users have only been available on Ubuntu via a PPA. Now, this Flatpak brings upstream builds maintained by the Mixxx developers directly to users on all Linux distributions. The Ubuntu PPA is still maintained. If the PPA or a package from your distribution is up to date and works for you, there is no need to switch to the Flatpak.

Migrating to Flatpak

If you do want to switch from a distribution package or Mixxx built from source code to the Flatpak, a little setup is required. Flatpak stores Mixxx's database, settings, and custom controller mappings in a different location than the ~/.mixxx directory that Mixxx has always used before. Flatpak uses ~/.var/app/org.mixxx.Mixxx/.mixxx instead. To copy your database, settings, and controller mappings into the Flatpak sandbox, run:

mkdir -p ~/.var/app/org.mixxx.Mixxx
cp -r ~/.mixxx ~/.var/app/org.mixxx.Mixxx

If your library contains any directories outside of your XDG Music Directory (~/Music unless you have reconfigured this), you will need to relink these directories to access the files inside of Flatpak's sandbox. Run Mixxx from the Flatpak and go to Options > Preferences > Library. Any directories that have a warning icon with ! in a yellow triangle need to be relinked. Select the directory in the preferences window and click the Relink button, then select the directory in the file picker dialog. Flatpak will automatically remap the directory under /run/user so Mixxx can read and write your music files from inside the Flatpak sandbox. Press Ok in the preferences window, then in Mixxx's main window, go to Library > Rescan Library.

Technical requirements

Using the JACK sound API for audio input and output with the Flatpak requires running Pipewire with JACK support outside the Flatpak sandbox. Most distributions now install Pipewire configured as an audio server by default as a replacement for PulseAudio. However, Pipewire-JACK might not be installed by default and may need to be installed from your distribution package manager.

If your distribution uses systemd, the Mixxx Flatpak requires a recent version of systemd to use HID controllers. A bug fix for this has been backported to systemd stable versions from 252 and later. If your distribution, for example Ubuntu 22.04, has an older version of systemd, HID controllers will not work with the Flatpak by default. You can work around this by copying this udev rule file to /usr/lib/udev/rules.d/ and rebooting.

Mixxx 2.4 Released

2024-02-16T13:39:52+01:00

We are proud to announce Mixxx 2.4, a new major version of our free open source DJ software, available right now. It's been two years since the last release due to the large number of great new features and important changes under the hood. See the changelog for the full list of changes.

The 2.4 release includes the following highlights:

EngineOS Export

Mixxx 2.4 adds support for exporting crates, playlists and the library to Engine DJ OS devices, including Denon and Numark standalone controllers.

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

This allows users to prepare their tracks on a laptop using Mixxx and export them to a USB stick for use on a standalone controller at their gig.

Saved Loops

Mixxx 2.4 adds support for Saved Loops, which can be assigned to any Hot Cue slot. If you already have tracks from Serato DJ with Saved Loops, Mixxx 2.4 will import them automatically.

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Effect Chains

Mixxx 2.4 introduces Effect Chains, a set of effects which can be saved and reloaded with all their parameters and individual Meta Knob mappings. Effect Chains can also be exported and imported, which allows you to share them with other Mixxx DJs. Once you've created an Effect Chain, you can create a custom Super Knob mapping which turns the chain into a Quick-Effect, where you take creative control with a single knob. Effect parameters can be reordered and or hidden. In the effect units, Mixxx 2.4 also displays the value and unit of effect knob parameters while they are being adjusted.

Track Menu Enhancements

The track menu in Mixxx 2.4 is enhanced by several new features:

Select loaded track in library.
Analyze/re-analyze with variable/constant BPM on a per-track basis.
Look up track metadata at Discogs, SoundCloud and LastFM.
Remove track files from disk.

Sync Lock Improvements

Mixxx 2.4 adds support for manually selecting the Sync Leader by clicking on the new button with the crown symbol next to the Sync button. This mode is useful when tracks have variable BPM. All decks with sync enabled will follow the changing BPM of the Sync Leader.

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Many Other Changes

Soundstretcher / Key-Shift Algorithms

Mixxx 2.4 now supports three different key shift algorithms:

Soundtouch (Basic audio quality - medium CPU usage)
Rubberband R2 (Good audio quality - higher CPU usage)
Rubberband R3 (High audio quality - very high CPU usage)

Waveform Rendering Reworked

The waveform display has been rewritten, solving some longstanding performance issues, especially on macOS.

Apple Silicon Support

Mixxx now supports macOS ARM systems ("Apple Silicon") such as M1 natively and provides installation packages for those architectures. For macOS users, this increases the stability and performance of Mixxx on Apple silicon.

Controller Backend

Modernized Javascript ES7 based controller mapping system. HID backend rework.

Mixxx 2.4 Factsheet

Supported Platforms

Windows 7 or later on 64bit processors
macOS 10.12 or later on Intel processors
macOS 11.0 or later on ARM processors (Apple Silicon)
Ubuntu Linux 20.04 or later (other Linux distributions are supported by third parties)

Supported Controllers

Mappings for 129 MIDI controllers included
Mappings for 16 HID controllers included

See the full list of supported controllers in the Mixxx Manual.

Press Information

Mixxx 2.4 is available right now: https://mixxx.org/download/

The manual for Mixxx 2.4 can be found here: https://manual.mixxx.org/2.4

Images For Media Use

Full-Resolution images of the Mixxx 2.4 screenshots above can be downloaded here: https://mixxx.org/screenshots

Press Contact

Feel free to contact us via: press@mixxx.org

Mixxx 2.3.6 released

2023-08-15T13:09:47+02:00

Welcome the Mixxx release version 2.3.6, the final maintenance release before releasing the upcoming 2.4.0 with exiting new features.

This small bug fix release may appear insignificant, but it's a testament to the rock-solid quality we bring to every user to ensure a reliable mixing experience.

This release improves, among other things, some details with looping, allows playing tracks exceeding 6 hours and fixes rare crashes in exceptional situations.

You can download the new version from the Download page. There, you will also find the 2.4 beta to test the new features that will be released soon.

Here is the full changelog of Mixxx 2.3.6 for more details:

Fixed possible crash when closing Mixxx while browsing the file system #11593 #11589
No longer stop a track with an active loop at the very end #11558 #11557
Fixed resyncing when moving an active loop #11152 #11381
Allow true gapless playback when repeating full tracks #11532 #9842 #11704
Rhythmbox: Fixed bulk track imports from playlists #11661
Console log spam reduced #11690 #11691
Numark DJ2GO2 Touch: Add missing loop_out mapping for the right deck #11595 #11659
Shade: Fixed VU-Meter and other minor issues #11598
Fixed a rare crash when disabling quantize form a controller #11744 #11709
Controller Preferences: Avoid scrollbars in I/O tabs if Info tab exceeds page height #11756
Broadcast: Improved error message in case of timeout #11775
Handle setting loop_in and loop_out to the same position #11771 #10600
Fix build issues with Protobuf v23.4 and with clang 32 #11751 #11765 #11762
Disable GL VU-Meters on Windows by default. They can be re-enabled via the command line option --enableVuMeterGL. #11787 #11785 #11789
Library preferences: Uncheck Serato metadata export when file metadata export is unchecked #11782 #11226
Denon MC6000MK2: Delete mapping for master gain #11792
Improve output in case of some failed file system operations #11783
Fix overlapping buffers when decoding M4A files using FFmpeg before 4.4 #11760 #11545
Don't reject key values from file metadata with non-minor/-major scales. #11001 #10995
Allow playing tracks with durations of more than 6 hours #11511 #11504
Update latency compensation for Soundtouch version 2.1.1 to 2.3 #11154

Mixxx 2.4 beta release

2023-05-31T11:29:40+02:00

It's been a while, but after almost exactly 3 years, we're proud to announce the beta version of the next major release: Mixxx 2.4!
Keep your eyes peeled for the stable version of 2.4 being released in August if everything goes according to plan. In the meantime, we need help from YOU! In order to get 2.4 stable, we need lots of people testing this beta release, the more, the better. Please download it and report any bugs you find on our bugtracker.

Here's a quick look at the most important changes and new features you can look forward to in Mixxx 2.4:

Support for saving loops as hotcues ("Saved Loops").
Save effect chains and then load them into effect units or the QuickEffect
Native Apple Silicon support (better performance on M1/M2/etc. devices).
Explicit Sync leader.
New controller mapping scripting engine (ES2016 support).
New "all-shaders" Scrolling waveforms resulting in much better GUI performance on all platforms (especially MacOS).
A bunch of polish for the Library.

Expect a more in depth blog posts for each of these features in the coming weeks.

You can check out the full changelog on github.

Mixxx 2.3.5 released

2023-05-11T00:00:55+02:00

Another bugfix release, this soon?

Yes, unfortunately it turned out that 2.3.4 introduced a couple of serious bugs that required prompt action to fix in order to rectify this subpar release.

The most serious issue we fixed was a regression that caused an empty waveform overview after loading a track. This issue has been fixed in version 2.3.5, along with several other bug fixes and improvements.

Other notable changes include requesting microphone and line-in access on macOS, allowing explicit selection of buffers of 2048 and 4096 frames per period in the JACK API, making the Beat FX section of the Pioneer DDJ-400 more intuitive, and fixing a visual issue with the the VU peak indicators in the Tango skin.

Overall, version 2.3.5 aims to improve stability and performance while addressing the issues introduced in the previous release. Users are encouraged to update to this version as soon as possible to ensure the best possible experience while using Mixxx.

Here is the full change log if you're interested:

Fix empty waveform overview after loading a track (Mixxx 2.3.4 regression) Fixed by #11333 #11359 #11344
Fullscreen: Fix a crash that occurs on Linux after enabling fullsceen and using menu shortcuts e.g. Alt-F. #11328 #11320
Fullscreen: Rebuild & reconnect menu only on desktops with global menu #11350
macOS: Request Microphone and line-in access permission. #11367 #11365
JACK API: Allow to explicit select buffers of 2048 and 4096 frames/period. They are not supported by the automatic buffer setting of the used PortAudio library. #11366 #11341
Pioneer DDJ-400: Make Beat FX section more intuitive #10912
Playlist export: Adopt new extension after changing the playlist type #11332 #11327
LateNight: brighter fx parameter buttons #11397
Fix drift in analyzis data after exporting metadata to MP3 files with ID3v1.1 tags #11168 #11159
Fix broadcasting using Opus encoding #11349 #10666
Tango: Remove VU peak indicators from stacked layout. This fixes a visual regression in Mixxx 2.3.4. #11430 #11362

Mixxx 2.3.4 Released

2023-03-03T18:51:28+01:00

You know the drill, another 2.3 bugfix release. Mixxx 2.3.4 to be exact.

Let's take a look at the changes:
macOS received a bunch of love, especially in regards to possible UI performance problems and translation issues. We also enabled support for macOS 13 (Ventura) on Intel-CPUs, while there is still some work in progress to support Apple silicon from Mixxx 2.4.0.
In addition, our Tango and LateNight skins received a lot of minor tweaks and visual fixes.
Issues occurring during metadata import from 3rd party software were also fixed. This includes issues when fetching data from MusicBrainz as well as importing metadata from Rekordbox databases or music files containing Serato metadata.

Since we include controller mappings in bugfix releases, we can also announce that we gained support for the Traktor Kontrol S2 Mk1 and the Numark Party Mix.
Some existing mappings also received some attention, especially Numark ones because plenty of community members discovered that the Pitch/Rate-slider was inverted in a couple mappings.

That's about all for 2.3.4. If you're interested in the full changelog, you can find it on GitHub.

As usual, we recommend you update to the newest stable version by visiting our download page

Mixxx accepted for GSoC 2023!

2023-02-27T09:42:04+01:00

Mixxx has been accepted as a mentoring organization for Google Summer of Code 2023, a global program focused on bringing new contributors into open source software development.

This means that new or even established contributors of Mixxx have the opportunity to work on Mixxx full-time during the summer for 12+ weeks while receiving a stipend sponsored by Google. For more information, check out the Google Summer of Code Contributor Guide.

You will find the GSoC 2023 Project Ideas for Mixxx in our wiki, but your own ideas are also more than welcome. Taking a look at our GSoC advice page is recommended if you're planning to apply. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our code base.

You could also help us, even if you are no GSoC candidate yourself. Simply print out a flyer and post it on the bulletin board of your local university.

If you are interested in last years projects, take a look at the blog post of David Chocholatý and Fatih Emre YILDIZ. Their work will have a great benefit for our users in the upcoming Mixxx version 2.4. You can already test them in a development snapshot of 2.4-alpha

The official application period will start March 20th and ends on April 2th, so have your applications ready in time. Potential GSoC contributors should start discussing their application ideas on our Zulip now. Just start a new topic in the #gsoc stream. Please understand that we only engage with potential contributors via the respective channels in the #gsoc stream on Zulip or via the official GSoC application process.

GSoC 2022 Work Product - Track Suggestion Feature

2022-09-26T19:26:29+02:00

Disclaimer: The blog post primarily serves as the documentation for the Google Summer of Code 2022 project: "Track Suggestion Feature". Thus, it contains a lot more detailed description, than the other Mixxx blog posts.

Introduction

After long hours of playing, when the floor is crowded the question shows up. "What to play next?". That is a big problem for almost every DJ. This project aims to give suggestions according to tracks playing on the decks. With this feature, Mixxx will have a helper for all the DJs.

Hey everyone It's Emre! You've just read my project description. First, let me introduce myself before I dive into a detailed explanation of my project. I love to listen and play music. I have been always into DJing. That's why I wanted to take a part in Mixxx. I am a person who plays music while chilling-partying with my friends. They always find my music choices are the right fit. But they don't know how difficult to pick the right song, especially after a while of playing. So I thought Track Suggestion Feature would be the best project to work on this summer.

Motivation

The track suggestion feature was on the wishlist a long time ago. This feature was mentioned firstly on the Bug Tracker and on the Forum. These discussions inspired me to do this project.

Before we started to work on this project, My mentor and I decided to do it with side projects. We chose the side projects, so the implementation of the enormous features split into pieces. With that, we have a chance to test and review them in smaller environments. These side projects also helped me to get to know the code base, we can think of them just like preparation ground. Also, in one of those side projects we have encountered a bug that took long time to review and test, there was a risk to exceed the time of the project, but luckily we made it and could focus on the main part.

We have come up with a few different side project ideas.

The first idea was to have a feature called Find On Web. This feature aims to help users if they are looking for additional info about a track on online music databases. After this is implemented roughly, we decided to polish it with the Factory Design Pattern which simplifies adding other online music databases later on. After these two side projects we decided to get cover art of the tracks which is Cover Art Fetcher. When I collect tracks for my library, I always wanted to have the correct metadata of the track and also the correct cover art. As a person who cares about appearance a lot, I thought that I am not alone in this situation and people would love it too. That's why I found this side project very helpful and important! At last, the main project comes along, the Track Suggestion Feature which is getting Track Suggestions from various services.

Implementation

Find On Web Feature

The first side project Find On Web is supposed to help user finding additional info about a track, album, or artist.

Think about a scenario, you have only just a track from an album and you would like to get more information about other tracks in that album. Until now, you would first open your favourite web browser, then you type the Artist and Album in your search engine, you hit the button to search and you find the web page and finally you can get more information. This is very time-consuming. This is where the Find On Web comes in handy.

Let's think about another scenario. You love to find out remixes of each track in your library and with those remixes you expand your library. You probably use SoundCloud or a similar service very often. Luckily we have this service in our Find On Web feature. If you are looking for remixes in your library very often, Find On Web feature will help you along with that.

This feature is placed in the Track Menu. When you right-click on a track, you will see different Menus and Actions that you can take over a track. This is called Track Menu. On the track menu, in the Metadata section, you can see the Find On Web. There are three main Online Music Databases that exist as menus. They will be called services after this part. These services are:

When you hover your mouse over those services menus, you can see the related track properties as actions. Each action populates the suggested service with the suggested track information for your default browser. This looks like:

Find On Web Feature

This Implementation was designed roughly for the next step. The next step was:

Find On Web With Factory Design Pattern

This implementation aims to have a Factory Design Pattern for the Find On Web feature.

As its name states, you can think about you have a factory and you can produce products. Our factory is the Find On Web itself and our products are the services. The most important point here is that all products coming out of a factory must be derived from the same interface or class. Thanks to this pattern, you can abstract our Services for future use. You can produce products - add new services - straight forward.

Since there are many other online music databases, that is nice to have Find On Web feature with the Factory Design Pattern. Just in case if needed any other service can be added easily without making any changes in the code base.

Related Files:

Editable Track Menu

While discussing Find On Web feature and where we could placed it on Mixxx. We have decided to place it on Track Menu. There was an idea on Zulip, that the Track Menu was gettin crowded, and we can consider to make it configurable.

At first I thought the same and this feature would be nice to have and that can help me to get to know the code base for the preferences option.

I introduced this idea on the Zulip channel. The idea of making the track menu configurable rejected in the discussion with the community in favor of Mixxx. Sometimes the configuration option proves the developers' inability to make decisions for them. As a result, we have chosen not to implement this.

Cover Art Fetcher

This is the third side project for the Track Suggestion Feature. Fetching cover art from online resources. According to the search we have done, we decided to fetch the cover art from Cover Art Archive (CAA) hosted by Archive.org . The Cover Art Archive is a joint project between the Internet Archive and MusicBrainz.

The CAA uses the track's Release MBID (MusicBrainz Identifier) to retrieve cover art. For that, the Import Metadata From Musicbrainz feature could be used.

To get cover arts, we needed two different processes that should work in order. These processes are called tasks. First, we should get the cover art links. Second, by using that links and according to the user choice we should get the cover art itself.

Cover Art Archive works a little bit different than the other services. I discovered that after I sent my first-ever request. I received the response but it was redirected. Thanks to Qt's class QNetworkAccessManager has Redirect Policy which is designed for these situations.

The response consists of links to the cover art in different sizes. The possible sizes were 250px and 500px all the time and if it is available 1200px and also the HQ. This response also had the back cover art of the albums. After discussing that with the community, we have decided to only allow the front cover art but with every possible size, which includes the HQ!

On the preferences the user will see these options:

Lowest: 250x250
Medium: 500x500
High: 1200x1200 if available on CAA.
Highest: More than 1200px if available on CAA.

Then we needed the second task to get the Actual Image of the cover art. According to the preferences chosen by the user, the actual image is retrieved.

After this task was successfully done, there was only one thing left and it was the use case.

The best use case was to change the Import Metadata From Musicbrainz window to be suitable for cover art fetching and updating metadata at the same time. That was solving all the possible issues mentioned.

Right now, users can select between the lowest quality to highest quality, when they press apply on the tag fetcher cover art is downloaded and updated for that track.

Related files:

coverartarchivelinkstask.cpp

coverartarchiveimagetask.cpp

Cover Art Fetcher

Track Suggestion Feature

This is the main part of the project. In my opinion, Track Suggestion is a cool feature for a DJ app. Getting a hint for the next track at right time would be so precious for a DJ. But the possibility of the finding correct track has also the same amount of difficulty.

To find similar tracks, we have used Last.fm. Thanks to their API we can get track suggestions by just providing the Artist and Title. What is changed is basically on the library sidebar, there is a new feature called "Track Suggestion" which can be turned on or turned off on the preferences page. There are five different sub-menus located under this feature. Four of them belong to the decks and one of them belongs to the user's choice. When a track is placed on a deck, the correlated sub-menu changes to the Artist | Track Title. If the user clicks on that menu a new library is populated. If the suggestions are fetched before the user will be retrieved from the database, if it is not, the user will see a button that says Load Track Suggestions For Artist | Track Title. After this button is pressed, we send the request and get the response cached in the database.

The new library is an External Library. The located tracks are not available to play, because they are only text retrieved from Last.fm. But the tracks listed in that library can give an idea to the DJ about what to play next. DJ can see a title or an artist, and with that, this title or artist can guide the DJ to pick the next song.

There is a problem with the Last.fm service, when the track or artist name is misspelled the suggestions can not be fetched. Also for some tracks, there is no suggestion available on the Last.fm servers. To fix this issue, we have discussed a few different solutions, such as finding another service as a back up.

Track Suggestion Feature

Related files:

Pull Requests and Issues

Pull Requests

mixxx#4697 - BasePlaylistFeature: add popup asking deletion playlist

Status: Merged

This PR is the beginning of my story. That was my initial PR in my open-source experience. As mentioned on the Mixxx GSoC advice page before, I fixed a bug from the easy tag.

In order to do that, I needed to fork the project, clone it, compile it, make changes, install the pre-commit, push the changes, and open a PR.

As a total beginner, that took my whole day to figure things out. But If I look at it now, I can say that I am more experienced and that it is easy peasy - lemon squeezy.

mixxx#4700 - CrateFeature: add popup to avoid accidental remove of Crate

Status: Merged

This PR is similar to my first PR. After the first PR is merged, That was also mentioned on the bug that it is needed for crates as well.

mixxx#4752 - Parserm3u export

Status: Merged

This PR aims to have a better playlist/crate exporting experience. While I was surfing on the discourse, in one of the topics a user asked a question related to the exporting playlist. To help the user, I tried to export my playlist, but suddenly I realized that when I import my playlist back, there were some missing tracks. I have mentioned that on Zulip and with the help of other developers, I realized that there were missing characters and I wanted to solve this issue. This PR is about that issue.

Meanwhile, I've learned that m3u files can have different encodings while m3u8 files are UTF-8.

mixxx#4772 - WFindOnWebMenu: Menu for to find track properties in online music databases

Status: Merged

This PR was my first PR in the coding period. FindOnWebMenu helps users to find related track properties on various online music databases.

In this PR, I had the chance to get to know the code base and got familiar with the QT. I also used the git command rebase for the first time, that was difficult at those days, but right now I am more experienced with the git commands.

mixxx#4836 - WFindOnWebMenu: Implementing the factory pattern

Status: Merged

This PR is the second step of the previous one. This changes all the code into the factory pattern.

In this PR, I have learned design patterns. Not only the factory design pattern, I also learned the other design patterns, such as Abstract Factory, Singleton, and more. I am pretty sure that I will encounter these general problems in software and I will use the design patterns.

mixxx#4851 - Cover Art Fetcher

Status: Open (WIP) | last GSoC commit: 8856e4b

This is the main PR about the cover art fetcher.

mixxx#4864 - Cover Art Label & Cover Art Full Size composition with menu

Status: Merged

There was a problem with the cover art label displayed on the cover art fetcher. We decided to implement the cover art fetcher into "Import Metadata From Musicbrainz", and I wanted to add the existing cover art and the fetching cover art on the "MusicBrainz" dialog. The problem was, the cover art menu which consists of actions "update-clear-reload" was populating from the fetched cover art label too. To solve that, we first decided to have a base class for the cover art label which doesn't have any menu at all, and Inherit another label which has the menu. But this was not good looking in the code base with the duplication of the code and also locating/naming of the new base class. So with the help of my mentor, we have decided to have a composition approach. This has taught me a terminology in Object Oriented Programming. Which is very simple but effective in design. Is-a & Has-a * relationship. When we inherit from a base class, we can simply say "Cover Art Label is a Cover Art Label With The Menu". But that doesn't just sound right. So instead, we added Cover Art Menu as a parameter in the constructor. Now we can say "Cover art label has a* cover art menu". Thanks to this PR, this is not going to be used just not in the cover art fetcher also in the cover art worker.

mixxx#4871 - DlgTagFetcher new feedback system

Status: Open (WIP) | last GSoC commit: 47bbc15

This PR was to aim for a better interface for "Import Metadata From MusicBrainz". Because when the user wants to get cover art from the cover art archive, the process was too long and confusing about the initial status of cover art fetching. To have a better feedback system, we have decided to add a QProgressBar to show the initial progress not just for the cover art archive, but also for fetching Metadata from Musicbrainz. While Implementing this new feedback system, I discovered a few related bugs that were affecting the existing release of Mixxx version 2.3. That PR and also the bugs were going to lead me to learn more.

mixxx#4887 - Ask user after changing the cover art.

Status: Draft | last GSoC commit: 693ab90

This PR was about a "TODO:" comment in the code base. But after I work on it for a while, I discovered that this is a must, for the cover art fetcher. This PR asks users if they want to copy the cover art which they have updated. It started simply with a QMessageBox and then became big with the needed implementations. Such as making it atomic writing, moving to a separate thread, and adding a comparison between the old and new cover art. This PR was becoming more bigger and difficult to review-implement. So we had to break this into smaller PRs but this one is still open for the future implementation.

mixxx#4909 - CoverArtUtils: Fix Reload From File/Folder, Updates Wrong Cover Art

Status: Merged

This PR aims to fix the related bug mentioned below.

mixxx#10822 - Fix: Rate limit exceeds for Musicbrainztask.

Status: Closed

This was a bug that I noticed while working on the new Musicbrainz design. I've tried to fix this by adding a state called "Looping" in the first place. But later on, this PR was superseded by mixxx#10875. But even though, thanks to my mentor for providing additional information about how to overcome this issue. I have learned about the activity diagram 'Swimlane' and UML State charts.

mixxx#10860 - Track Suggestion Feature: Get tracks suggestions according to the track playing on the decks

Status: Open (WIP) | last GSoC commit: 0c02074

This is an initial PR about the Track Suggestion Feature. This is used Last.fm's API to get similar tracks that are placed on the deck and also tracks selected by the user.

mixxx#10861 - BaseSqlTableModel: remove duplicated line.

Status: Merged

While I was working on the Track Suggestion feature, I encountered a duplicated line in one of the classes. This PR deletes this duplicated line.

mixxx#10878 - FIX: Tag Fetcher close button doesn't abort task

Status: Merged

This PR aims to fix the related bug mentioned below.

mixxx#10897 - Moving SafelyWritableFile class to the utility folder.

Status: Merged

This is a part of the cover art copy worker PR. This PR aims to move the SafelyWritableClass from inside a file to the utility folder.

manual#517 - Update Getting Involved

Status: Merged

There was a new user who introduced himself on the Zulip channel. I wanted to give additional information to guide him. To do that I was looking at to documentation and realized that the links for bug reporting were directed to the launchpad which was the old bug tracker of Mixxx. This PR aims to delete the old links and replace them with the GitHub issues link.

mixxx#10902 - Cover Art Copy Worker

Status: Open (WIP) | last GSoC commit: 2e13c64

This PR was opened due to the size of the PR about "Ask user after changing the cover art". This is the smaller version of it. There is no comparison, wizard, or dialog but the other must-needed parts for the cover art fetcher are included in this PR.

mixxx#10908 - ImageFileData class added to write images without loss

Status: Merged

While the worker was writing new cover art where the track was located, there was a decrease in the cover art file size. This PR was needed to save the cover art without loss. While working on this I have learned that the formats for images. Between these formats, "jpg"-"jpeg" format(s) is a lossy format that compresses the images. That is useful for websites to downgrade the size of the web page but not in our situation which quality is really important.

Issues

mixxx#10877 - Closing Tag Fetcher via the "x" close button doesn't stop the WebTask

Status: Closed

I was testing the latest status of the Tag Fetcher. If the Musicbrainz window is closed via the ESC button or 'x' button the Tag Fetcher was not aborting and working in the background.

mixxx#10816 - Updating Cover Art on Track Properties Doesn't Take Effect

Status: Open

This bug is related to the Track Properties and it is different than mentioned in the title. Normally all the cover art actions update the cover art right away, but when we update it on the track properties the cover art was not updated. That was a mistake by me and this was the correct behavior of the track properties.

The bug is actually when the new cover art is updated on Track Properties and the user wanted to see it in full size, the old cover art populates.

mixxx#10807 - Reload From File/Folder, Updates Wrong Cover Art

Status: Closed

This was a bug that I encountered while working on the cover art fetcher. I have updated the cover art of all the tracks in my library. But the problem was all of my tracks were updated with only single cover art.

mixxx#10796 - If MusicBrainz Returns an empty XML (404) whole task fails and no results displayed

Status: Open

This bug was affecting some of the tracks in my library. While I was working on the Tag Fetcher, I realized some songs in my library could not get metadata from Musicbrainz. There was an error. That was displayed as "Not Found" on the Tag Fetcher. But the logs were different, there were some successful results, and they exist on the MusicBrainz. But importing metadata for these tracks was failing for some reason. When I dig that down, I realized that the responses from Musicbrainz are successful but empty, and in the codebase that was meant to be no results. This is still in progress, but after that is resolved we will increase the rate of the successful results of our Tag Fetcher.

mixxx#10795 - Rate Limit exceeds for some songs while Importing Metadata From MusicBrainz

Status: Closed

This bug is discovered the same as above. The error message displayed to the user was confusing too. The difference is, it was quite easier to find out why there was an error. The tracks that can not have the results were the ones that have a lot of Recording IDs compared with the other tracks. When that is dug down, we found out that MusicBrainz Rate Limit was a request per second. But that was designed without any delay. That's why if a track has many Recording ID's retrieved from AcoustID, we were hitting the rate limits.

mixxx#10782 - Mixxx crashes when click on a track updated with Musicbrainz Metadata

Status: Closed

This bug was happening due to debug assertion when I select the tracks updated from "Import Metadata From MusicBrainz".

Discourse

In my free time, I was surfing through the Mixxx Forum to help the users as much as I could with my knowledge. In some of the topics, I was able to help the users, these topics and my answers were:

Discourse - Exporting a playlist to m3u invalid characters

Discourse - Easy Uncheck Assume Constant Tempo In Track Properties When Default

Future work

There are only a few to-do's left for the side projects we have discussed before. They can be improved just like in any other feature that exists in the Mixxx. For the track suggestion feature, there are still additional future works that still needs to be done. These are:

Merge the cover art worker for Cover Art Fetcher, with the caching class of the fetched cover art Cover Art Fetcher can be easily integrated.
Specialized External Playlist model for Track Suggestion Feature for better database interaction
Determination if the suggestions are in the user's library, with that Track Suggestion Feature can be much more useful.

There are a few ideas that have been discussed before on Zulip. These are not mandatory works but that would have been nice to have. These can be future references.

Get cover art of the suggestions so the Track Suggestion Feature would look better.
User Clustering Playlists! There was a brilliant idea while we were brainstorming about Track Suggestion Feature. User's can make their own suggestions by using their own library.
There could be a field in preferences for Find On Web feature, which is a field that can be filled by the user. With that users can add their own services.
Find On Web could have a preference option to enable - disable the services.

Things I learned from GSoC

First of all, I can easily say that GSoC was one of the best experiences in my life. It deserves Its title "Summer of Code" I had a great summer full of coding. I learned a lot and had so much fun. During this period, being an open-source contributor to a community felt amazing. Before the GSoC, I did some projects for my university projects and used git very basically. But for the first time in my life, I did coding for a real project and used git professionally, and learned a lot about it. I have learned that every aspect is really important while coding and even small glitches can cause a big bug. I have developed features which people can use. Fixed existing bugs that people encountered. This was such a unique experience. If I haven't met GSoC this year, I wouldn't be an open source contributor or I would have been very late in another time in my life. I can easily say that I've learned a lot about C++, Qt, design patterns, web services, testing, debugging, git and gained important experience on all of them. What I have learned was I am enjoying hours of coding, testing, hunting bug, and solving problems. If I have to compare myself before and after the GSoC, the difference is huge.

Conclusion

At the end of the coding period, the decided side projects and their little steps were implemented into Mixxx. Such as Find On Web, Find on Web with Factory Design, and Cover Art Label without a menu. Besides the side projects, there were many bugs (which were affecting both the stable 2.3.3 version and the upstream branch) reported and fixed. Such as the empty XML, the rate limit of MusicBrainz, aborting the tag fetcher, etc. With those fixes, Mixxx users will have a better fetching metadata experience. At the end of the period, unfortunately, the Track suggestion feature couldn't be implemented into the Mixxx code base but we have a working POC as an open PR. Also, an existing request from a long time ago was discussed seriously with the developers and users on the Zulip GSoC channel. We have over-searched the available services and discussed the main problems with fetching suggestions from different services, how to make this feature useful and what needs to be done to have the best use-case. This will be a reference to the future for sure.

Acknowledgements

I want to start with how great Mixxx is! Since the first day I joined the community and introduce myself on Zulip today, I am enjoying it a lot and I am so happy to be part of Mixxx. Everybody in the community was really helpful and they are doing their best to make Mixxx the best DJ Software. I would like to thank all the developers and contributors who contributed to Mixxx in any way.

I can not express how thankful I am, to my mentor @Daniel Schürmann. He has been such a great adviser, teacher, and guide from the very beginning to the end of the project. It won't be my fault if I say that he has been the best mentor! Besides being a really good mentor, he was so friendly. The ideas that he shared with me broadened my aspect through the project. At the beginning of the project, I was nervous about the whole big thing that needs to be done, and he gave me perspective in those sorts of circumstances. That was "broom stroke after broom stroke". This perspective helped me from the beginning till the end. There is one last thing left that I need to add, which is... "It's Friday Again!".

I would like to thank @ronso0 for his brilliant ideas about the GUI of the Tag Fetcher Dialog, Cover Art Fetcher also for the Track Suggestion Feature. His ideas about UI/UX were really helpful for me to move forward in my PRs. I would like to thank @Swiftb0y for his reviews in "Factory Pattern Design", that was nice to work with him, also I would like to thank him for his ideas about the cover art fetcher. I would like to thank my friend @David Chocholatý who is also a 2022 GSoC Mixxx participant for his coworking and help with the final blog. I would like to also congratulate him on his successful project!

I would like to thank everyone interested and who shared their precious ideas related to the "Track Suggestion Feature" and Its little side projects.

At last, I would like to thank Google for this amazing program and giving us this opportunity .

GSoC 2022 Work Product - Pitch Shift effect and Group Delay handling

2022-09-08T23:45:52+02:00

Disclaimer: The blog post primarily serves as the documentation for the Google Summer of Code 2022 project: "Pitch Shift effect and Group Delay handling". Thus, it contains a lot more detailed description, than the other Mixxx blog posts.

Introduction

The project implements the Pitch Shift effect for the Mixxx DJ Software Application. The Pitch Shift effect raises or lowers the original pitch of an audio signal¹. Thanks to the long working period, the project was expanded with the implementation of the Group Delay handling for the effect chain.

Motivation

Before the effect was implemented, the pitch could be changed using the deck's rate slider separately only. This imposes significant restrictions on the ways other effects can interact with the sound. In this project, the new Pitch Shift effect is introduced in the built-in effects, which can be used in the effect chain. It implements the wish Add a Transpose / Pitch Shift effect for the Mixxx software. The effect has to work with the effect chain API. With that, the other extensional options can be used. Primarily, it allows for a user to use a much wider range, than the Pitch Shifter for the deck player. Due to the produced latency based on the pitch processing, the production delay has to be handled for the Dry/Wet or Dry+Wet mode to ensure that the original (dry) and processed (wet) signals overlap.

Background

List of terms from the field of music, sound processing and development in general:

Pitch
- Pitch is a perceptual property of sounds that allows their ordering on a frequency-related scale. The pitch is the quality that makes it possible to judge sounds as "higher" and "lower" in the sense associated with musical melodies².
Scale
- In music theory, a scale is any set of musical notes ordered by fundamental frequency or pitch. The scale ordered by increasing pitch is an ascending scale, and a scale ordered by decreasing pitch is a descending scale³.
Octave
- In music, an octave is an interval between one musical pitch and another with double its frequency⁴.
Interval
- In music theory, an interval is a difference in pitch between two sounds. In western scales, intervals are most commonly differences between whole tones and semitones⁵.
Semitone
- A semitone is a distance in pitch between a note and the very next note, higher or lower. It is the smallest interval in most western scales⁶.
Chromatic scale
- A chromatic scale is a set of twelve pitches used in tonal music, with notes separated by the interval of a semitone⁷.
Dry and wet signals
- Dry sound signals refer to the raw or unprocessed sounds that usually come from a direct recording. On the other hand, wet sounds refer to the processed sound/signal⁸.
Ring buffer (circular buffer)
- In computer science, a circular buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end. This structure lends itself easily to buffering data streams⁹.
Audio buffer
- An audio buffer holds a fixed size amount of sampled audio data. The audio buffer size determines the time allowed for the computer to process the audio data. Thus, it also determines latency.
Latency
- In the audio world, “latency” is another word for “delay”¹⁰. The latency (time) of an audio system refers to the time difference from the moment a signal is fed into the system, to the moment it appears at the output¹¹. For example, audio latency is when there is a noticeable delay between the sound being played and the moment it reaches the speakers¹⁰. Depending on the application, such a delay can have various effects. Usually, the aim is to achieve the lowest possible latency¹¹.
Sample Rate
- Audio sampling is the process of transforming a musical source into a digital file. Digital audio recording does this by taking samples of the audio source along the soundwaves at regular intervals. The more samples are taken - known as the ‘sample rate’ - the more closely the final digital file will resemble the original. A higher sample rate tends to deliver a better-quality audio reproduction¹².

Implementation

Pitch Shift effect

The Pitch Shift effect main algorithm is implemented in the PitchShiftEffect class. The implementation uses the widely known audio time-stretching and pitch-shifting library RubberBand. The implementation adheres to the “push model”. That means, that the input audio samples are offered to the RubberBand library API directly. Instead of the main Pitch Shifter for each deck player, which has a limited range (only 7 semitones up and down in musical terms, which means not even an octave), the independent Pitch Shift effect offers to work in the range of ± 2 octaves (± 24 semitones). The Pitch Shift effect has the following options:

Pitch knob
Range knob
Semitones mode
Formant preserving

The Pitch knob changes the pitch of a track up or down. For the default middle position, the track pitch is unchanged. The Range knob ensures setting the range of the Pitch knob. The Pitch knob based on the range setting can work from zero range to 2 octaves range. These two knobs work similarly to the real professional Pioneer DJM-900NX2 mixer which is widely used in clubs for live DJ mixing. Then, the Semitones mode toggle was added. This option sets the scale of the Pitch knob. The knob can work in two modes: Continuous or Semitones mode. In the Semitones mode, the pitch is changed based on the chromatic scale in a musical way. Otherwise, the pitch is processed continuously, which is a default approach of the used RubberBand library. By default, the Semitones mode is on. As last, the Formant preserving option was added which uses the RubberBand API namesake option. It preserves the resonant frequencies (formants) of the human vocal tract and other instruments (compensates for “chipmunk” or “growling” voices).

Related files:

Screenshots:

Pitch Shift effect in the Mixxx software

Pitch Shift effect in the effect chain

Group Delay handling

As a project extension, the Group Delay handling of the effect chain was implemented. Based on the Pitch Shift effect processing, using the RubberBand library, the effect produces some amount of latency. Due to that, if we would like to play the original unprocessed signal and the processed one together using the Dry/Wet or Dry+Wet mode, the two audio signals will not overlap because of latency. With that, the common audio processing approach is to delay the original signal by the amount of latency to overlap the signals. Based on the Mixxx effect chain API (EngineEffectChain), the group delay latency handling was implemented for the whole effect chain and works for the total produced latency from the effect chain used effects. The main algorithm of the Group Delay handling for the effect chain is implemented in the EngineEffectsDelay class. The implemented APIs take the group delay with the input signal and return the delayed signal using the inner data structures. For group delay changes, it performs cross-fading to avoid unwanted clicks in the output audio signal. The implemented API was used and built into the implementation of the effect chain. Now, the sum of the latency reported by effects is processed. As was mentioned, lastly, the Group Delay reporting from the effects was implemented using the Mixxx API structures for effects (EngineEffect and EffectProcessor).

Related files:

Based on the implementation of the EngineEffectsDelay, it was soon figured out, that the custom optimized data structure for the Group Delay handling should be created. A common approach for working with the audio signal stream is to use the ring buffer data structure. However, based on the specification of Group Delay handling and requirements on the buffer data structure, the classic widely known implementation is not appropriate for use. So, the new improved and optimized variant of the ring buffer data structure was created specifically for the Group Delay handling use case. The implementation can be found in the RingDelayBuffer class.

Related files:

After the RingDelayBuffer was implemented, the new optimized data structure was introduced in the EngineEffectsDelay for Group Delay handling. With that, the performance has highly improved based on the benchmark results comparison. The benchmarking process and results will be described in detail in the "Testing and benchmarking" chapter later.

Pitch Shift effect improvement

At the latest, it was started the “pull model” implementation for decreasing the Pitch Shift effect latency in the GSoC period. In the new model implementation, the RubberBand API requires the amount of input samples and this amount of samples is passed. The main difference between the usage of these two implementations in the Mixxx software is which tradeoff has to be made. When the “push model” implementation is used, the input data samples have not to be prefilled between the processing but the audio dropouts can occur. On the other hand, the “pull model” implementation with correctly set structure sizes avoids dropouts, but the input data samples have to be prefilled before the processing, and a delay will be produced before the output is produced. To compare the differences in group delay between the “push model” and “pull model” implementation, a measurement was made. The results are captured in the following two graphs.

Based on the first graph, the “pull model” implementation with the size of the circular buffer of 4096 frames produces a lower latency than the “push model” even with the latency produced before the output data. Simultaneously, the delay between dynamic Pitch changes is in a smaller range.

Push and pull model group delay comparison

In the second graph, the group delay for the unchanged pitch was measured. The differences in the measurements are, that the previous pitch values before the unchanged pitch settings are different. With the results of the last measurement, the “pull model” implementation is more stable and produces a similar, almost constant delay after dynamic pitch changes for the same pitch setting.

Push and pull model group delay comparison for unchanged pitch

The results of the measurements clearly show, that despite the “pull model” implementation for the Pitch Shift effect in the effect chain is not optimal, it should be preferred over the “push model” implementation.

Testing and benchmarking

With the implementation of the EngineEffectsDelay for Group Delay handling and the RingDelayBuffer as an optimized data structure for the same use case, the tests were included with the use of the GoogleTest framework. Basically, the common situations were tested, then extreme cases and cases that are not allowed but have to be handled for the release builds. On the basis that these implemented structures are critical from the point of view of performance, with tests, the benchmarks were created with the use of the Google Benchmark. Based on the results of benchmarks, the used functions and algorithms were compared. After both of the mentioned structures were implemented, tested and optimized, the RingDelayBuffer was introduced in the EngineEffectsDelay as an inner structure for the Group Delay handling. Based on the changes and use of optimized data structure the performance has highly improved. The performance differences are shown in the following benchmarks results taken over from the Ubuntu GitHub CI’s results.

Without RingDelayBuffer

Run on (2 X 2593.91 MHz CPU s)
CPU Caches:

L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 1024 KiB (x2)
L3 Unified 36608 KiB (x1)

Benchmark	Time	CPU	Iterations
BM_ZeroDelay/64	260 ns	260 ns	2690728
BM_ZeroDelay/512	2079 ns	2078 ns	336963
BM_ZeroDelay/4096	16616 ns	16614 ns	42139
BM_DelaySmallerThanBufferSize/64	269 ns	269 ns	2600146
BM_DelaySmallerThanBufferSize/512	2119 ns	2119 ns	330263
BM_DelaySmallerThanBufferSize/4096	16978 ns	16977 ns	40822
BM_DelayGreaterThanBufferSize/64	269 ns	269 ns	2597728
BM_DelayGreaterThanBufferSize/512	2125 ns	2125 ns	329431
BM_DelayGreaterThanBufferSize/4096	16979 ns	16978 ns	40976
BM_DelayCrossfading/64	608 ns	608 ns	1151956
BM_DelayCrossfading/512	4865 ns	4865 ns	143875
BM_DelayCrossfading/4096	40081 ns	40079 ns	17621
BM_DelayNoCrossfading/64	539 ns	539 ns	1298494
BM_DelayNoCrossfading/512	4238 ns	4238 ns	165164
BM_DelayNoCrossfading/4096	33939 ns	33936 ns	20622

With RingDelayBuffer

Run on the same system as above.

Benchmark	Time	CPU	Iterations
BM_ZeroDelay/64	14.3 ns	14.3 ns	48804839
BM_ZeroDelay/512	84.7 ns	84.7 ns	8291923
BM_ZeroDelay/4096	510 ns	510 ns	1345199
BM_DelaySmallerThanBufferSize/64	21.7 ns	21.7 ns	32209113
BM_DelaySmallerThanBufferSize/512	108 ns	108 ns	6460461
BM_DelaySmallerThanBufferSize/4096	1627 ns	1627 ns	429938
BM_DelayGreaterThanBufferSize/64	21.9 ns	21.9 ns	31799348
BM_DelayGreaterThanBufferSize/512	108 ns	108 ns	6471893
BM_DelayGreaterThanBufferSize/4096	1625 ns	1624 ns	435414
BM_DelayCrossfading/64	153 ns	153 ns	4596623
BM_DelayCrossfading/512	841 ns	841 ns	832905
BM_DelayCrossfading/4096	9451 ns	9450 ns	73944
BM_DelayNoCrossfading/64	44.1 ns	44.1 ns	15865504
BM_DelayNoCrossfading/512	209 ns	209 ns	3345740
BM_DelayNoCrossfading/4096	3236 ns	3235 ns	215491
BM_WriteReadWholeBufferNoDelay/64	714 ns	715 ns	978487
BM_WriteReadWholeBufferNoDelay/512	796 ns	797 ns	878388
BM_WriteReadWholeBufferNoDelay/4096	1594 ns	1628 ns	429600
BM_WriteReadWholeBufferDelay/64	714 ns	715 ns	978692
BM_WriteReadWholeBufferDelay/512	795 ns	796 ns	878389
BM_WriteReadWholeBufferDelay/4096	1500 ns	1528 ns	457952
BM_MemCpy/64	4.68 ns	4.68 ns	174373476
BM_MemCpy/512	33.0 ns	33.0 ns	21221060
BM_MemCpy/4096	154 ns	154 ns	4535488
BM_StdCpy/64	4.68 ns	4.68 ns	152600697
BM_StdCpy/512	32.1 ns	32.1 ns	21839231
BM_StdCpy/4096	158 ns	158 ns	4418188
BM_SampleUtilCopy/64	4.68 ns	4.68 ns	174349198
BM_SampleUtilCopy/512	33.0 ns	33.0 ns	21194709
BM_SampleUtilCopy/4096	154 ns	154 ns	4515069
BM_Copy2WithGain/64	8.03 ns	8.03 ns	87167131
BM_Copy2WithGain/512	64.2 ns	64.2 ns	10889704
BM_Copy2WithGain/4096	823 ns	823 ns	847146
BM_Copy2WithRampingGain/64	15.6 ns	15.6 ns	44785697
BM_Copy2WithRampingGain/512	116 ns	116 ns	6011618
BM_Copy2WithRampingGain/4096	1113 ns	1113 ns	629003

Demo video

The video with a couple of examples of Pitch Shift effect possible usage

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Challenges

Several problems arose during the coding period. Despite the medium project size, it was needed to spend much more time working on the project based on the issues. I think the biggest challenge in this project was exactly the implementation of the Pitch Shift effect using the RubberBand library. The issue occurred soon, that the effect chain offers the effect to work only with the fixed size audio chunks. Based on that, it is not possible to require an amount of input audio data as needed for the RubberBand library “pull model” implementation. The SoundTouch library for Pitch Shifting was tested too but produced results with worse audio quality and with the same amount of delay. Based on all the discussions, the RubberBand library has shown as the best option for the effect, despite the issues which are associated with it. After that, the Mixxx application did not have implemented the effects delay handler for the effect chain, so, the implementation of this structure was automatically needed. Based on that, the goals of the project were changed. The original proposal contained the Pitch Shift effect, and with that as a project extension to the project requirements of the Mixxx organization, the Auto-tune effect was proposed. After consideration, the Zulip chat survey for other Mixxx developers and users was created to be able to vote for possible project extensions. Based on the survey results, the project extension goal was changed to the implementation and optimization of the Group Delay handling for the effect chain to improve the performance of the Pitch Shift effect for the Dry/Wet and Dry+Wet modes. As the last challenge, I would like to mention the usage of the std::span from the standard library which is supported by C++20. Because the Mixxx organization adheres to its own Minimum requirements policy for the Ubuntu LTS, the mixxx#4810 and the mixxx#4852 pull requests could be merged after the official Ubuntu release was announced in the middle of August due to support of C++20.

Pull requests and issues

mixxx#4775 - PitchShiftEffect: add independent effect

Status: Merged

The PR adds an independent effect to Mixxx's built-in effects. The implementation uses the RubberBand library for changing a pitch of an input track. The effect works in real-time mode and adheres to the “push model” implementation. That means that the input data are offered to the RubberBand instead of that the library requires the amount of input data.

mixxx#4810 - EngineEffectsDelay: effect chain delay handling

Status: Merged

This PR adds the structure for the Group Delay handling of the effect chain. Based on that, some effects can produce latency due to their inner processing. The latency has to be handled for the Dry/Wet and Dry+Wet modes that the dry and wet signals overlapped. The structure for delay reporting from the effects into the effect chain was implemented. With that, the dry signal delaying to overlap with the wet signal was implemented as well. Because it is a critical part of the application engine performance, the tests and benchmarks were included in the development.

In this PR, the std::span was newly introduced into the Mixxx software code with the design proposal and cooperation of my mentor. The util for working with spans was implemented, so other developers can easily work with spans directly from the custom Mixxx data structures. With that, the Mixxx code is being upgraded using the C++20 standard.

mixxx#4848 - Fix EngineDelay and EngineFilterDelay modulo calculation documentation

Status: Merged

Based on the code changes in the EngineEffectsDelay and discussion with my mentor, the explanation commentary was added to two other Mixxx structures working on a quite similar principle.

mixxx#4852 - RingDelayBuffer: ring buffer for delay handling

Status: Merged

During the creation of the EngineEffectsDelay for the Group Delay handling of the effect chain, it was suggested to create an optimized data structure for the inner processing based on the ring buffer. This widely-known signal processing structure was improved and optimized specifically for the use case with handling of delay. Again, tests and benchmarks were created for the RingDelayBuffer and based on benchmarks results the used data copy functions were compared.

vcpkg#48 - [rubberband] add overlaid rubberband v3

Status: Merged

During the coding period, the new RubberBand library release v3.0.0 was announced. Based on the implementation for adding RubberBand v2.0.2 directly into the microsoft / vcpkg repository by the Mixxx organization developer, the RubberBand v3.0.0 was added to the overlaid ports in the Mixxx fork of the original repository.

mixxx#4869 - EngineFilterDelay: clamp wrong delay values

Status: Merged

While working on mixxx#4810, I encountered a bug in the EngineFilterDelay structure: The structure works in a similar way but for a little different use case. Newly the unacceptably huge delay values are clamped in the setter, so, based on the inner calculation the structure will not produce absolutely wrong output. The PR was merged the same day as its creation.

mixxx#4898 - PitchShiftEffect: decrease and report latency

Status: Draft (WIP), last GSoC commit: 146f104

In this draft PR was worked as another project extension. The implemented “push” way model is extended into the “pull” model instead. The new approach decreases the effect latency and this latency is reported in the effect chain delay handler. This PR is still a "Work In Progress". As the last work done the latency measurements were performed for several implementations and for different pitch settings. The measured data was plotted for demonstration. The new implementation was accepted and the PR will be done in the non-GSoC time as a future Mixxx contributor. With the new implementation, the Mixxx circular buffer data structure was improved and optimized for performance. So, it remains to finish the pull implementation by setting the right size of the input ring buffer. Eventually, implement the input ring buffer size depending on the range that was set. As the last thing, the valid delay value propagation for the effect will be finished.

mixxx#4901 - PitchShiftEffect: extend effect options

Status: Merged

The PR extends options of the Pitch Shift effect. The Range knob is added to the setting of the range of the Pitch knob. These two knobs work similarly to the real professional Pioneer DJM-900NX2 mixer which is widely used in clubs for live DJ mixing. With that, the Semitones mode toggle was added for changing the scale of the Pitch knob. By default, this toggle is on, and the Pitch knob works in the Semitones mode. In musical terminology, the pitch is changed based on the semitone chromatic scale. If the toggle is off, the Pitch knob works in the Continuous mode, which is also the default in the RubberBand library. At last, the Formant preserving option was added which works with the namesake RubberBand library option. It preserves the resonant frequencies (formants) of the human vocal tract and other instruments (compensates for “chipmunk” or “growling” voices). With the PR, the new function for the calculation of the Sign function was added to the Mixxx util for math operations.

mixxx#10827 - Improve buffers size function const-correctness

Status: Merged

This PR improves Mixxx’s buffers data structures by using the C++ constant expressions for the size function.

mixxx#10832 - EngineEffect: invalid engine parameters handed over into an effect

Status: Open

During the work on the Pitch Shift effect, it was figured out, that the actual parameter settings are not propagated into the effects. The maximum possible values are used instead and based on that, some newly added effects can work wrong, based on the invalid values for sample rate or size of the buffer, for example.

mixxx#10835 - EngineBufferScaleRubberBand: remove unused include

Status: Merged

The unused include was removed from the implemented Mixxx structure.

mixxx#10840 - EngineEffectsDelay: introduce ring delay buffer

Status: Open (WIP), last (non-failing) GSoC commit: 0c01e34

The implemented optimized ring buffer data structure for delay handling is built into the effect chain handling structure. With the use of the new data structure, the delay handling performance is highly improved based on the benchmark measurements. Unfortunately, the PR was not merged during the coding period due to a failing test for the macOS CI (based on the inner rounding problem for zero value). At the same time, Mixxx's macOS CI started crashing during the configuration stage because of an issue that the workflow runner has changed. For that reason, the bug fix couldn't be tested and the PR was not merged in time. After the bug fix will be able to test on macOS CI and will pass, this PR is ready for merging.

mixxx#10843 - RingDelayBufferTest: refactor includes and span creation

Status: Merged

The tests for the RingDelayBuffer are refactored and the span creations are deduplicated.

mixxx#10858 - PitchShiftEffect: add description comments

Status: Merged

Added the comments for the Pitch Shift effect processing.

website#279 - content/news: add GSoC 2022 Work Product

Status: Merged

Adds a blog post containing the "Work Product" for Google Summer of Code 2022 on the Mixxx website.

Future work

Concretely for the Pitch Shift effect, the effect will be improved using the “pull model” implementation after the end of the GSoC period. With that, the Dry/Wet and Dry+Wet modes will be done for the effect too. As the next project extensions, based on the survey, the following options or features can be added to the Pitch Shift effect implementation:

Auto-tune effect
A piano keyboard interface
Optimize interface for common controllers
CPU load balancing
Consider interaction with the main Pitch Shifter
Expose compensation delay as additional parameter for making funny things without extra CPU cycles

More widely, as the future work for the Mixxx software, the wider support for the LV2 standard for effects can be implemented or better, the Carla audio plugin host can be introduced in the Mixxx application. It will allow users to use their favorite effects enabled via audio plugin standards such as LADSPA, DSSI, LV2, VST2, VST3 and so on, in the application instead of offering only the built-in effects or poor API for the LV2 standard. After consultation with my mentor, we agreed, that I can take on this task as a regular Mixxx contributor after the end of GSoC.

Things I learned from GSoC

I don't think I can even express how much the GSoC experience has given me. Even though I had the experience with open source in one small project, the workflow and development for the greater organization as Mixxx was completely different and gives me a lot. I have learned so many cool things about audio processing, development in C++ with the best practices, using the new C++20 standard, testing and benchmarking with the use of Google frameworks, and improving my knowledge with git and approaches to open source development in general. Thanks to the change in the proposed project extension, I learned a lot about real-time audio signal processing and about cool data structures. I had a chance to try to design the data structure with extensions too. I am really glad about the plan change now. I really improved my English, both, written and spoken. I think, that it was the best experience so far for me as a developer I ever had. It is awesome, that I can publish my work and have immediately the feedback and proposed improvements. With that, I liked the open source development to just how much I can learn from the awesome people and create new cool stuff. Despite I’m a college student, this actually missed me a lot, to just have feedback on my work which opens me the opportunities to learn. I really felt that I’m a part of the community. I will be happy to continue being part of the Mixxx organization and contributing to open source.

Conclusion

The wished new effect was implemented, and the issue which requested this new feature was closed with the "Fix Committed" status. All requirements by the Mixxx organization in their project idea, on which the project proposal was based, were met. Thanks to enough time in the GSoC Coding period was worked on the project extensions. Based on the situation and the importance of new Mixxx features, the originally proposed extension was replanned and changed. The new Group Delay handling structure was successfully implemented and optimized with the implementation of the extended data structure. In the GSoC Coding period, work was started to minimize the effects latency as well as to polish the effect even more. Unfortunately, that work could not be finished before the GSoC deadline.

During the coding period, I lined up among the top Mixxx contributors for the last month, with 61 commits authored, and I became the 27th of 238 contributors for the Mixxx software, with 119 commits in total.

August 2022 contributors - mixxxdj/mixxx

Contributor summary - mixxxdj/mixxx

Acknowledgements

First, I would like to many thank my mentor @Swiftb0y for his guidance, help, reviews, and a lot of new information and lessons he gave me during the summer. I'm just motivated and learned a lot. I would like to thank the Mixxx organization developer @Daniel Schürmann for his help, reviews and active contributions with new ideas and improvements to my project and pull requests. Thank you both for involving me in the Mixxx development process and for constructive criticism which offers me learn many new things in the past weeks. I would like to thank my summer colleague for the Mixxx organization and friend @Fatih Emre for his help and synergy on the final blog post structure and chapters. Of course, I would like to thank all Mixxx developers for welcoming me into the Mixxx family and for their help. I would like to continue our cooperation after GSoC end as Mixxx developers. I look forward to our future teamwork. Many thanks to the Google Summer of Code team they made this amazing experience possible for me.

Resources

Wikipedia, Pitch shift, Modified: 6 June 2022, Accessed 2 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Pitch_shift ↩
Wikipedia, Pitch (music), Modified: 6 Sept. 2022, Accessed: 7 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Pitch_(music) ↩
Wikipedia, Scale (music), Modified: 13 July 2022, Accessed 1 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Scale_(music) ↩
Wikipedia, Octave, Modified: 18 June 2022, Accessed 1 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Octave ↩
Wikipedia, Interval (music), Modified: 6 Sept. 2022, Accessed: 7 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Interval_(music) ↩
Dan Farrant, A Guide To Semitones & Tones (Half & Whole Steps), Modified: 25 June 2022, Accessed: 2 Sept. 2022, Retrieved from: https://hellomusictheory.com/learn/semitones-tones/ ↩
Wikipedia, Chromatic scale, Modified: 15 March 2022, Accessed: 1 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Chromatic_scale ↩
Celine, Difference Between Wet and Dry Signals or Sounds, Modified: 22 Feb. 2012, Accessed: 3 Sept. 2022, Retrieved from: http://www.differencebetween.net/technology/difference-between-wet-and-dry-signals-or-sounds/ ↩
Wikipedia, Circular buffer, Modified: 29 Oct. 2018, Accessed: 2 Sept. 2022, Retrieved from: https://en.wikipedia.org/wiki/Circular_buffer ↩
Audio Modeling, Grow Your Knowledge, Accessed: 3 Sept. 2022, Retrieved from: https://kb.audiomodeling.com/en/c/grow-your-knowledge/d/what-is-audio-latency-how-do-i-fix-latency-issues-while-recording/ ↩↩
NTi Audio, Latency in Audio Systems, Modified: 10 March 2021, Accessed: 7 Sept. 2022, Retrieved from: https://www.nti-audio.com/en/news/latency-in-audio-systems ↩↩
Adobe, Sample rates and audio sampling: a guide for beginners, Accessed: 8 Sept. 2022, Retrieved from: https://www.adobe.com/uk/creativecloud/video/discover/audio-sampling.html ↩

Migrated to GitHub Issues

2022-08-24T15:19:17+02:00

Yes everybody, we officially moved our bug tracking away from Launchpad to GitHub. If you've never tried to report a bug in Mixxx or wanted to contribute in other ways, it's very likely you have no idea what this post is about, but if you do it's even better. No matter if you do or don't, keep reading.

The Mixxx team has traditionally been using Canonical's (the makers of Ubuntu) Launchpad platform for hosting their code, managing bug reports and releases. Over the years, Launchpad has become increasingly dated, lack of modern features, old UI, and bad user experience is the primary reason why many people (myself included), stay away from Launchpad. Especially for new contributors the mandatory Ubuntu One account was another reason for not to immediately report a bug when they encountered it.

We've started transitioning away from Launchpad quite a while ago:
Back in 2013 we have transitioned from the Bazaar version control system to Git and moved our main branch to GitHub. At that point in time, GitHub issues where not yet suitable for managing our bugfix and release workflow, thus bug reports continued to be handled on Launchpad. This has progressively changed over the past couple of years, now GitHub has a "duplicate issue" detection feature, can organize bugs in projects and the labeling feature is flexible enough to fulfill most of our needs.

Going forward, Launchpad will only be used for publishing to our Ubuntu PPA. Hence no contributor outside of the core team will have to bother with Launchpad again.

Shortly before starting the migration, we made our Launchpad bug tracker read-only (some of you might have noticed that and/or have seen our heads-up post). The migration took about 50 Hours. All of the existing messages were copied to GitHub including links to any attachments and patches uploaded as part of message. We also carry over the state of a bug by mapping them to Github issue Labels:

Launchpad	GitHub
Confirmed	`confirmed`
Fix Committed	close issue
Fix Released	close issue
Incomplete	`incomplete`
In Progress	no label
Invalid	`invalid`
New	no label
Triaged	`confirmed`
Won't Fix	`wontfix`
Critical	`party stopper`, `bug`
High	`bug`
Low	`bug`
Medium	`bug`
Undecided	no label
Wishlist	`feature`

Since Mixxx is a project exclusively maintained by volunteers where each volunteer is free to work on whatever they choose anyways, we decided to drop the different priority levels assigned to issues.

I want to express a special thanks to our core team member @Holzhaus for writing a custom import script which made this migration feasible in the first place.

Due to the big number of bugs and the flood of related notifications, I have noticed quickly that the script will likely hit various rate limits and spam protection facilities.
After getting in contact with GitHub via Twitter they assembled a team of engineers and FOSS experts to help us evaluate possible solutions. Thanks to them, we were able to avoid email spam and reduce the time the import took by two orders of magnitude.

What does this mean for existing contributors?

From today on, no more bug reports should be filed on Launchpad. Currently ongoing discussions should be continued on GitHub instead. Note that any comments made after 2022-08-22 12:00 UTC have not been migrated to GitHub. Existing bug reporters need to create a GitHub account if they haven't already.

Thank you everyone for your patience.

Bug Tracker Temporarily Unavailable

2022-08-19T07:24:03+02:00

Hello Everybody.

After thorough preparation, we're finally moving from Launchpad bugs to GitHub issues. We'll publish a more detailed blogpost after the migration is done. For now, We'd just like to let everybody know, that we will disable our bug tracker on launchpad sometime on Monday the 22nd of August. Any activity on Launchpad after that point will not be carried over to GitHub. Any already existing link to an issue on Launchpad will still continue to work, but you will not be able to search for them on Launchpad anymore. Once the migration has been completed, the more detailed blog post will be published and you will be able to interact with the newly migrated issues on our GitHub repository.

Thank you all for your patience during the migration.

Mixxx 2.3.3 released

2022-06-22T00:04:51+02:00

Its that time again!
Almost a year after the release of 2.3.0 we're bringing you the next bugfix release Mixxx 2.3.3.

This release features - you guessed it - various bugfixes and improvements: But since we're not your run-off-the-mill mobile app, we'll get a bit into detail:

A bunch of controller mappings have received various improvements, such as the Pioneer DDJ-SB3, the NI Traktor S3, Behringer DDM4000 and Denon MC7000. We've also addressed some long-standing bugs in our controller engine and the Auto DJ, smoothed out the preference dialog and fixed a bunch of possibly show-stopping bugs. 😬 😌

As usual, we recommend you update to the newest stable version by visiting our download page

If you are interested in the detailed CHANGELOG, here you go 😉:

Changelog

Pioneer DDJ-SB3: Fix controller breaking when releasing the shift button #4659
Traktor S3: Push two deck switches to explicitly clone decks #4665 #4671 lp:1960680
Behringer DDM4000: Improve stability and add soft-takeover for encoder knobs #4318 #4799
Denon MC7000: Fix 'inverted shift' bug in the controller mapping #4755
Fix spinback and break effect in the controller engine #4708
Fix scratch on first wheel touch #4761 lp:1800343
Preferences: Prevent controller settings being treated as changed even though they were not #4721 lp:1920844
Fix rare crash when closing the progress dialog #4695
Prevent preferences dialog from going out of screen #4613
Fix undesired jump-cuts in Auto DJ #4693 lp:1948975 lp:1893197
Fix bug that caused Auto DJ to stop playback after some time #4698 lp:1893197 lp:1961970
Do not reset crossfader when Auto DJ is deactivated #4714 lp:1965298
Change the minimum Auto DJ transition time to -99 #4768 lp:1975552
Samplers, crates, playlists: fix storing import/export paths #4699 lp:1964508
Library: keep hidden tracks in history #4725
Broadcasting: allow multiple connections to same mount if only one is enabled #4750 lp:1972813
Fix a rare mouse vanish bug when controlling knobs #4744 lp:1130794 lp:1969278
Restore keylock from configuration and fix pitch ratio rounding issue #4756 lp:1943180
Improve CSV export of playlists and crates and fix empty rating column #4762
Fix passthrough-related crash in waveform code #4789 #4791 lp:1959489 lp:1977662
Passthrough: stop rendering waveforms and disable Cue/Play indicators 4793

Projects Announced for GSoC 2022

2022-05-21T16:51:39+02:00

Google has accepted two contributor's projects for Mixxx as part of their Google Summer of Code (GSoC). GSoC is a stipend program that allows new contributors to work Mixxx on their own ~175 hours or ~350 hours project.

This year Fatih Emre YILDIZ and David Chocholatý have been successful with their applications. Congratulations!

David Chocholatý will implement a pitch shift and auto-tune effect, that will allow you to get creative with loops and samples for example by altering the pitch or even play melodies.

Fatih Emre YILDIZ will add a track suggestion feature that fetches track suggestions from online sources. This information can then be used to make the random track selection in Auto Dj more reasonable or help the DJ to keep the crowd dancing even if he is out of ideas for a follow-up track.

We will discuss the project details in our public Zulip so that anyone can follow their progress.

Russia's invasion of Ukraine

2022-03-29T23:18:45+02:00

On 2022-02-24 we received horrible news from Ukraine, which has become even worse since then. As an organization committed to freedom we feel the urge speak up and show solidarity with Ukraine.

Russia's invasion of Ukraine is unjustified and has already been condemned by the UN as a violation of international law. The attack creates endless suffering not only for the men, women and children of Ukraine but also for the many Russian soldiers who are sent into a senseless war that they do not want, do not understand and are not even allowed to call as such.

Mixxx and the FOSS movement respect user freedom and stand for freedom in other ways as well, including freedom of speech and worldwide peaceful cooperation. As an expression of solidarity, we propose to include tracks by Ukrainian artists, Russian activists or anti-war tracks in general in our DJ sets. Although we are not able to stop this war, and we are not under the illusion that music alone will put an end to the suffering, however we think it is important to make our voices heard and support the various local or international efforts to help Ukrainians as much as we can.

Here for instance three suitable tracks:

In case you cannot access them, please contact us on Zulip

Mixxx accepted for GSoC 2022!

2022-03-18T12:26:02+01:00

Mixxx has been accepted as a mentoring organization for Google Summer of Code 2022, a global program focused on bringing new contributors into open source software development.

This year the program is open for all new or beginner contributors of Mixxx. It is no longer limited to enrolled students. New contributors have the opportunity to work on Mixxx full-time as a 12+ weeks programming project and receive a stipend sponsored by Google. For more information, check out the Google Summer of Code Contributor Guide.

You will find the GSoC 2022 Project Ideas for Mixxx in our wiki, but we're also interested in project ideas that matter more to you. Taking a look at our GSoC advice page is recommended if you're planning to apply. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our codebase.

The official application period will start April 4th and ends on April 19th, so have your applications ready in time. Potential GSoC contributors should start now to discuss application ideas on our Zulip. Just start a new topic in the #gsoc stream.

Mixxx 2.3.2 released

2022-01-31T22:18:57+01:00

New year, new Mixxx - we're starting 2022 with the release of Mixxx 2.3.2! Grab it from our download page and install it on Windows, macOS and Linux.

This release irons out a few bugs and adds support for the Pioneer DDJ-SB3 controller. The full changelog can be found below. In case you're a Linux package maintainer please double check the Packaging section in the changelog and modify your packaging script if necessary.

Changelog

Playlist: Enable sorting by color #4352 lp:1945976
Fix crash when using Doubling/Halving/etc. BPM from track's Properties window on tracks without BPM #4587 lp:1955853
Fix writing metadata on Windows for files that have never been played #4586 lp:1955331
Preserve file creation time when writing metadata on Windows #4586 lp1955314
Fix handling of file extension when importing and exporting sampler settings #4539
Fix crash when using an empty directory as resource path using the --resource-path command line option #4575 lp:1934560
Pioneer DDJ-SB3: Add controller mapping #3821
Don't wipe sound config during startup if configured devices are unavailable #4544
Append selected file extension when exporting to playlist files #4531 lp:1889352
Fix crash when using midi.sendShortMsg and platform vnc #4635 lp:1956144
Traktor S3: Fix timedelta calculation bugs #4646 lp:1958925

Packaging

Downloads of external dependencies are placed in build/downloads
The sources for libkeyfinder are now expected in build/downloads/libkeyfinder-2.2.6.zip instead of build/download/libkeyfinder/v2.2.6.zip
CMake: Adjust the download directory and name of external dependencies #4511
Fix/Improve Appstream metainfo #4344 #4346 #4349

How Does Timecode Vinyl Actually Work? (Pt. 2)

2021-12-22T23:00:18+01:00

In the last post, I explained how a basic relative-mode Digital Vinyl System (DVS) works. But there are two problems that are still left to solve:

Seeking inside a track by picking up the needle from the record and dropping it somewhere else will not work.
The basic relative-mode implementation will likely suffer from so-called sticker drift. This means that if you put a sticker on the vinyl record as visual aid and then scratch the record back and forth so that the sticker is in the same position it had before the scratch, the track should also be at the same position. If you just use the pitch information, it will likely be too inaccurate to make this work, and track position and sticker position drift apart (hence the name).

Both of these problems can be solved by throwing position information into the mix. This is why the timecode signal also contains information that can be used to detect the needle position on the record.

Getting the position out of the analog signal

From a steady sine waveform alone, it is hard to determine in which groove the needle is and at which rotation degree the platter is moving. One can imagine to count cycles of the wave from the beginning of the control track. Unfortunately this is error prone due to crackling or a skipped groove. The counted number becomes void after such an event. To restore the counted number, a periodical position information is required. For Serato timecode, this information is added to the sine wave by amplitude modulation (AM) representing the position as a series of low and high amplitudes, digital bits, where 1 is a relatively high peak, and 0 is a relatively low peak.

The right channel is just a phase-shifted version of the left one, so we only need to look at the positive peaks of the left channel.

If we look closely, we notice that the peaks occur every time the right channel crosses zero and the signal value goes from the positive part of the signal to negative part.

This is very convenient, because that way we don't have to lose any sleep over how to detect the peaks in the left channel, we just detect if there was a positive-to-negative zero crossing in the right channel, then take the current value of the left one and check if it's a 0 or 1 by comparing it with a threshold.

Now it's clear how the analog timecode signal can be converted to a stream of bits. But how can these bits be interpreted as positions? Or rather: How did the engineers that created the timecode format encode the positions as bits?

Encoding strategies

Simple Base-2 Encoding

The intuitive approach is to encode positions as a sequence of ascending numbers, e.g. the first position is 0, the second position is 1, the third position is 2, etc. Since we're working with bits, we could simply express these decimal numbers in the base-2 (binary) numeral system, like this:

Position	Bit Sequence
0	`000`
1	`001`
2	`010`
3	`011`
4	`100`
5	`101`
6	`110`
7	`111`

Of course, that is just a toy example, but even if we only had 8 different positions, we need use 3 bits (= 3 cycles) to represent each position. In reality, we want to encode a lot more different positions, which means the resulting binary number will be longer, meaning we need more bits and therefore cycles per position we want to encode.

The corresponding signal would look like this:

The first 3 cycles encode position 0, the next 3 cycles encode position 1, and so on. Simple, right? Unfortunately, this approach has a major problem.

Let's assume you seek to a random position in the track (by picking up the needle and dropping it somewhere) and the next 3 bits are 001. Do you know what position or cycle number we are at?

We can look up 001 in the table above and see that these bits encode position 1 (cycles 3-6). So after reading these bits we should be at cycle 6. And that is one possibility, but not the only one.

So there are multiple possible positions and we don't know which one is the correct one. We can mitigate this by reading the next 3 cycles too, but this doubles the amount of cycles we have to read (6 instead of 3 cycles) until we know the position for sure.

Digital Vinyl Systems need to be responsive and minimize the latency (i.e. the delay between moving the vinyl and seeing/hearing the action in the software) to be usable for scratching. Therefore, this approach is not sufficient.

The problem with the simple base-2 encoding is that may end up in the middle of a number and we don't know where a number begins or ends.

Using Sentinel Values

To detect the beginning of a new position mark reliably, we need something special, that can be clearly distinguished from the position values. Such a value is called a sentinel value and could be used to indicate "A new position value starts here".

After a seek, we have to keep reading bits until we encounter the sentinel value, then we can start reading the actual position bits. In fact, that's exactly what the early Final Scratch DVS did.

In the Final Scratch timecode, each position was prefixed by 0001, followed by 16 bit of position information. Although using a sentinel value ensures that we know when a position starts, this approach is also problematic. Let me explain why.

As we already stated, we want the latency between moving the needle and detecting the position to be as small as possible. Among other things, the latency is determined by how many bits we have to read until we know the position, so we want this to be as small as possible in all cases. And this is where using sentinel values fail.

Let's assume the DJ dropped the needle directly in front of a sentinel value:

 0 0 0 1 [-------16 bit position-------] 0 0 0 1 [-------16 bit position-------] 0 0 0 1 ...
^                                       ^
Needle dropped here          At this point we know the position

After reading the next 20 bits (4 bit sentinel value + 16 bit position value), we know the position. That's fine, but it's only the best case.

What if the DJ dropped the needle after the first bit of the sentinel value? That would be the worst case and we'd need to read a lot more bits before know the position:

 0 0 1 [-------16 bit position-------] 0 0 0 1 [-------16 bit position-------] 0 0 0 1 ...
^                                                                             ^
Needle dropped here                                            At this point we know the position

The DVS can't detect that the needle was dropped on the sentinel value (because the first bit is missing). Therefore, it need to wait for the next one and just ignore the remaining 3 bits of the sentinel value and the subsequent position value. Then it can detect the next sentinel value and position.

So in that case it would be necessary to read 39 bits before the position can be known. Needing so many bits to reliably detect a position is bad for latency and might make the system feel "sluggish".

Using an LFSR

It would be great if we could reduce the number of bits that we need to read to detect the position reliably - even in the worst case. In the DJ community, Serato's take on DVS is widely considered one of the best solutions. What are they using for position detection? We can get a basic idea by taking a look at the back of the Serato Control Vinyl (CV2):

Deep in a New Zealand laboratory, the founders of Serato set out to create a control record to give professional DJs superior control. Standard timecode records just didn't feel enough like vinyl to make the cut. After months of nerdy, mathematical investigation, they created a maximal-length pseudo random bit sequence using a linear feedback shift register. Or, in English, the Serato NoiseMap™ - a unique control tone for digital DJs that offers unparalleled sensitivity and tightest, most authentic vinyl feel.

So Serato is using a Linear Feedback Shift Register (LFSR) its control signal. Sounds scary? Don't worry, it's not as complicated as it may sound.

What is an LFSR and how does it work?

A Linear Feedback Shift Register (LFSR) is a shift register that uses a linear feedback function. LFSRs are common in modern computing (e.g. for generating pseudo-random numbers), but using them for a vinyl control signal an interesting and unusual application. I'll outline the basic principle and then try to explain step-by-step using an example.

For our purposes, it suffices to know that a register is an array that contains a fixed number of bits. We are working with a Shift Register, which means means that the contents of the register are shifted to the left or right in each step.

If we shift the register's contents to the right, we need a new value that we insert at the leftmost position. LFSRs use a (linear) function that takes the current content of the register as input. The resulting value is then fed back into the register.

Let's have a look at a step-by-step example. Here's a 3-bit LFSR that generates a maximal-length pseudo random bit sequence:

In each step the following happens:

We take the current contents of the register to calculate the feedback bit. In this case, we calculate x = s₁ + s₀.
Then shift the register to the right.
The bit that is "pushed out" of the register (i.e. the rightmost bit s₀) is the output bit
The leftmost (empty) space is filled with the feedback bit (x) we calculated.

Let's assume that the initial state of the register is (1, 0, 0).

First, we need to calculate the feedback bit x which is defined as the sum of s₁ and s₀. In this step, both bits have the value 0, so x = s₁ + s₀ = 0 + 0 = 0 Next, we need to shift everything to the right, and insert x = 0 on the left. The output bit is 0, because that is the rightmost bit that is "pushed out" of the register.

In the next step, the feedback bit is x = s₁ + s₀ = 1 + 0 = 1. Note that this time s₁ has the value 1 because we shifted the register to the right in the previous step and 1 moved from s₂ to s₁. Now that we calculated x, we again shift the whole register to the right and write the feedback bit into the leftmost position. The output bit is 0.

We can now continue this a few more times. In step 5, the feedback bit is x = s₁ + s₁ = 1 + 1. Usually, the result of that calculation would be 2, but in this case it's 0. The reason for that is that we're working with bits (which are either 0 or 1), so 2 is not a valid value.

Consider a 24-hours clock: If it's 23:00 and you wait 2 hours, it's 01:00 and not 25:00. That time doesn't exist, so you just subtract 24, which is the number of possible hours from 0 to 23, to make it valid (25:00 - 24:00 = 01:00). In the same way 2 becomes 0, when you calculate 2 - 2 = 0, because 2 is not a valid bit value.

After the first 6 steps we get the following table:

Step	s₂	s₁	s₀	Feedback bit x = s₁ + s₀	Output bit x = s₀
1.	1	0	0	0 + 0 = 0	0
2.	0	1	0	1 + 0 = 1	0
3.	1	0	1	0 + 1 = 1	1
4.	1	1	0	1 + 0 = 1	0
5.	0	1	1	1 + 1 = 0 (mod 2)	1
6.	0	0	1	0 + 1 = 1	1

In the next step, we would insert the feedback bit (1) at the leftmost position and shift the other bits to the right, which results in the state (1, 0, 0), which is exactly the state we started with. From now on, the table rows would just repeat forever.

This means that this LFSR has a period of 7 (because it repeats after 7 steps). That is the maximal period length you can archieve with a 3-bit LFSR.

Other 3-bit LFSRs that have a shorter period length exist, e.g. if you have an LFSR where the feedback bit is calculated as x = s₀ it will already repeats after 3 steps, no 3-bit LFSR will have a longer period.

Hence, we now know how to generate a "maximal-length pseudo random bit sequence using a linear feedback shift register" just like Serato has. Let's check how that can be used to solve the problem at hand.

LFSR output as timecode signal

In each step of the LFSR example above, we get exactly one output bit (the rightmost bit of the LFSR that is "pushed out"). The example has six steps, thus we also get 6 output bits:

0 0 1 0 1 1

Since the LFSR has an internal state of 3 bits, we can use 3 subsequent bits for encoding positions, like this:

Position	Bit Sequence
0	`001___`
1	`_010__`
2	`__101_`
3	`___011`

The corresponding timecode signal would look like this:

We can now observe an interesting property of our 3-bit-LFSR-based output signal: Any sequence of 3 bits in the signal is unique.

This is great and exactly what we want, because after reading 3 bits we now know unambiguously which one of the 4 positions we're at.

How big does the LFSR need to be?

The example above is obviously a toy example. In real life, we want to a lot more than 4 different positions.

The Serato Control CD has a play time of approximately 16 minutes 20 seconds, or 16 * 60 + 20 = 980 seconds. At a timecode frequency of 1000 Hz (cycles per second), we have 980,000 cycles. Every cycle encodes one bit, therefore we need an LFSR with an output length of at least 980,000 bits before it starts to repeat.

At most, an n-bit LFSR can output 2ⁿ - 1 bits before it starts to repeat. An LFSR with such a period size is called a maximal-length LFSR, and we already mentioned that Serato states that it uses a such an LFSR on the packaging of its timecode media.

The smallest possible LFSR that can output at least 980,000 bits without starting to repeat needs at least 20 bits of state. A 19-bit LFSR is too small, because 2¹⁹ - 1 = 524,287 is less than 980,000, but a 20-bit LFSR can output up to 1048575 bits before it starts to repeat. We don't want to make the LFSR larger than absolutely necessary, because the larger the register, the more bits we need to read before we can detect a position after a needle drop. Hence, increasing the LFSR's size also increases the latency.

A Real Life Example

Let's have a look at a real-life DVS that relies on an LFSR for position detection. We already know that Serato's timecodes uses an LFSR, but what does it look like exactly?

Fortunately, we can find out by using the Berlekamp-Massey algorithm. It takes the bit sequence decoded from Serato's timecode, and finds the shortest LFSR that produces that output.

For the Serato Timecode CD bit sequence, the algorithm finds the following LFSR:

We also have to find the correct seed (initial bit state for the LFSR), but this is trivial:

We know the first 20 bits of the timecode (e.g. by simply looking at the waveform) and we also know that this bit sequence is unique. First, we select a random non-zero bit sequence as initial LFSR state and then step through the LFSR states while comparing the output of the LFSR with these first 20 bits of timecode bit sequence. As soon as we see these 20 bits, we just go back 20 steps to the LFSR state before the first bit of that sequence appeared in the output. This is the seed.

A DVS could now generate a lookup table (LUT) that maps each LFSR state to a position. When reading bits from the timecode, it can then perform a simple lookup to get the corresponding position.

Increasing the signal frequency

Another way to reduce the latency is to increase the signal frequency. Serato uses a signal frequency of 1000 Hz, Final Scratch uses 1200 Hz and Traktor Scratch MK2 even uses 2000 Hz. This means that if you play the record at its original tempo, Serato will read 1000 bits in a single second, Final Scratch will read 1200 bits and Traktor Scratch MK2 can read 2000 bits. Sound like a good way to reduce the latency, right?

Unfortunately, a higher signal frequency also comes with a cost: The signal's maximum frequency must not exceed half the sampling frequency, otherwise signal folding will occur and lead to information loss. If you use an audio interface with a 44100 Hz sampling frequency (or sample rate), the signal's maximum frequency at which is can be sampled losslessly (called Nyquist frequency) is 22050 Hz.

When DJs scratch using DVS, the record is being moved back and forth very fast, so it's not played back at the original speed. If they move it too fast, signal folding will lead to misdetection of the bits. With Serato, you can speed up the record up to 22.05 times of the original speed before that happens. Traktor MK2 only allows a scratching speed of 11.025 times before the Nyquist frequency is reached and signal folding occurs.

Hence, the signal frequency is a tradeoff between latency (how many bits per second) and maximum possible scratching speed.

Conclusion

I hope these two blog posts were interesting and helped understanding how DVS works internally. Of course, this was just a basic introduction, and there's still more to consider, like dealing with noise, dusty vinyl, etc. And the information read from the timecode vinyl still has to be hooked up to the GUI and audio engine of the DJ software, which is challenging on it's own.

If you want to see an actual DVS implementation, check out Mark Hills' excellent free and open-source xwax software. Its timecode decoder is what Mixxx uses internally to provide vinyl control.

You can also have a look at vinylla, a toy library that I started to get a better understanding of DVS (and also to learn how to program in Rust).

And if you want to help improve the way Mixxx' DVS capabilities or want work on other parts of Mixxx, hit us up on Zulip Chat!

How Does Timecode Vinyl Actually Work? (Pt. 1)

2021-11-21T00:09:09+01:00

Since the dawn of DJing, spinning vinyl records has never really gone out of fashion. Even when CDs became popular in 90s and most music listeners happily phased out their record players, the classical "two turntables and a mixer" setup stayed the epitome of DJing. In recent years, digital DJ controllers became more popular, but there are still many DJs that stick with their notorious Technics SL-1210s turntables.

There's a reason for that: the tactile feeling of manipulating music with your hands is something that controllers have had trouble archieving. Motorized controllers like the Rane One try to provide a similar workflow, but it's still to be seen whether they will be able to take significant market share and replace vinyl setups or if they stay a niche product.

On the other hand, going digital has its benefits: In contrast to the 80s, nowadays many tracks are only released digitally, and a pure vinyl setup makes it impossible to play them. Jumping to different positions instantly inside a track using hotcues - without picking up, moving and dropping the needle - just isn't possible with vinyl records, and carrying around heavy crates of records isn't the best you can do for your back either.

Digital Vinyl Systems (DVS) aim to provide the best of both worlds by combining the flexibility and power of digital DJing with the tactile control of traditional vinyl DJing. But how does it actually work?

The Basics

Instead of a traditional record that contains music, a "control" record is used. Such a record contains a special signal that is processed by the computer. The computer transforms this signal into information about direction ("Is the record playing forwards or backwards?"), pitch ("How fast is the record spinning?") and position information ("At which position of the record is the needle?") and uses it to manipulate the playing track in software.

There are many formats out there: VirtualDJ, Rekordbox, Numark, MixVibes, Traktor and Serato all provide their own solution. Mixxx (and the underlying xwax library) support the latter 3 formats.

Serato is one of the most popular and robust digital vinyl systems. The Serato Control CD can be used to achieve the same thing on CDJs instead of turntables. Since the latter essentially works the same as the vinyl version and can be downloaded for free from the Serato Website, I'm going to explain how it works based on that format.

Let's take a look at the control signal (also called "timecode signal"). If you open the WAV file with an audio editor like Audacity, it looks like this:

As you can see, the timecode signal is a stereo signal. The left channel is on top and the right channel is on the bottom. Both channels look very similar, but the right channel is shifted a little.

Detecting the Playback Velocity

Let's focus on the left channel for now. The wave basically looks similar to a sine wave that you may remember from your high school math classes. You can divide that signal into "cycles", where each cycle starts from zero and goes into a positive part (above the black line) followed by a negative part (below the black line) and then repeats:

Each cycle has the same length and if we count the number of cycles in a single second of audio, there are 1000 of them. Hence, we now know that the signal has a frequency of 1000 Hz (Hz = 1/s, so it's basically a fancy way saying "per second").

With that information, the DVS system can detect how fast the record is playing by checking how many cycles there are in a second of audio recorded from the turntable. If there are 2000 cycles per second, it's playing a double speed, at 500 cycles per second the record is playing at half speed, and so on.

But how does the computer know how many cycles there are in a second? We can't actually wait for a second, because the delay (also called latency) would be very noticeable and make the system unsuitable for scratching.

Analog vs. Digital Audio

It's important to know that in contrast to analog audio like vinyl or music cassettes, the computer doesn't actually work with the continuous (smooth) wave that we see in the screenshot.

Instead, digital signals work with measurements (called "samples") that indicate the value of the wave position at specific points in time. How often these measurements are taken is determined by the sample rate (or sampling rate). For example, Audio CDs use a sample rate of 44100 Hz (i.e. 44100 measurements per second, or 1 measurement every ~22.68 microseconds). Such a signal is called "time-discrete":

The reason for this is that a time-continuous signal has infinite resolution and would need infinite memory space to save, which is impossible - and also unnecessary, because as long as you take enough samples per second, you can restore the original signal without any loss of information.

Since computers can't store numbers with a theoretically infinite number of different values, a digital signal is also value-discrete. This means that the amplitude values are mapped to a finite number of different values.

Let's assume we only have space to store 11 distinct values per sample (-1.0, -0.8, -0.6, -0.4, -0.2, 0, 0.2, 0.4, 0.6, 0.8 and 1.0). But a sample value may have any value, so if its value would be between two of these values, they have to be rounded (in this case: multiples of 0.2). This process is called Quantization and causes some information loss, which means that it adds noise to our signal. An example for such a quantized, value-discrete version of the analog signal looks like this:

A more realistic example is the Audio CD, which uses 16 bit per sample value. With 16 bits, you can represent 2¹⁶ = 65536 different values.

A digital signal is both time-discrete and value-discrete:

Note that this is just a very basic introduction in how digital signals are represented. If you're interested in the topic, I recommend watching Monty Montgomery's "Digital Show & Tell" video, where he demonstrates how digital signals behave in contrast to analog ones and clears up common misconceptions.

You may wonder why the timecode signal in the screenshots looks like a analog signal instead of a "lollypop chart". Digital vinyl scratch system work with digital signals, not analog ones, right? And you'd be right, it's just that most audio tools (like Audacity) show a wave instead of individual samples by default.

Detecting Zero Crossings

Now that we know the basics of digital audio, we can start thinking about a simple low-latency approach to detect the playback velocity using so-called "zero crossings".

Whenever the wave goes from the positive part to the negative part or vice-versa, it crosses "zero". For example, in the timecode signal screenshot I used above, we can see 3 zero crossings:

Note that we're working with a digital signal. To illustrate that this signal is time-discrete, each individual sample value is illustrated by a little dot.

To detect these zero crossings reliably, we can't just check if the sample value equals zero, because we cannot assume that a sample measurement is happening at the exact time that the signal is at zero position.

It might be the case the current sample is after the zero position and the previous sample was before the zero position. Hence, we also compare the previous sample value with the current sample value. If the current value is positive and the previous value was negative, or if the previous value was negative and the current value is positive, the signal crossed zero.

Refining Pitch Detection Using Zero Crossings

Now that we know how to detect zero crossings, we can use them for determining the pitch.

If we look at the timecode signal, we can see that each cycle of the timecode signal has two zero crossings: At the start of the cycle, when the positive part of the wave starts and in the middle of the cycle when the negative part of the wave starts.

So the equivalent of checking for 1000 cycles per second is to check if there are 2000 zero crossings per second. Let's say the audio interface uses a sample rate of 44100 Hz, then there should be a zero crossing every 441000 / 2000 = 22.05 samples.

We can now detect the pitch by comparing the expected number of samples between zero crossings with the actual number of samples between them. This very simple, low latency pitch detection algorithm works because the Serato timecode has a fixed frequency of 1000 Hz, which means that the distance between all zero crossing is fixed. It would not work with a regular music signal, which has lots of different frequencies added together.

However, we need to use multiple sample distances and calculate the average to make this calculation more accurate, because in reality there are no fractions of samples, only full samples.

Detecting the Playback Direction

The DVS system also needs to know if the record is playing forwards or backwards.

To do that, we need to take a look at the right channel. It's basically the same signal as the left channel, but as we noticed before, it's shifted by a quarter cycle. This means that whenever there's a negative or positive amplitude peak in the left channel, the right channel is at zero.

We can use this property to detect the playback direction. After the left channel crossed zero, we check if the left and right channel waves are both positive or both negative. If so, the record is playing forwards, otherwise it's playing backwards.

For the right channels it's the opposite. After the right channel crossed zero and the left is negative and the right is positive or if the the right is negative and the left is positive, the timecode is playing forwards. If both waves are positive or both are negative, the record is playing backwards.

Now we have already have the basic building blocks to make a DVS system with a simple relative mode.

For a DVS system that allows you to skip forward and backward in a track by picking up and moving the needle (absolute mode), we need a way to detect the current position in the timecode signal. I'll explain how that works in the next post.

Mixxx 2.3.1 released

2021-09-30T15:57:13+02:00

We are happy to announce the release of Mixxx 2.3.1! Head over to the download page and download it on Windows, macOS and Linux.

This release fixes a handful of bugs and packaging issues plus adds several controller mappings.

Mixxx now includes mappings for the Numark DJ2GO2 Touch controller and the Numark Mixtrack Pro FX controller. The Behringer DDM4000, the Hercules Inpulse 300 mapping, the Denon MC7000 mapping and the Traktor Kontrol S3 mapping have been improved since Mixxx 2.3.0.

Among other minor issues, this release fixes the random skipping of tracks and the wrong track entries in the history playlist when using AutoDJ. Both bugs are regressions that were introduced in the Mixxx 2.3.0 release.

For the full list of changes, have a look at the changelog and the 2.3.1 milestone on Launchpad.

In case you're a Linux package maintainer please double check the Packaging section in the changelog and modify your packaging script if necessary.

Mixxx 2.3.0 released

2021-06-28T18:11:51+02:00

We are proud to announce the release of Mixxx 2.3.0! If you want to give it a spin, you can download it now on Windows, macOS and Linux.

This release brings a lot of new features and bugfixes:

Prepare your DJ set using hotcue colors & labels, mark intro/outro sections in your tracks and add track colors for easier library navigation. Our new multithreaded analysis and more accurate key detection will improve the preparation process further.

Mixxx 2.3.0 comes with a new default skin: "LateNight" underwent a massive redesign and replaces "Deere" as default skin, so check out the screenshots page.

If you're a Rekordbox or Serato user, switching to Mixxx has become a lot easier: You can now play tracks directly from USB drives that contain Rekordbox and Serato libraries.

We also added support for recording/streaming in the Opus and HE-AAC codecs, introduced deck cloning and polished the library and preferences (including the controller workflow).

2.3.0 also adds out-of-the-box support for the Pioneer DDJ-200 and DDJ-400, the Native Instruments Traktor Kontrol S3, the Hercules DJControl Inpulse 200 and Jogvision, the Roland DJ-505, the Behringer B-Control BCR2000 and DDM4000, the ION Discover DJ Pro and the Numark iDJ Live II. A few existing controller mappings have received fixes and new features, too.

For the full list of changes, have a look at the changelog and the 2.3.0 milestone on Launchpad.

Note: Linux users who see broken icons are affected by a bug in the KDE kIconThemes 5.80 package. If you don't have a newer version of that package in your repos, yet, see this comment for how to fix the issue.

This has been a rather big release, with lots of useful changes, bug fixes and improvements. All in all, with a total of 7477 changes over 1 million lines of code were modified since the 2.2.4 release!

Despite our plans to release Mixxx more often, it's been two years since the 2.2.x release, and 2.3 has been in the beta phase for almost a year now. The reason for these delays is that we switched to the CMake build system generator, worked on some big refactorings and infrastructure updates that were necessary to streamline our process, but also took a lot of time.

Our small development team can always need a helping hand, so if you want to help out and make Mixxx better, get in touch with us! Unfortunately, we receive almost no C++ contributions from Windows or macOS developers despite our large user base on those systems. Our whole core development team uses Linux, which makes it extremely hard to maintain support for other systems. Without significantly more contributions, the future of Mixxx on Windows and macOS is at stake. If you know a bit of C++ and use Windows or macOS, please consider helping out.

Many people spent their free time working on Mixxx and reported bugs, translated Mixxx into other languages, contributed controller mappings, improved skins and hacked on the core code. This release also features improvements to our manual made by our first intern from the Outreachy program. Thanks a lot to all our contributors, we really appreciate it!

The Mixxx code (including skins and controller mappings) has received contributions by almost 100 people:

$ git log --pretty="format:%an" release-2.2.4..upstream/2.3 | sort -u
abseits
Adam Szmigin
Albert Aparicio Isarn
Alex
Alexander Horner
Balló György
Be
beenisss
Ben
Be Wilson
Chris Hills
Christian
Christian Wolf
Codecat
Cristiano
Dan Giddins
Daniel Poelzleithner
Daniel Schürmann
David
David Baker
David Lowenfels
David TV
denvercoder21
dj3730
d-j-a-y
DJ Phatso
DJPhatso
Edward Millen
ehendrikd
ehmic
esbrandt
Evan Dekker
Fayaaz Ahmed
Ferran Pujol Camins
Frank Breitling
Geovanni Pacheco
geraldog
Geraldo Nascimento
Harshit Maurya
haslersn
Ilkka Tuohela
Jan Holthuis
Javier Vilarroig
JoergAtGithub
JosepMaJAZ
Josep Maria Antolín Segura
jusko
Justin Kourie
Katsarov
Kerrick Staley
ketan-lambat
luz.paz
Martin Kirchgessner
Matthew Nicholson
Matthieu Bouron
Matthieu Imbert
meltedpianoman
Michael
Nathan Korth
naught101
ned haughton
Nico Schlömer
Nik Martin
nikolas
Nino Miškić-Pletenac
Nino MP
nopeppermint
NotYourAverageAl
OsZ
Owen Williams
perseo22
Philip Gottschling
Pierre Le Gall
Pino Toscano
Pradyuman
Raphael Graf
Rebecca Wallander
RJ Ryan
RJ Skerry-Ryan
ronso0
Sanskar Bajpai
s.brandt
S.Brandt
Sean M. Pappalardo
Sebastien Blaisot
Sebastien BLAISOT
Sébastien Blaisot
Sergey Ukolov
Simon Harst
Stefan
Stéphane L
Stéphane Lepin
Swiftb0y
Thomas
Timothy Karani
toszlanyi
Uwe Klotz
Valefungo
Waylon Robertson
xerus
xerus2000
YunQiang Su
z411

Does using Mixxx with JACK give you zero latency?

2021-05-09T02:14:43+02:00

In regular intervals, we discuss how much latency the JACK Audio Connection Kit introduces when used in Mixxx. That is one of the Sound APIs that Mixxx supports on Linux, and it's a layer on top of the Advances Linux Sound Architecture (ALSA).

Unlike analog devices, digital audio devices process audio in time slices of samples stored in memory buffers. These are passed through the various layers. The latency of a digital audio device depends on the number and size of those buffers. The aim is to minimize the latency, so that the audible result of pressing a button or turning a knob in Mixxx is produced without noticeable delay, in order to allow DJing by ear.

The JACK FAQ state that:

There is NO extra latency caused by using JACK for audio input and output. When we say none, we mean absolutely zero.

This is true on its own, because JACK uses the buffer configured for ALSA directly to mix the audio sources together. ALSA has a second buffer with the same length that is used to feed these samples into the hardware. That's all.

However, in the case of Mixxx two more buffers are used by JACK for syncing and mixing the buffers of the patch field. It allows the client applications to use the full CPU time of each buffer cycle.

This is not a problem of JACK per se, but of the way JACK support was implemented in Mixxx.

When using the ALSA API directly Mixxx does what JACK does: It uses the ALSA buffer directly, which doesn't add any latency.

This can be confirmed by recording the own sound via a mic and measure the round trip latency. For my test, I have used the internal speaker, microphone and ALC298 Analog sound. For separating the signals in one stereo stream, I have enabled the Balance effect to move deck 1 fully to the right channel and the mic fully to the left. The test track is a 440 Hz sine wave generated by Audacity. Then I have cued the track into the pre-roll, started recording and pressed play.

These are the resulting recordings visualized in Audacity:

The upper stream is the JACK case. The left channel is the recorded master 440 Hz sine wave and the right channel is the mic input.

JACK is configured with a 1024 frames buffer and reports a latency of 46.4 ms for the sum of two buffers. The round trip latency is 95 ms (driver + ALSA + JACK async mode + duplex stream = 4 buffers).

The lower stream is the ALSA case. Mixxx is configured with the same single buffer of 1024 frames = 23.2 ms. The round trip latency is 49 ms (driver + ALSA = 2 buffers).

Not in the picture is the ALSA pulse device. It runs at a latency of 104 ms (driver + ALSA + 2 x pulse + ALSA = 5 buffers) PipeWire on Fedora 34 has by default the same latency as JACK in this test.

With this picture we can verify that Mixxx actually has the same buffer size in both cases. When pressing pause, it fades the signal out over one buffer length which is equal in both cases. The peaks in the recorded right channel is the sound of the mouse click. You can only barely see the recorded sine wave.

For reference, I have done the same test using jack_iodelay

3114.842 frames     70.631 ms total roundtrip latency
extra loopback latency: 42 frames
use 21 for the backend arguments -I and -O

The result is 70 ms (driver + ALSA + JACK async mode = 3 buffers). The duplex cycle is omitted here. This is one buffer more than a native ALSA implementation.

To verify that the duplex cycle is not introduced by Mixxx or the PortAudio abstraction layer used by Mixxx, I have routed the jack_iodelay signal through Mixxx.

2048.000 frames     46.440 ms total roundtrip latency
extra loopback latency: 2047 frames
use 1023 for the backend arguments -I and -O

This is the minimum we can expect, one buffer is needed for jack_iodelay and one for Mixxx. The result can be confirmed with the same setup using jack_latent_client which just passes the input to the output.

If we connect the output of Mixxx to the input, an extra buffer is used for some reason. This can be also confirmed with jack_latent_client and the same feedback loop.

The upper stream shows the Mixxx results and the lower stream shows the jack_latent_client results.

In addition, most distros use JACK with its default "Server Asynchronous Mode" which introduce one buffer of extra latency (--async-latency) when accessing the sound card. In Ubuntu Hirsute 21.4, QJackCtl exposes a "Use server synchronous mode" checkbox in the sound card preferences. It is grayed out by default but becomes active if "Enable JACK D-Bus interface" is checked as well. In this case the JACK mixing is done after Mixxx in the same time interval.

Conclusion

For now, we recommend using Mixxx with the ALSA backends even if you are running JACK. The same applies to PipeWire as Mixxx uses JACK protocol to connect to it.

It should be also noted that JACK can't deal well with two or more sound cards. Mixxx can do the required clock sync using the ALSA API and this with no extra latency as long the underlying driver allows it. For details refer the Mixxx manual.

Pipewire will become default on most distros and we need to find out what is the best setup for using it with Mixxx. Do you have interest to help? Get in contact with us at Zulip

New in 2.3: KeyFinder support

2021-04-08T20:00:00+02:00

Starting with the 2.3, Mixxx will integrate support for the excellent KeyFinder library by Ibrahim Sha'ath.

KeyFinder is a pretty accurate open-source key detection tool. It's been in the top 3 of the 2020 key detection comparison on Reddit and performs considerably better than the key analyzer from the QM-DSP library that current stable version of Mixxx is using.

Unfortunately, it's also a lot slower than the QM-DSP algorithm (because the latter divides the sample rate by 8 and only analyzes every 8th window, resulting in a speedup factor of 64). We hope to improve performance in the future. Until then, the Queen Mary key Analyzer will be selected by default and you'll have to enable KeyFinder in the Key Detection settings.

On Windows, macOS, Fedora and Arch Linux, KeyFinder support is already enabled. To try it out, grab one of the 2.3 beta builds from our download page. On Ubuntu, KeyFinder is not enabled yet, because we didn't find the time to create a DEB package for it.

If you want to help with out with that or work on improving key detection in Mixxx, get in touch with us on Zulip Chat.

Announcing the Mixxx Subscription Service

2021-04-01T12:00:00+02:00

We are happy to announce a major change in our licensing model: Starting with Mixxx 2.3, Mixxx will switch to a new, multi-tiered subscription plan.

Using our Mixxx Core plan for only $6.99/month (introductory offer, $9.99/month after the first 3 months), you can get your party started. It offers advanced DJ functions like a top-notch library and tag editing for organizing your music and supports playback of a single deck.

If you want to enjoy advanced DJ features such as using a second deck and crossfader, recording your set, streaming to Shoutcast servers, check out our Mixxx Creative plan for only $9.99/month (introductory offer, $14.99/month after the first 3 months).

The Mixxx Pro plan ($19.99/month) even goes one step further and lets you spice up your mix by adding EQs, controller support and samplers!

With our additional FX, DVS and Spinal Tap plans ($4.99/month each, can be purchased in addition to any of the Core/Creative/Pro plans) you can take your DJing to the next level and open even more possibilities by adding support for effect chains, enabling support for timecode vinyl and making all knobs and sliders go up to eleven (for that extra push over the cliff).

For real headliners, the Bottle Service VIP plan ($499.99/program launch) will guarantee the appearance of at least three Instagram Influencers at each of your parties.

This is an amazing opportunity for us to generate shareholder value for our hedge fund investors and reshape the DJ experience for our customers. Because of this is such a huge step forward, we don't want to overwhelm our users and make the transition as easy as possible. Therefore, we will postpone all bug fixes and features for an indefinite amount of time instead of including them in Mixxx 2.3.

Note: Existing Mixxx installations will start a 30-day free trial of the Mixxx Core plan. Customers need to enter payment data before the trial period is over to continue using Mixxx. If you're not satisfied with the service, you may cancel anytime. Please note that canceling the subscription does not cancel payments. Refunds are not available.

EDIT: As you probably noticed, this is an April Fool's joke. There is no subscription plan, and Mixxx is and always will be free.

A Statement on Richard Stallman and the Free Software Foundation

2021-03-26T00:00:00+01:00

The contributors to the Mixxx project were dismayed this week to learn that Richard Stallman had been reinstated to the board of directors of the Free Software Foundation. His departure in 2019 was a consequence of the criticism he faced regarding his inappropriate behavior towards women, his hurtful comments about people with Down's Syndrome and his remarks relating to the Epstein scandal. His resignation came as a relief for many who have suffered his actions. Richard Stallman's actions disqualify him from representing the FSF and the free software community as a whole.

While Mixxx is not officially associated with the Free Software Foundation, there's an inevitable connection in the public's mind between all FOSS projects and the FSF. Furthermore, Mixxx is and always has been licensed under the terms of the GNU General Public License, version 2 or later, and only the Free Software Foundation can publish new versions of the GNU GPL which could be retroactively applied to the Mixxx code. Given this relationship, the Mixxx project has an interest in ensuring that the Free Software Foundation has inclusive, principled, and wise leadership which can effectively lead the broad free software community to meet present and future challenges.

Therefore, we feel an obligation to add our voices to the chorus of those who have expressed dismay at this turn of events and call for the resignation of Richard Stallman. The FSF board of directors, by allowing him to return, is giving the appearance of endorsing his conduct and can't remain effective without significant personnel changes and bylaw reforms. By sanctioning his return, the board of directors has lost all credibility on the issues of diversity, equity, and inclusion. The myriad software developers who chose to trust the FSF with stewardship of licenses for the code we wrote deserve to have a voice on the leadership of the FSF. We cannot trust an organization that knowingly makes controversial decisions behind closed doors. We do acknowledge the Free Software Foundation's efforts to revise its bylaws to establish democratic processes for electing leadership and to increase the transparency of its activities, and the community will be watching closely to verify that these changes are effective and substantial.

The FOSS community has led the way for the rest of the wider tech industry, showing that open standards and practices result in better products while respecting users' freedom, privacy, and community. Now we have the opportunity to light a better way for the industry at large by showing that a more welcoming, inclusive industry also creates products that are better for everyone. Our community needs to demonstrate a strong sense of accountability at this time. We expect the FSF board to do the right thing and follow up its statements with actions by accepting responsibility for this bad decision and enacting specific commitments for change to rebuild trust.

About my Outreachy internship with Mixxx DJ: Week 13 progress

2021-03-01T19:33:00+01:00

This is the thirteeth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

Following last week’s progress, I finished making the edits to the video, and now, I’m only waiting to get feedback before I add in any animations or effects. I hope to upload it this week (since I’m writing this blog in the next week). 🤞🏽
I have been working on issue #117 – updating the screenshots of the 2.3 manual from the Deere to Latenight skin. I hope to make a PR this week.

And… this is the last week of the Outreachy internship program. This week’s blog is not as long as the previous ones because I have not documented what I will be doing next week. This is because I have not planned out all of the details yet, but of course, I will be making improvements to the manual – next week I will be updating the screenshots in the 2.3 manual from the Deere to the Latenight skin. I hope to check this item off the checklist in this issue. And then, of course, I will continue making tutorials for the Mixxx Youtube channel and working on the cookbook/ DJing techniques chapter.

This has been a great experience interacting and getting to know the Mixxx community virtually. Overall, I would say my internship has been a success because I was able to gain practical skills, work in a fantastic environment that is really inclusive, and make connections that will last a lifetime. I could not be more thankful.

This is NOT goodbye, because I am still going to continue contributing to Mixxx, and endeavor to finish the projects that I started. That is, I will still be making tutorials for the Mixxx YouTube channel, working on the DJing techniques/cookbook project, and making other improvements to the manual. See you next week 😉

Improving the Mixxx developer experience with maintainable build infrastructure

2021-02-23T19:17:51+01:00

Since we published Mixxx 2.3 beta in June 2020, you may have been wondering what has taken so long to get the 2.3.0 release out. Well, we have been very busy the past few months building a more sustainable technical infrastructure for the Mixxx project. We have moved this website to the Pelican static site generator and moved the forums to Discourse. Additionally, we had to do a ton of work for the macOS and Windows builds. "Building" software is the process of transforming the code that we write into an executable file that you can run on your computer.

Build Servers

We introduced support for the CMake build system with the release of 2.3 beta, but there were still rough edges at that time, particularly for building Mixxx on Windows and macOS. When we released 2.3 beta, we planned to keep using the old SCons build system for 2.3 on the servers that make our official builds. However, shortly after we announced 2.3 beta, the self-hosted Jenkins Windows build server stopped working. That was far from the first time our self-hosted build servers went offline and we got tired of continually troubleshooting these self-hosted servers. So, we decided to not bother fixing the old build server and instead move our builds to a hosted service.

We were already using AppVeyor for Windows and Travis for macOS & Linux continuous integration to build each commit (change to the code) to catch bugs early. However, we were not uploading the builds from AppVeyor or Travis to our file server at downloads.mixx.org. Also, we were using the free options for these services. Together with the slow, old SCons build system, these CI builds hit the time limits on the free tiers so often or took so long to run that we often ignored them. When Travis announced tighter restrictions on their free service, we decided to evaluate other options.

It turned out that GitHub Actions met all our needs with support for macOS, Windows, and Ubuntu. GitHub Actions allows us to run a maximum of 20 concurrent builds or 5 concurrent macOS builds with a 6 hour time limit for jobs. The 6 hour time limit for jobs is important because Mixxx's dependencies take about 4 hours for a full build without a cache.

While we are wary of being dependent on services that are powered by proprietary software and have other serious issues, no other service provides comparable computing resources as GitHub Actions does for free. For a busy project with little budget, that is super helpful. Moreover, GitHub Actions hosts the artifacts from every build, even on pull requests. This allows users to test Mixxx before we merge changes to the code without the users needing to know how to build Mixxx. This also makes it much easier for developers to test changes on operating systems they do not use personally, which is very helpful because all of our core development team runs Linux.

macOS Woes

Since we were switching to a whole new build server setup, we decided to get the new system working with CMake rather than keep using the old SCons build system. Although CMake comes with tools to make macOS application bundle packages (the files users download and drag and drop to their /Applications folder), they are sorely lacking and badly documented. Since none of our core developers use macOS and macOS is cumbersome to run in virtual machines, one of our core developers had to borrow an old Macbook Air from a friend to do this work. Getting CMake correctly building macOS packages took more than a week, but that was only the beginning of the journey.

A great aspect of using GitHub Actions for our builds is that GitHub does the work of keeping the operating systems and build tools in the virtual machine images up to date for us. However, when we tried to build Mixxx with our old archive of dependencies on GitHub Actions, it would not build because GitHub Actions no longer had a version of XCode old enough to support the macOS 10.13 SDK which was used on our old macOS build server.

So, we got GitHub Actions to run the scripts we used on the old build server to build all of Mixxx's dependencies. This took about another week of work. With a new archive of dependencies built by GitHub Actions, we could build Mixxx on GitHub Actions. Then, more complications became apparent.

The builds from GitHub Actions were so laggy that they were completely unusable, but the builds from the old build server with the same code were okay. It turned out that having our own build server that was such a hassle to upgrade that we didn't do it for years was masking a serious bug. Building Mixxx with a macOS SDK 10.14 or newer made Qt use layer backing. Combined with the legacy QGLWidget API we still use for Mixxx's waveforms, this was extremely slow. We have previously attempted to update to the newer QOpenGLWidget API. Although this performed much better on macOS, the waveforms jerked back and forth instead of scrolling smoothly. We considered trying to finish this work for 2.3, but the task is difficult and would require major changes to the waveform rendering code.

Ultimately solving this performance issue will require rewriting our whole GUI for Qt6 which will also be a huge challenge. If anyone reading this is skilled at graphics programming, please get in touch on our Zulip chat. We could really use help figuring out how to rewrite waveform rendering for Qt6. For now, we are using an ugly hack of automatically downloading the macOS 10.13 SDK to build Mixxx with current versions of XCode that do not officially support that old of a macOS SDK.

But that was not the end of the macOS-specific bugs. While working on rebuilding our dependencies, we updated to Qt 5.12.10 from 5.12.3. However, when Mixxx was built with Qt 5.12.10, it would not show any windows at all on macOS 11. So for now we are stuck with Qt 5.12.3 and the macOS 10.13 SDK. Altogther, dealing with these macOS-specific problems took about 3 months of work, and we are glossing over some details here.

With CMake working on every OS we support, we changed our plans and decided to drop support for SCons for 2.3.

Winwoes

With macOS builds finally working on GitHub Actions, we still had challenges with Windows. Although we could build Mixxx on Windows on GitHub Actions using our old archive of dependencies, the server we used to build those dependencies was no longer functioning. In Mixxx 2.3, we have added support for analyzing tracks' musical key with libkeyfinder, but this new dependency was not in the old Windows build environment. We could not work around that by simply downloading libkeyfinder automatically when building Mixxx because libkeyfinder has its own dependency on FFTW. Moreover, if Mixxx users were affected by bugs in any of our dependencies, we would not be able to update them if we kept using the dependency archive from the old server.

We tried to get our old Windows batch scripts for building Mixxx's dependencies to run on GitHub Actions. However, like on macOS, we ran into challenges because GitHub Actions' virtual machine images had a more up to date version of the MSVC C++ toolchain than our old Windows build server. Our old scripts relied on old Visual Studio project files to build many of the dependencies. These did not work without modification on GitHub Actions. Updating those would have required a developer using Windows to update them using Visual Studio, but all of our core developers use Linux and nobody wanted to learn how to do that. If we did manage to do that, we would likely have to do that all over again when Microsoft releases a new version of Visual Studio.

Rather than update our old build scripts for Mixxx's Windows dependencies, we decided to abandon them in favor of Microsoft's new vcpkg package manager for C & C++ libraries. Using a package manager is a much easier way of building our dependencies than our own custom build scripts. Many of our dependencies were already available in vcpkg, but many were not or had various issues using them with Mixxx. We had to add new packages for:

chromaprint
libdjinterop (will be a new dependency for Mixxx 2.4)
libebur128
libkeyfinder
libid3tag

For several other packages, we had to get them building with CMake or make changes to their CMake build systems to make them usable for Mixxx on Windows. These are still waiting for CMake support to be merged upstream to the libraries before we submit packages to vcpkg upstream:

This took another month of work after spending three months working on the macOS builds, but it was well worth it. The old scripts to build Mixxx's Windows dependencies on the old server took 36 hours to run because the server built both 32 and 64 bit binaries and built each with two different set of compiler options. We are dropping support for 32 bit Windows in Mixxx 2.3, so half of that build time is gone. A full build of Mixxx's Windows dependencies with vcpkg takes about 4 hours. Now, with caching on GitHub Actions, adding or modifying a dependency for Mixxx only takes about 20 minutes.

Using vcpkg has allowed us to build Mixxx with some dependencies that were missing on Windows before because nobody wanted to put in the effort to write Windows batch scripts to build them. Now, Mixxx can play module tracker files with libmodplug and use LV2 effects plugins on Windows. Coincidentally, as we were working on this, falkTX at DISTRHO published the first release of PawPaw bringing many LV2 plugins common on Linux to Windows and macOS, which can now be used with Mixxx! Here is Mixxx working on Windows with LV2 plugins, Modplug, and KeyFinder all working:

vcpkg is great for us because it works on Windows, macOS, and Linux. This allows us to work on packaging Mixxx's dependencies for Windows while we work on Linux. As long as the dependency's build system is crossplatform (CMake or Meson), this is quite easy. If they do not have crossplatform build systems, that is one reason we are working on getting CMake support merged upstream. Plus vcpkg's overlay feature makes it easy for us to make custom modifications to certain packages while easily merging updates from upstream for every other package.

Most of our dependencies already work on macOS and Linux with vcpkg, with the notable exception of the unmaintained portmidi library. When we get that working with vcpkg, or potentially replace it with a currently maintained crossplatform MIDI library such as RtMidi17, we will be able to use vcpkg for all our dependencies for both Windows and macOS. For Linux, we are considering distributing Mixxx as a Flatpak using the dependencies from vcpkg in the future, but this will have to wait until PipeWire is included in more Linux distributions, which will start happening in the next couple of months with the releases of Fedora 34 and Ubuntu 21.04.

Developer Experience

All of this work has been very tedious. We would have much rather spent this effort writing fun new features for Mixxx, but this had to be done to keep the project going. Now that it is working, developing for Mixxx is much nicer.

As we got the new setup going with GitHub Actions, we wrote scripts that can be used both by GitHub Actions and by developers that want to set up a development environment on their computer. The scripts automatically download the archive of Mixxx's dependencies. On macOS, the script sets the appropriate environment variables. On Windows, the script generates a CMakeSettings.json file which can be used to setup Visual Studio to work on Mixxx very easily. We hope this makes Mixxx more welcoming for Windows and macOS developers to contribute.

Developers on every OS can now easily have their code built and tested automatically on Windows, macOS, and Linux simply by pushing commits to GitHub, and we can ask users to give feedback using the build artifacts from GitHub Actions.

On macOS and Linux, the builds on GitHub Actions only take a few minutes now that we are using ccache which was easy to implement with CMake. We have tried getting compiler caching working on Windows with sccache and clcache but have not succeeded yet, so the Windows builds still take about 40 minutes.

Historically, issues with the build servers have been a major factor why Mixxx releases have been so few and far between. We hope that by having this automated on a reliable service that we do not need to maintain ourselves, we can focus more on programming cool new features and getting Mixxx releases published more regularly.

If you want to get involved in making Mixxx more awesome, come introduce yourself on our Zulip chat. You do not need to be a coder to contribute. Our new infrastructure makes contributing easier both for developers and testers!

Addendum: compiler caching on Windows

After figuring out undocumented requirements for sccache, fixing a bug in it, and fixing another bug in Google Test, and working around a bug in GitHub Actions caching, we have compiler caching working on Windows. Windows builds now take 16-18 minutes. That is significantly longer than macOS which takes about 10 minutes, but it is a big improvement from 40 minutes per Windows build without compiler caching!

About my Outreachy internship with Mixxx DJ: Career goals

2021-02-22T11:30:00+01:00

About me

My name is Aanyu Deborah Oduman. I am 23, and I work and live in Uganda. I just recently finished studying for my bachelor’s degree in Computer Engineering from Makerere University, Kampala, and I am slated to graduate in mid-March.

For the past three months, I have been contributing to Mixxx in improving their documentation. The goal is to make the Mixxx software easier to use especially to the new user by making the manual easy to understand and follow. I have also been making video tutorials for the Mixxx YouTube channel; videos that will act as a guide for Mixxx users to follow and make great mixes.

My background

I have always taken a keen interest in tech, but I didn’t get to fully explore it until I joined the university and enrolled in a Computer Engineering course. High school provided a couple of opportunities in robotics and innovation, but with the limited resources and the vast number of students, the time was never enough to learn and master a new skill. But even with the limited resources, I am grateful to have had the chance to learn how to build lego prototypes and write simple programs for them.

I started learning C+ and Python, as part of the engineering curriculum and this foundation propelled me into wanting to learn more about programming and seeing what else I could do with code. With these basics, I enrolled in a couple of coding bootcamps and attended a few seminars in aviation and software development. I applied to the Andela bootcamps, just when the company was still new and we were just getting to know about the awesome tech startup. It is here that I learned how to use HTML, and CSS – things that were not taught in my engineering course.

After a while, I applied to the Google-ALC training programs where we were given free access to some of the best coding courses on Pluralsight. I learned more about HTML5, CSS, Bootstrap and Python and created my first website using Flask.

I worked on a few other projects alongside school, though, with the tight schedule, I didn’t get to do it consistently until the lockdown of March 2020. COVID-19 came with a lot of downsides, but I was fortunate that it came as a blessing in disguise for me. I was stuck home with nothing else to do but bury my head in the heaps of programming languages and stacks. I was finally able to put my HTML, CSS, JS and Python knowledge to use and that’s when I learned Frontend Web development with ReactJS in a 3-month remote internship that taught me everything I know about Frontend web development. The program was continued in a second 4-month (or more) internship where they taught Backend with NodeJS, and finally, full-stack web development with MongoDB, ExpressJS, ReactJS, and NodeJS.

Around the same period, I had the honour of participating in the #BuildforSDGs challenge; Cohort 2. The #BuildforSDGs program is committed to helping empower people to build real-world, locally and relevant solutions focused on the Sustainable Development Goals (SDGs) while gaining skills needed to advance in one’s career. I got to collaborate with really talented developers from all over Africa and received priceless mentorship from the experts at Andela and Facebook.

Shortly after, towards the end of the program, I started applying for the Outreachy FOSS internship, and this where I am now.

The skills that I have learned through working for Mixxx

The Outreachy internship with Mixxx introduced me to Free and Open-Source Software. I had never contributed to FOSS before the program, let alone knowing what the term meant.

Through the internship working with Mixxx, I have gained experience in technical writing on a larger scale, and with a more recognized project. I had only used markdown before while working with git, but now, I get to use markdown and reStructuredText for much greater work.

I am getting to understand more about how to use Git, especially on an active project with many (experienced) contributors. I am more comfortable with git now than I used to be. I think it is safe to say that I can extricate myself from sticky git errors and I understand git tree structures much better.

I have gained more confidence in my skills as a video and content creator, especially for technical projects such as Mixxx. I understand better how to use video editing tools to make short understandable YouTube tutorials for the new Mix user, and how to write scripts for the videos.

I have learned more about usability, in the context of how easy software should be to understand and to use by people new to them. With every new addition that I make to the Mixxx manual, I understand more about how the software works and the GUI aspects of it.

The list of skills that I have learned through the Mixxx internship is quite endless. I learned how to send files to another computer using OpenSSH and rsync in a command-line – something that might be easy for Linux users to do. I have a better understanding of how Open-source software communities operate and how to get started contributing to Open-Source software. Not forgetting the confidence that I have gained through the interactions that I have had with the various contributors in the community. I have come to appreciate teamwork more, and the importance of asking for help when I need it.

What next? What are my career goals?

I love contributing to software applications that people use in their everyday lives. I have loved receiving immediate feedback on my technical writing and video editing skills in this internship. I have loved having a mentor who I can turn to for guidance about most things open source related. Open source embodies some very positive aspects of the internet – and that is collaboration, knowledge and skill-sharing towards a common goal. The results are impressive and demonstrate what can be achieved from small contributions of time and effort by a large number of people.

I would love to continue being a part of the open-source contributors’ community and adding my input to various open-source projects. I look forward to exploring different open-source internship programs such as the Major League Hacking open-source internship program, Google Season of Docs, Google Summer of Code, among other open-source opportunities. I would love to grow my experience in working with various software and learn from highly experienced and long-standing members of the Open-source community.

I look forward to strengthening my skills in Frontend web development, and eventually Backend web development. During the lockdown period, I started off learning React JS and I was able to work on a couple of personal projects. I want to take it to the next level and learn more about things like Continuous Integration and Continuous Deployment (CI/CD), test-driven development (TDD), shipping apps using Docker among other things. I want to get more comfortable with using public APIs in the applications that I create (this has always been tricky for me). I also look forward to learning how to use Django for backend development and eventually get comfortable with it. I want to strengthen my skills in UI/UX design and incorporate this with the frontend dev stack and finally, if the opportunity presents itself, I will contribute to an Open source project using some of the technologies in the MERN stack or in UI/UX or even in Django or Flask.

What interpersonal skills make me a good collaborative member?

Open-mindedness

I am open to and accepting of new ideas. When people get together to discuss a project, different ideas come from different perspectives and areas of expertise, so there’s inevitably going to be a flurry of ideas on the table about how to proceed—ideas that’ll be unfamiliar, new, exciting, and possibly difficult to understand. As a naturally curious person, I thrive in this kind of environment.

Communication

I try to make sure to communicate openly and clearly with other contributors. I am mindful of different communication styles and I adapt the way I communicate accordingly.

Fostering a collaborative environment means making room for all types of communication and communicators. I love that the collaborative process in open source usually incorporates alternative ways of communicating, otherwise the most outspoken people would steal the show.

Organization

One of the things about contributing to open-source programs remotely is that no one will be physically around to push you to do anything or get work done. The process is, for the most part, self-paced and I believe it takes a certain level of organization to make valuable contributions to a project. Throughout the Outreachy internship working with Mixxx, I have kept myself organized, assigning myself tasks daily and managing my time effectively. I try to take my organization beyond just doing what I’m assigned but taking the initiative to find out what needs to be done and then doing it.

Long term thinker

I like to envision the end result of a goal before I get started and continue to do so while I carry out my duties. Collaboration is about working towards a common goal or a shared purpose and recognizing how my contributions fit into that goal. I endeavour to have a deeper understanding of the project’s scope and everyone’s role in it because the more I understand this, the better I will be equipped to make it happen. I believe that understanding my broader purpose helps me make more meaningful contributions to the team.

Adaptability

Sometimes collaborative projects don’t go as planned. Priorities shift, obstacles delay progress, and problems occur, catapulting the whole project into complete disarray.

To persevere, people need to be able to adapt at a moment’s notice. I adapt easily to sudden shifts in goals or priorities and prefer to brainstorm solutions to problems that may be encountered while working on the project, as opposed to freaking out and not working towards a solution.

What am I looking forward to ?

I want to keep working with Mixxx, so I can get better at technical writing and make video tutorials that explain specific technical concepts. I prefer to work with communities that openly make efforts to improve diversity and Mixxx does this. So I plan to continue contributing to my current community even when the internship is officially done. If I manage to find another paid internship or a remote paid full time or part-time job, that would be great.

I am aiming to secure opportunities that will provide me with the exposure and chance for progression in the world of web development and Open-Source software.

My three-month internship with Mixxx was a full-time remote internship which has made me come to appreciate the perks of working remotely. I would love to continue doing so (working remotely), but if required, I am also able to move to a different region or country for work.

I have a non-tech background in art, content creation for social media – I managed social media for an online platform called Celebu Online and a creative arts group called Kelele @ Makerere. I also have a background in writing – a skill that has greatly helped me with the technical writing bit of the Mixxx project. I believe that this background provides me with a unique perspective on certain things, especially in the areas of usability, marketability, creativity, team-work and what consumers like.

In five years’, time, I hope to be an exceptional software developer who has imparted the skills that she has learned to other younger people aiming to get into the field. I hope to have empowered other people who wish to join this industry by teaching them what I know and exposing them to opportunities that will help them progress in their career, like I’ve had. I hope to have scored a more permanent job doing the things that I love and effecting change in other people’s lives, one way or another, and I’m grateful to Mixxx and Outreachy for launching my career in the right direction.

About my Outreachy internship with Mixxx DJ: Week 12 progress

2021-02-21T21:50:00+01:00

This is the twelfth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I added the step by step tutorial on deck cloning for playing with a single turntable. See pull request #330 I plan to do the same for beat juggling, but I want to get feedback on how that looks before I proceed to do the same for beat juggling.
I made the video tutorial introducing Mixxx to the first time user – a tutorial guided by chapter 4 of the manual. I’m still making edits to the video, but I’m hoping to finish with this by the end of the week.
I lost a couple of days to long distance travels – from my home to the city and back. I had also to do bit of adjusting migrating from Windows to MacOS, but I’m getting there 🙂
This week (since I’m writing this blog late), I will be making a pull request for issue #293 (“Mention mp3 encoder in Recording chapter”). I posted a question in the comments section, hopefully I will get an answer this week.
I'm also going to make another Youtube video tutorial and add other minor fixes to the Mixxx manual 🙂

About my Outreachy internship with Mixxx DJ: Week 11 progress

2021-02-14T12:09:00+01:00

This is the eleventh weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I successfully added rekordbox (and its icon) to the list of supported libraries in this pull request that I opened a long while ago – I was documenting the rekordbox library import.
I also started a LinkedIn company page for Mixxx, on the suggestion of my mentor. I think it will be a great way to get Mixxx to reach an even wider audience. Here is the link to the page.
I learned something new this week! I learned how to use rsync and OpenSSH inside the cygwin command-line environment to send files from one computer to another. The learning curve was slightly steep but I finally got the hang of it. I sent the YouTube Mixxx tutorials that I have made so far through the cygwin command-line to my mentor, Owen.
I added more documentation to the track/library analysis section in the manual. The manual did not define what analysis does and why it is important, so I felt like it could easily be overlooked – especially by new users. I added some information about why users should do it in advance and what happens if they don’t. I opened a pull request here.
I didn't get to make the video introducing Mixxx to the first time user last week…a tutorial guided by chapter 4 of the manual. So will be doing that this week.
I will continue working on pull request #330. I am taking a step by step instruction approach with documenting deck cloning in the cookbook. I hope to have made some progress with this pull request this week.

New in 2.3: Importing tracks and cues from Serato

2021-02-08T11:18:15+01:00

As all of you probably know, Mixxx is the best DJ software in the market. However, we've recently been made aware that a minor competitor has emerged and tries to steal that title from us - Serato DJ Pro. The hardware support is nice, but since Serato is neither open-source nor as customizable, we're not too concerned. From the user's perpective, switching to the most popular open-source DJ software in world seems like the obvious choice.

Unfortunately, migrating from Serato to Mixxx is a lot of work - apart from familiarizing yourself with a new tool, all the countless hours you spent to organize and prepare the tracks in your old library are lost, and you need to start from scratch. At least until now - if you're a Serato user and cast an eye on Mixxx, we've got a nice surprise for you.

Use your Serato library in Mixxx

In addition to Rekordbox device libraries, we added support for reading Serato's database files in Mixxx 2.3, too. This means that the tracks from your Serato library will show up in in the library table and can be directly loaded onto decks without the need to add the music directory in the preferences. Crates created in Serato are also supported, so your collection is still neatly organized.

If you have USB drives with a portable Serato library on it, we've got you covered as well: Libraries and crates on external USB drives will work on all supported platforms - even on Linux!

Import your Beatgrid and Hotcues

Sorting tracks in your library is important, but preparing cue points in tracks is probably the most time-consuming task. Serato saves them in special file tags along with the other track metadata like title, artist and so on. It took months of work, but we finally managed to reverse-engineer the binary formats used by Serato to a degree that allows us to parse this information and use it in Mixxx.

This means you can import the positions, labels and colors of your hotcues into Mixxx automatically when you load the track for the first time. Mixxx will also import the Beatgrid from Serato, which works for both Beatgrid that were automatically detected by Serato's track analyzer and those that you edited manually.

If you already added a track to your Mixxx library before support for reading Serato's hotcues was added, you can trigger a reimport of the metadata via the track context menu. Note that this will clear your existing cuepoints in Mixxx if the track has any Serato hotcues.

Unfortunately, a myriad of encoders and decoders for lossy formats such as MP3 and M4A/AAC exist, which leads to a situation where all decoders detect slightly different track start and end times for files from different sources. Hence, your cues might end up shifted by a few milliseconds.

We've done our best to mitigate the problem, but if you experience issues we'd appreciate if you get in touch with us on Zulip Chat and work with us to make the offset correction more accurate. Additionally, we've added a way to shift all cues for a track at once. This makes it possible to fix the cue positions if Mixxx fails to determine the correct offsets.

Support for other Serato metadata

Mixxx 2.3 will also import saved loops from Serato, but proper support for saving and restoring loops is scheduled for 2.4. For the time being, we just import these loops into the Mixxx database and allow using their start position as regular hotcues. That way, you can start using your loops once 2.4 is out without the need to reimport your metadata (which would undo your cue modifications in Mixxx). Other Serato metadata that we parse include the track color and the BPM lock status.

Serato also stores other information like the overview waveform image, but we don't import that information in Mixxx 2.3. Serato Flip macros are not imported either, because Mixxx does not support that kind of functionality yet. This is going to change with this year's GSoC project by Janek Fischer, so hopefully we'll be able to import them in the future.

Can Mixxx write Serato's Tags?

If you're running our development snapshots, you may have noticed that it's not possible to write cues from Mixxx into Serato metadata tags yet.

At Mixxx, we believe vendor lock-in is a bad thing and that users should be free to use the DJ software they like best. While these changes allow you to migrate from Serato to Mixxx with less friction we don't want to lock-in users into Mixxx either.

This means we're looking into adding support for Serato metadata export in upcoming Mixxx releases. Even for Mixxx-only users this would make it easy to transfer cue points between multiple computers.

We already have some code in the pipeline, but since it's a complex undocumented binary-only format we didn't want to rush adding support for writing these tags. Bugs in the code or misconceptions about the format might lead to data loss and potentially even crash Serato, so extensive testing is necessary.

Hence, it's still uncertain if support for Serato tag export will already land in Mixxx 2.3 - but stay tuned!

About my Outreachy internship with Mixxx DJ: Week 10 progress

2021-02-07T23:09:00+01:00

This is the tenth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I made the necessary edits to the YouTube tutorial about the Mixxx community and uploaded it to YouTube. Here is the link.
I had a brief video call with community team leaders from the Tor Project to discuss more about the internet censorship situation that has been going on in Uganda. The purpose of the discussion was to understand more about how I am using Tor and other anti-censorship tools, and how it can be improved based on my feedback.
To get some inspiration for the cookbook chapter, I read through the first few chapters of the Mixxx manual, looking for sections that could use the step by step instruction approach that the cookbook will provide. I found an area in the “Analyze your tracks/ library” section that needed more explanation, and discussed it in the Zulip chat. I will be filing an issue and making a pull request for it soon.
I lost a day of work to no electricity and maybe half a day to the poor internet speeds (some of the downsides to using VPNs).
Next week, I will be working on a number of pull requests implementing suggested changes. One of them includes converting the deck cloning section into a step by step instruction guide as opposed to a whole article.
I will be adding new sections to the same chapter with the same step by step approach – this will be my main task this week. All the (new) sections that I will be adding are subject to discussion. It is a work in progress 🙂
Finally, I will be making another YouTube tutorial introducing Mixxx to the first time user… This tutorial will be guided by chapter 4 of the manual and will go something like;
- Start the Mixxx software
- Import music to the Mixxx library - import your audio files
- Analyze your library tracks (what it means to analyze a track)
- Configure Sound output - especially if you're not using any DJ Hardware
- Play your first track with Mixxx
- The Mixxx manual - in case you need to refer to a Mixxx resource for help

About my Outreachy internship with Mixxx DJ: Week 9 progress

2021-02-01T11:15:00+01:00

This is the ninth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I made a pull request #203 for this issue that I had filed to correct the broken link to Paul Bloch of open Artist (creator of the Mixxx logo).
I recorded the video tutorial about the Mixxx communities, following the script that I wrote the week before last. I got feedback for it from my mentor, and I need to do some editing. I will be editing and uploading this video next week, after getting feedback from the community on Zulip.
Following the discussion on GitHub for issue 335, I have rearranged the Live Broadcasting – Start your own Internet radio chapter – mostly just headings. I made a pull request for it here.
Next week, I will be writing a script for the next video tutorial that I will be making (yet to decide which one but most likely it will be a 5-minute in-depth video about mixing (once the program is set up). I have homework to do with this one, considering the fact that I’m not a pro with mixing, but I look forward to the challenge.😅😅
Once I have done my homework and written the script, I will record the video, send the first cut to my mentor for feedback before I re-record or edit the final video. Just like I did for the Mixxx communities video.
I also realise that I need to do my homework on the cookbook. (See comment on cookbook chapter). I need to choose topics that will not conflict with the DJing with Mixxx chapter. Some of the topics that I had chosen earlier were similar…. with the content in this chapter. This will be my assignment this week.

About my Outreachy internship with Mixxx DJ: Contributing to open source amid Uganda’s internet restrictions

2021-01-24T14:00:00+01:00

Last week, amid the 2021 general election, Uganda was disconnected from the internet entirely. The country experienced a widespread internet blackout that lasted 4 days, starting on the eve of the election (13th January 2021) and ending in the morning of 18th January 2021. In the days leading up to the election, access to major social media platforms and circumvention tools was blocked – even when the OTT (Over the Top) tax (commonly referred to as the “Social Media Tax”) was paid. This internet shutdown and the social media ban that followed affected many online jobs and businesses, my internship with Mixxx under the Outreachy program was no exception.

Before I write this article, one thing to note is that Ugandans have been in this internet battle with the government for quite some time now. The internet shut down came as a surprise when it did, but at the end of the day, I feel like we should have seen it coming. By the time it dawned on us that the internet really had been disconnected, we were already in darkness, with only the people physically close to us to express our shock too. The audacity of this government!

As the years go by, our President, H.E Yoweri Kaguta Museveni, has been feeling a lot of pressure about the presidential seat. If elections were conducted freely and fairly, you would notice a declining trend in the number of votes his political party (NRM) has been getting over the years. Ugandans are tired, and they want change. They have been more vocal about the injustices that have been happening in the country and it has cost them their lives, even their families’. This resistance from the public has been causing anxiety in State House, and it’s starting to show.

In the 2016 presidential elections, Ugandan authorities blocked access to Facebook, Twitter and WhatsApp saying the platforms would be used by the opposition to mobilize protests. (This article from the BBC has more context on the social media blockage) President Yoweri Museveni was facing a tough challenge from veteran activist Kizza Besigye, and he believed shutting down social media would help to curb the “threat”. Authorities also suspended mobile transfers of money.

In 2019, the government introduced a tax on the use of the social media, which activists have called an attempt at controlling free speech. He said that the youth only use social media to gossip and spread wrong rumors (about him). (This article from the BBC provides a better account of the imposition of the social media tax by President Museveni on Ugandans) . He imposed OTT – Over the Top Tax and since then, it’s never been enough to simply have a good internet connection. You have to pay a daily fee of UGX 200 to your Internet Service Provider, or if you’re being rebellious, a VPN application installed on your phone or computer. He insisted that the revenue collected from the tax would help the country cope with the consequences of olugambo [gossiping]. I don’t know... but to me, these look like the actions of an increasingly anxious person in power.

On 12th January 2021, the Uganda Communications Commission (UCC) ordered internet service providers in the country to immediately suspend any access and use of all messaging apps and social media platforms until further notice. This was done so suddenly and without prior notice that it took most of us a couple of failed OTT subscriptions to realize that social media platforms had indeed been blocked. Before that, internet speeds had become excruciatingly slow, it was any wonder we were able to get anything done in those few days. A few days after the social media block, the government decided to shut down the entire internet! (The social media ban was simply not cutting it) So when Google stopped working and our parents were restarting their phones several times, is when we realized that truly, there was no end to the surprises.

During this (not so brief) period we were in total blackout. No internet services were available anywhere. I was not doing any work as far as the Outreachy internship with Mixxx goes. I was not making any contributions, and sadly, that whole week went just like that. We (devs) wondered if there was a backdoor to the whole situation, maybe some independent internet Service Provider that didn’t serve the government or something – lol. I was not sure what to do without the internet so I read books, watched movies on CD, took nature walks, anything to pass the time. How did our forefathers survive without the internet ?

So after NRM won the Presidential election, the internet was restored on Monday evening (18th January). There is speculation regarding this matter as to who exactly restored the internet. Word has it that it was the Anonymous that had hacked the government systems and restored the internet. On the other hand, neither the ISPs nor the Uganda Communications Commission openly came out to declare/ announce that internet had been restored. The internet had been restored alright, but we still could not access social media. Not with OTT, and definitely not with certain VPNs. But the election was over, was it not? Then why was social media still blocked? This time, not only had social media been blocked, but all app stores, YouTube, and most VPN clients. (This article by techjaja provides more detail on the platorms that were banned in Uganda and when it happened.)

At this point, I was ready for anything. I had about two VPN applications installed – Psiphon Pro, and Thunder VPN. Nothing was going to get in the way of work this time.] The VPN connections were mostly flaky so I decided to add Orbot and Tor Browser to that list. Things were working for a while, but I should have known that the relief would be short-lived.

I was working one day when I encountered this error while trying to access GitHub.

I thought that was odd, considering I’ve always accessed GitHub with no difficulty. I didn’t think much of it. I thought that as long I could run commands in the git command line, I would be okay.

While I was wrapping my head around the whole situation, Gus from the Tor Project asked if I would volunteer to run a simple test (See the Emma repository on Github for them to see if Tor Bridges were working. I said yeah! Sure! Anything to bypass the next internet shut down. So I had to access the repository for Emma (a lightweight censorship analyzer) on GitLab, but to my dismay, I could not access GitLab. I got returned the same error “this site can’t be reached”.

Well, that’s just ridiculous, I thought. I entered this URL in my browser https://www.torproject.org/ to see if it was a “tor issue”. The browser returned “This site can’t be reached”. So then, I realized all Tor sites had been blocked too, probably because the government suspected that we would try to use Tor to bypass the internet restrictions. Smart! I was pissed, but I thought it was smart. I went ahead and opened the Tor Browser on my computer, pasted the same link there, copied the link to the repository and ran ‘git clone’ in my command line. Error!

I reported this error to Gus, who suspected that the https://torproject.org domain had been blocked. He then gave me a link to a different GitHub repository with the same code to clone but I kept getting returned the same error “Failed to connect to github.com port 443: Timed out”.

My suspicions were right – the government had blocked GitHub too. GitHub! I did not understand the reason for this considering GitHub is not even a social media application. It’s not a VPN either, so what was going on?! I thought I had been blacklisted by the government and they had blocked my IP address from accessing these sites or something.

It was hard not to feel defeated. I wondered how I would get any work done if I couldn’t even use GitHub? How would I get inspiration for the “Create video tutorials” project if YouTube was blocked? I had the Tor Browser installed on my computer which I could use to access GitHub and GitLab, but that virtual connection only worked inside the browser. I needed to have my entire system tunneled so that I could push and clone from GitHub through the git command line. I turned my mobile VPN on and took my frustrations to Twitter.

A friend of mine then sent me a link, which I used to download the VPN for Windows. I got the .exe setup downloaded on my phone, transferred it to my computer through Bluetooth, and run the installation. It worked. GitHub was working, everything was working fine. I have tried asking other people if they are able to access GitHub. Some are, but majority aren't. I thought it was an OS specific problem, but I was wrong. A friend of mine who runs Linux on his computer does not need the VPN to push to GitHub, but I think it could just be coincidence.

So now, the new order of things is:

boot computer
connect to the mobile hotspot
start VPN
get to work

This report by OONI shows network measurement data on the blocking of social media and circumvention platforms leading up to Uganda’s elections, as well as IODA data (and other public data sources) on the internet blackout that occurred amid and following the election. It provides a full account of all the sites that got blocked, when they did, and the various circumvention tools that could be employed to bypass the censorship.

I think it’s disappointing that our government sees the internet as a nuisance, and have very little regard for basic human rights. Internet costs in Uganda are already very high, considering the social media tax (OTT) on top of that. However, now that social media has been banned, OTT has been rendered ineffective. We do not know how long this social media ban is going to go on for, though word has it that it is indefinite. It could be permanent, they say. I asked a close friend who works with UCC why GitHub was being blocked, and he says that people would try to get updates and installations from GitHub (the same reason for blocking the app stores).

So the question that lingers in my mind is, if the government successfully blocks all VPNs, as well as YouTube and GitHub along with all the social media applications, what will happen to the jobs of all the Ugandan developers who work remotely, but most importantly, what will happen to my internship with Outreachy ??

About my Outreachy internship with Mixxx DJ: Week 8 progress

2021-01-24T12:09:00+01:00

This is the eighth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

Has been a little bit slow, to be honest. Internet speeds are much slower now because of all the Virtual Private connections that have now become the new normal.
I wrote a script for the In-depth video tutorial about the Mixxx communities; the forum on discourse, Zulip chat, Mixxx' social media platforms - Facebook and Twitter, filing a bug report in the Mixxx launchpad, and then finally how to contribute to any of the Mixxx projects on GitHub. Submitted it to my mentor, in case I needed to make any adjustments, which I did.
I was going through past articles on the Mixxx website when I came across this one about a minor website revamp and the creation of the current Mixxx website logo. I noticed that the link to Paul Bloch of Open Artist was broken so I opened an issue for this in the website repo here.
Next week, I will record the YouTube tutorial about the Mixxx communities, following the script that I wrote this week.
Following the article that I published this week about the current internet censorship situation in Uganda, I will be contributing to a section in the Outreachy internship guide that will help future interns who might find themselves in a similar situation, navigate internet censorship in their own countries. A draft pull request has been opened by Sage Sharp here.

So in addition to next week’s tasks, I will contributing to this pull request as well.

About my Outreachy internship with Mixxx DJ: Week 7 progress

2021-01-17T16:40:00+01:00

This is the seventh weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I created a YouTube channel for Mixxx tutorials and posted the first video. Its an installation tutorial for Windows OS. Here is the link to the YouTube video. This was early in the week.
Sadly, I did not get a lot done in this week, because our government (Uganda) decided to shut down the internet. We had no access to the web or any internet-based services for at least four days. The internet just got restored today (as I write, it's Monday of week 8) but social media is still blocked.
Since I did not finish accomplishing some of last week's tasks, I will work on those first then record the second YouTube tutorial. It will most likely be an in-depth video about mixing once the program is set up (following the first video).
I will be working on issue #335 as well. Finding a reasonable arrangement for the Record/ Broadcast your mix chapter.

About my Outreachy internship with Mixxx DJ: Week 6 progress

2021-01-12T10:05:00+01:00

This is the sixth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I got feedback for Pull request #337. I am required to arrange the descriptions in the order that the headphone and master mix controls appear in the screenshots (left>right). I asked for clarification on this task before I could tackle it, so I think this will be finished next week. In the meantime, I edited the description for channel faders and level meters and committed it.
I am still working out a proper arrangement for the Record/ Broadcast your mix chapter. issue #335 . This is still in the works, so, perhaps I will finalize this next week.
I wrote a script for the “How to download and Install Mixxx” video tutorial, as well as the sequence that I will be following. I haven’t gotten around to recording this yet (as I’m still planning), so this video will be done early next week once I’ve figured out exactly how to go about it.
I lost a day or two to really bad internet. Either that or the Ugandan government has already started limiting certain Google applications. This usually happens as we near the Presidential elections. Here is a recent article about this. Ugand orders all social media to be blocked . I couldn’t use Youtube (for research purposes) and at a certain point, I had no network bars completely.
So most of this week went into research and planning, stuff that didn't really require the internet.
Next week, I plan to record at least three video tutorials for the “Create video tutorials” project. This will be my main priority for this week.
I will open a pull request for issue #335 .
And if time allows, I will make at least one addition to the Cookbook, or at least start a different conversation about it.

About my Outreachy internship with Mixxx DJ: Mixxx to the first time contributor

2021-01-08T17:38:00+01:00

Before the Outreachy internship program, I had never contributed to open-source software. I didn’t know what open source software was (or how different it was from other software) until a friend explained it to me. Since made my first contribution to Mixxx, I have learned a lot about different open source software and the different ways that I can contribute. I thought it was rocket science (because of the term “open source”) but really, it’s not. I feel fortunate to have been offered the internship contributing to Mixxx, and now I can’t wait to share everything that I know about contributing to open-source software – Mixxx in particular.

Mixxx is a free/open source DJ performance software for Windows/Mac/and Linux. It supports effects, harmonic mixing, beat matching with thousands of users all over the world and it integrates the tools DJs need to perform creative live mixes with digital music files.

Mixxx was first released in 2003 as a graduate student project, and then it was picked up by the community and greatly enhanced. Mixxx has an unusually broad community that encompasses performing musicians, C++ programmers, amateur DJs, Internet radio broadcasters and even casual users. All contributors, from programmers to skin designers to translators are unpaid volunteers, hence it is entirely community driven.

Since Mixxx is completely free and also runs on older hardware, it is popular among people who want to try DJing or do not have the money to buy equipment or the latest fastest computers. Also, most commercial competitors will not create (good) fully featured DJing applications for Linux OS, perhaps because of its low desktop marketshare. It is also the only DJ software that one can fully customize to one's needs, since full access to the source code is always available. These, among many, are the reasons that set Mixxx apart from other DJing software. In essence, Mixxx plays a vital role in allowing anyone anywhere to throw a party.

I am contributing to Mixxx by improving their documentation (User manual). Mixxx’s user manual does a decent job of explaining the application, however, there is lots of room for improvement. Many users come to Mixxx without any prior experience DJing and are left wondering how to practically use the application to mix music. My job as an intern is to improve the manual by explaining not only how to set up Mixxx and how to use specific features, but also explain the bigger picture of how to play music with Mixxx. There is some information in the manual that is obvious or already explained in the application with tooltips but some of it may be deleted from the manual. Other text may be moved directly into the Mixxx GUI. One of my major tasks is to explain information that would take too many words to adequately explain in the Mixxx GUI. This also involves adding more links to specific sections of the manual from the Mixxx GUI (and edit the manual text with this context in mind).

This project is important because it will better the experience of many first time users of Mixxx. I had never used Mixxx before this internship and I think this turned out to be more of an advantage than a disadvantage. I say this because if I was using a software for the first time, I would need to refer to the user manual a lot, and one of the things that I appreciate as a first time user is when documentation writers make the effort to explain technical application-specific concepts to non-developers and first time users in the simplest way possible. Most long time users and developers of open source software might find difficulty doing this because they use these technical terms and apply these concepts every day in their work, therefore it comes easily to them. It might slip a pro user’s mind once in a while that some terms might not be well known to the ordinary user. So, as a newbie, I think that I am able to approach this project with fresh eyes and the perspective a first time user. Are the concepts understandable? Are they easily relatable to the Mixxx graphical user interface? What sections of the manual need more emphasis? Are the directions easy to follow? These are some of the questions that guide me as I work on this project.

Another Mixxx project that I am working on for this internship is the YouTube video tutorials project. Mixxx does not have enough updated video content on YouTube, and these videos are absolutely necessary for Mixxx’s documentation. In this project, I create illustrative videos to help Mixxx users understand how to use the software and thus, can be used by professional DJs, aspiring DJs, music lovers, and casual users. The project involves creating a series of short, brief videos for various playlists and they are mostly OBS Studio desktop recordings with voice-overs, coupled with some illustrative animations to keep the content fun and interesting.

One of the things that I love about working on these projects is that the tools that I work with (git, OBS Studio, Movavi video editor, VSCode) are easy to use. So I’m glad that I get to focus more on working on the actual tasks at hand, and not with the tools needed to get the tasks done (that happens sometimes 😊). I make edits in reStructuredText (.rst) for the manual and markdown (.md) for the website. I found these two lightweight languages easy to learn and work with, so I was happy to get over that learning curve in no time (I’m still learning though).

Another thing that I love about working on Mixxx’s “Improve User manual” and “Create Video Tutorials” projects is that I get to contribute to an open-source project that many people rely on. Some of the work that I do represents a solution to a problem that others may experience as well.

Through contributing to Mixxx, I have gained a much deeper understanding of the software. It was not easy in the beginning as I had to determine which part of the project was worth contributing to. Understanding the contribution guidelines also took me a day or two, and I made mistakes here and there, but that is all expected. It also took me a while to understand some of the issues that were opened in the manual repository on GitHub – determining where the problem was and why it was a problem, researching on the issue and then finally making the requested changes. Once you’ve gone through these steps, you will have gained a much deeper level of knowledge and understanding of the project at hand. Contributing to an open-source project, in the end, lets you reach a higher level of expertise. Something that cannot be easily achieved by simply reading books or using the project at hand.

Before I learned about Mixxx, I was experimenting with Virtual DJ but I didn’t use it often. I only knew the basics of loading a song on a deck, cueing, crossfading into another song, and beatmatching. (Man, I felt like a real DJ!) I knew enough to record a mix for my friends or get a high school party going, nothing too complicated 🙂

However, since I started working with Mixxx, I have learned a couple (understatement of the week) of new terms and concepts such as analyzing your tracks, the auto DJ feature (this is the coolest feature for me), microphone ducking (I always saw DJs do this, but I did not know that this was it was referred to), harmonic mixing, the difference between a crate and a playlist, kill switches among many other things.

When I first started contributing to Mixxx (during the contribution phase), I was fortunate enough to be in a community of really supportive people; developers, DJs, long time users of Mixxx, among others. I learned how to get started on making a contribution by following the community chats in the different streams. We (first-time contributors) all had the same questions. “What next after cloning the manual repo?” “Which branches should we be creating ours off of?” “Do you simply start working on an issue, or should you ask to have one assigned to you?” I remember asking why the bugs reported in the launchpad didn’t have documentation labels. 😌 Lol.

Starting out can be confusing, so, based on my experience so far, here are a few key suggestions that I would make to a first-time contributor of the “Improve User Manual” project or any other project:

If you ever get lost on how to start, try not to feel overwhelmed because you are not alone. You can always ask in the community Zulip chat, how to get started or even what tools you would need. But before you do so, I would suggest that you first read the README.md in the repository of Mixxx’s User Manual or the respective project that you’re working on. It has well-written guidelines on how to get started, prerequisites for the installation of some of the tools you will need, how to build your project and view it before you can commit it, how to troubleshoot in case you run into an issue, and so much more! In addition, there are high chances that what you want to ask in the community chat has already been asked in a previous conversation in the stream, so going through these messages can be helpful for you, especially if you’re shy. 🙂
Try to understand the working of Mixxx. Experiment with it. Learn about the different features and how they work, and how you can manipulate them to make good mixes. You don’t need to be a DJ to do this – the purpose for this is so that you understand better the project that you’re working on. It only makes sense that if you’re documenting a feature, let’s say microphone ducking, that you have Mixxx installed on your computer and that you have used microphone ducking before. I believe that doing this will give your work more context, and things will go smoother.
Take note of the git tree structure. While working inside any branch in the repositories, make sure to understand the git tree for that repository so as to avoid running into git errors and then spending a lot of time correcting them. I forgot to do this once, and I all I can say is, I have never been frustrated about git in my life. I had to open a whole new pull request in the end. I wrote about this in my blog about struggles. (you can check it out 🙂 )
Research on the issue you want to work on before you start working on it. This will help you understand what exactly you need to do and how to go about it. Some times the issues may not have enough detail in the description or the description may be too technical for you. Google is your best friend. I mean it. Leave no stone unturned by the time you start working on that issue! By doing this, you will find that you will have less commits as well (this is a good thing). It means that you understood what exactly needed to be done and did it.
Build the manual to see your changes, before you commit your work upstream. I think this is important to note because it helps keep your branch clean with fewer errors and less commits. I believe maintainers love working with clean code because it makes their work easier (remember that they maintain a lot of code already). So with an organised git commit history, I believe you’re more likely to get a review on your work faster because you’ve made the reviewers’ and mentors’ work easier. You might be tempted to depend on the Netlify deploy previews to preview your changes but that means you would have to commit every minor correction that you’re making and that could potentially make your pull requests messy.
Last but not least, your mentors are here for you. Do not hesitate to ask when you feel stuck. If you need more clarification, ask. Its okay to ask the same question twice because what’s important is that you understand and learn. Even better, ask your questions in the community streams. Leave it open so that you can receive different suggestions from various community members. It might open your mind up to new approaches to solving your problem. On the other hand, I am also [very] happy to help in case you have a question about this project or my experience in the internship. You can reach me on email at deborahtrez12@gmail.com or even in the community Zulip chat at @Aanyu Deborah Oduman. I would be happy to hear from you!

That said, good luck with your first contribution, and happy documenting! 🙂

About my Outreachy internship with Mixxx DJ: Week 5 progress

2021-01-04T09:00:00+01:00

This is the fifth weekly progress report of my Outreachy internship with Mixxx DJ.

This week:

I finished working on moving “deck cloning” to the cookbook chapter BUT this pull request raised the question about how it differs from the “DJing with Mixxx” chapter. It seems that there is sufficient overlap to merge the two….
I also finally finished moving all my past Outreachy blog posts to the website repo.
I couldn’t go ahead with moving “DJing with Mixxx” to the cookbook because I have to first figure out how the two chapters differ, and thus make the content differentiable. In any case, one of this week’s tasks is to clean up this same chapter. There is a lot of stuff mentioned in it and I received suggestions from some of the contributors to look at it with the eyes of a beginner. In other words, after the introduction, what are the most important aspects the manual should mention first, besides pointing to Preferences > Recording? What topics are most requested for by users? Can the sub-topics be re-ordered in that format?
I also helped finish up a pull request opened up by one of the applicants from the Outreachy contribution phase. It hadn’t been worked on in a long time and I thought I would help. It was about finding a reasonable order for chapters in 3.2. The Mixer Section. This pull request is yet to be reviewed. While working on this PR, I learned that even though you want to make a correction as little as a spelling mistake, you can’t push to other people’s repositories without them giving you write permission to their repo. 😊
Finally, I worked on issue #320 – Adding Screenshot of FX routing to effects documentation. The effect routing buttons are easy to overlook so I added a screenshot of the effect unit buttons located in the deck section of the skin to the manual, to make it more obvious. Here is a forum thread where a user overlooked the FX routing buttons: Effect rack 1 doesn't work for deck 1 . I opened a pull request for this here.
This week I will focus on working on the two chapters “DJing with Mixxx” and the “Cookbook”. The cookbook is my major internship project – so I think this will be a constant for the entire internship 😄. I will pick up on another open issue to work on as well, and then record a video tutorial – for real this time.

About my Outreachy internship with Mixxx DJ: Week 4 progress

2020-12-29T23:55:00+01:00

This is the fourth of many weekly progress reports that I will be publishing for the duration of my Outreachy internship with Mixxx DJ.

This week:

Last week, I mentioned that I was working on the cookbook chapter. I opened a GitHub issue for it here. I moved documentation about deck cloning that I found in this article to a new chapter of the manual that I called the cookbook. I opened a pull request for it here . I still have a couple of requested changes to make on it before it can get merged. I’m thinking that will be this week.
I also mentioned in my previous blog post that I would be moving all my blog posts about my internship experience with Outreachy to the Mixxx website repository. I did that too. I opened a pull request for that here. Just like the first, I still have a lot of changes to make (as requested) before it can get merged. I’m happy that I get to contribute to not just the Mixxx manual, but the website as well.☺
Christmas day was on Friday. So I took some time off to spend with family from the 25th – 27th. I didn’t do a lot of work on these two and half days.
This week, I plan to finish up on the above two pull requests. And then move onto moving the chapter “DJing with Mixxx” to the cookbook.I planned to do this last week, but I didn’t get around to doing so.. This task will be moved to this week.
I also plan to get/ create more content that I can add to the cookbook chapter…
…and then pick an open GitHub issue that I can work on this week.
I am not making Mixxx video tutorials as often as I hoped to. I think it’s because I am spending more time improving the Mixxx manual and contributing to the website repo – which is also okay. But this week, I should try to deliver on those promises that I made about making better Getting Started videos.

About my Outreachy internship with Mixxx DJ: Week 3 progress

2020-12-23T08:09:00+01:00

This is the third of many weekly progress reports that I will be publishing for the duration of my Outreachy internship with Mixxx DJ.

This week:

I made a pull request #327 in response to this issue . I moved the standard effects mapping documentation to section 11.5 of the manual.
Currently working on the cookbook chapter. I am moving documentation about deck cloning that I found in this article to a new chapter of the manual that I am calling the cookbook. I will then move onto moving the chapter “DJing with Mixxx” to the cookbook as well.
This week, I plan to move all my blog posts about my internship with Outreachy to the Mixxx website repository, and then if time allows, I will record another video tutorial about Mixxx DJ.
I also plan to work on this GitHub issue and make a PR for it this week.
I lost a couple of days to non-Mixxx related tasks. I had a slack week in general, in between finishing with University, submitting my project, moving out of my room, and then travelling home for the holidays – among other things. Because of this, I was not able to achieve all that I had planned to do this week. (see Week 2 – progress report). However, I do plan make up for it this week, and at the end of the (official) internship period.😉

Improving our Website

2020-12-15T13:21:32+01:00

Our website is now based on the Pelican instead of the Cactus static site generator. It supports blog posts natively and also supports pagination, archives, author pages and taxonomies likes categories and tags. If you want to browse older news articles, using Pelican will make our website more easy to use.

This also means that contributors that want to improve our website don't need a Python 2.7 installation anymore (Python 2 has reached end-of-life since the beginning of the year).

There are already some ideas to modernize the look of our website, and with Pelican we'll have a more solid basis for that. Join the discussion Zulip if you want to get involved!

SCons build system dropped in favor of CMake

2020-12-14T14:07:57+01:00

If you wanted to compile a recent version of Mixxx 2.3 beta or 2.4 yourself, you may have already noticed that we removed our old and rusty SCons setup in favor of CMake.

A few months ago we said that we were planning to ship Mixxx 2.3 with both SCons and CMake configurations (the latter would be considered "experimental"). However, that turned out to be impractical.

All of core developers started using CMake as their primary build system since initial support for it was added more than a year ago. Our build servers that we use to compile and test Mixxx during development have also been switched to CMake. That means that the SCons build received a lot less testing compared to the CMake build.

Due to the maintenance burden of keeping an additional build system and some problems with our SCons configuration that popped up recently, we decided to remove SCons and use CMake exclusively for the upcoming 2.3 release. That should free some resources and will allow us to work on more important issues than keeping our SCons build alive.

About my Outreachy internship with Mixxx DJ: Week 2 progress

2020-12-14T13:40:00+01:00

This is the second of many weekly progress reports that I will be publishing for the duration of my Outreachy internship with Mixxx DJ.

This week:

I made a pull request #322 in response to issue #157. I added missing documentation about importing rekordbox libraries from rekordbox prepared devices into Mixxx. This is still in review.
I made my first YouTube Mixxx tutorial titled “Getting Started”. I posted the video in the chat, and got feedback from some of the other contributors. I plan to record another video, and make some adjustments this time (based on the feedback that I got from the first.)
Currently working on issue #289 – which is moving the Standard effects mapping documentation to the manual.
I lost a day of work to correcting git errors while making the pull request #322.
I lost a day or two as well to re-recording the video tutorial and editing. I had recorded my voice and my computer screen at the same time, but that wasn’t working out too well. I later on decided to record my screen and voice separately and then merge the two in the final video.
So this week, I plan to make another recording for “Getting Started with Mixxx DJ” with the suggested edits and then make a PR for issue #289 and issue #320. I will also finalize the list of recipes to publish for the cookbook.

About my Outreachy internship with Mixxx DJ: Struggles

2020-12-06T18:10:00+01:00

I thought i knew git until this day - struggles

I hate feeling stuck. Staring at your screen blankly, at the verge of ripping your hair out because you have exhausted all the possible solutions and none of them has worked.

It makes me second guess myself, what I know, how I got here, the education that I got and all of the things that have led me to this career path. I have been in this position many times before and yet each time, the feelings of self-doubt are as fresh as the first time that I encountered a bug in my code (it was HTML by the way). I was in this position last week, and I have to admit, its not a good feeling.

It’s not that I did not know how to approach the task at hand. I did, but perhaps, git had other plans that day. So what happened is that I hadn’t pulled the latest changes from the upstream branch in a very long time and by then, a lot had changed; the branches had been renamed (from manual-2.3.x to just 2.3, and manual-2.2.x to 2.2, and so on), new sections and content had been added by some of the Outreachy applicants during the contribution phase.

I needed my work to be updated I did the usual git pull and I thought everything was fine. I usually never break a sweat when working with version control because I have been using git for the longest time – I think it’s coming to four years now. I created another branch from the manual-2.3.x branch (remember it had been renamed) and I started working. I finished making edits, committed, pushed and sat back as my code got tested on GitHub. My problems began when my code failed all of the checks on GitHub. In my head, I was like, “Wait, what?”. I was shocked because my code wasn’t even passing the basic RST syntax check. I began to panic. I got the feeling that I had not pulled the latest work from the upstream even though I had run “git pull”. Maybe I did, but perhaps I didn’t do it the right way. So many thoughts were running through my mind at this moment.

Panicked, I began to run a myriad of Git commands.

In doing so, I was required to fix merge conflicts. Now we all know how badly this can go. You could easily push outdated work and set everybody ten steps back. Or you could easily commit completely wrong work – work that has been deleted or moved. I tried to avoid fixing merge conflicts as much as I could, but in trying to do so, I made things worse, and I was not making any progress. When I finally got the guts to fix the merge conflicts, my commits were actively trying to disorganise progress in the upstream. Git revert wasn’t even enough to reverse the mess that I had pushed.

Aimen Batool was right. It hurts when you don’t know how to resolve merge conflicts. You spend hours finding the solution to a problem and then you end up losing your code in an attempt to fix the merge conflict.

I looked for solutions from Stack Overflow, freeCodeCamp blogs, Medium blogs, closed GitHub issues, and run them in my command line but none of them was working for me. I got to a point where Google kept returning me the same search results, the same Stack Overflow solutions and that’s when I realised I was going in circles. I was not achieving anything. I thought that I had missed something the first time, so the second time (and many after that) I would squint at my screen looking through the same solutions with a more critical eye but nothing! I checked the code of the branch into which I was trying to merge on GitHub, and compared it with mine. I realised that the work in my repo was quite outdated and for some reason, my local repo was refusing to sync with the upstream.

By this time, I had run too many git commands in my git bash, therefore, in this process of trial and error, I couldn’t tell what had or hadn’t changed in my repo. I had spent over nine hours on the internet searching for solutions and suggestions by people who had come across a similar issue. I was tired, discouraged and all out of options. I heavily pondered on whether I should just come out and ask some of the contributors from the Mixxx community for help. For lack of a better option, this is exactly what I did. I explained the errors that I was getting and how I got there. They understood what the problem was and guided me on what to do. One of the things they told me to do was rebase on my branch, so I thought “okay….”. I had never rebased on a branch before so I looked up what it meant. I read a blog about it and after I had understood the concept, I told myself, I got it. I got it. I ran a couple of other git commands and things looked like they would work out after all. I was happy. And then….

I got to building. sphinx-build generates documentation from the files in sourcedir and places it in the outputdir. It will create documentation in different formats whereby a format is selected by specifying the builder name on the command line – the default is HTML. So when I ran this command, I got extension errors. Could not import extension xxx (exception: No module named 'xxx')

I reached out again about this error and one of the contributors suggested that I install some build dependencies and build inside a python virtual environment. Again, huge relief! I do everything as told and then build. At this point, I’m pretty confident that things will work out this time.

The darned extension errors came back again. At this point, I just wanted to crawl under a blanket and scream. I am thinking “What is everyone going to think if I go back and ask about yet ANOTHER error?” “What if they think that I’m not good enough?” “What if they finally see me for the fraud that I am?” (not that I am a fraud) “What if they start to wonder how I even landed this internship?” “What if my mentors get tired of my endless questions?” “What if the questions never end?”

As hard as it was, I forced myself to ignore all these fears and just asked. Again. By then, this conversation with my mentors was happening under a GitHub issue and the thread had gotten too long. One of them then suggests that I should open a new topic in the community development help stream on Zulip so that the discussion on GitHub didn’t go too off-topic. So I move the discussion there and the community starts helping me debug. In my heart, I knew that nobody in the community would think less of me for asking about an error because, well, this is part of the reason for why the community exists in the first place – to help fellow Mixxx users find solutions to the various problems they are facing while using Mixxx. Even with this knowledge in mind, I was scared and felt small.

So the discussion in the community forum is going on very well, and I’m getting replies in not more than 10 seconds. I was pleasantly surprised by the community’s willingness to help with this (little) error. And then just as I was getting comfortable, one of the community members suggested that I run pip install sphinxcontrib-svg2pdfconverter. I was thinking “It can’t be that easy” when I got returned Successfully installed sphinxcontrib-svg2pdfconverter-1.1.0 . So I ran sphinx build one more time and it was successful! I couldn’t believe it took them all of two seconds (okay not two seconds, but it was really short time) to know exactly what was wrong with my code and provide me with the correct solution. It worked! I laughed.

I laughed at how simple the solution was even though I never would have guessed that that was it all along. I laughed at how long it took me to get here (it was a little over 9 hours) – to finally get the guts to ask somebody for help. I laughed because if I had just asked for help the minute I got stuck, who knows how many GitHub pull requests I would have created by now (not that many, but still…). I just laughed and shook my head. All my inhibitions seemed silly now, like, what did I think would happen, spontaneous combustion from embarrassment?!

So, moving on, I was able to build and preview my work before committing and everything looked good. I went ahead and created a pull request for this issue, feeling relief to my toes. I watch as the tests on Github run my code and then my heart dropped.

Again?! These errors just keep on giving, huh? This time I wasn’t going to panic. I told myself that I had been given all the resources that I needed to solve this, and if all failed, I would not waste time. I would reach out to somebody for help.

I decided to start afresh, on a completely new page. I created a new branch, made another pull request for the same issue, this time paying extra attention to the branch tree. Everything went smoothly and the checks passed (except for one) but I had been told before that that particular test was nothing to worry about. The joy!

Lessons learned

So through this experience, I was able to learn new concepts in git merging, committing, rebasing, and resolving merge conflicts. But besides that, here are a few key things that this experience has taught me.

Firstly, we have to learn to ask for help when we need it, even when it seems like the hardest thing to do. Despite what you think people will think about you when you ask for help, the fact is, asking for help will get you to where you want in way less time than repeatedly trying the same solutions that aren’t working or remaining seated and feeling dejected. We have to be humble enough to acknowledge that indeed things aren’t working and then make the effort to try to reach out to somebody for help.

Secondly, it’s always good to ask for help but before you do, please, do your research.

Try to ensure that you have exhausted all the resources at your disposal so that by the time you ask, you are better informed about all the alternative methods you could have used, but didn’t for justifiable reasons. You will not feel completely clueless when asked if you’ve tried a certain solution because you know that you tried it, and it didn’t work or that if you had tried it, it wouldn’t work for reasons A, B, C and D. I believe mentors feel more enthusiastic about providing help if they see that the intern has put in the effort to look for a solution to the problem and they did it exhaustively. But then again, don't research for 9 hours😉.

Thirdly. In Syeda Aimen Batool’s words (who also got the suggestion from Sarah), “Do not take things personally and focus on learning”. I read this in his article just the other day and I feel like this piece of advice resonated with me. He said that it can be hard to not take things personally and feel insulted when a senior dev or mentor makes a correction or suggestion. It’s even harder when you’re working in open source and it’s in a public platform. The most important thing is to focus on the main points and have a learning attitude. We won’t be able to learn new concepts and good coding practices unless we put all our ego aside and focus on learning from the experience and knowledge of others.

And finally, it’s important to remember that everybody struggles. Every pro dev started somewhere. They all faced some pretty difficult bugs and blockers but this is exactly how they became the senior developers that they are today. It’s all part of the journey. Once we understand that it is completely normal to get stuck, then we can normalize asking for help when we need it.

About my Outreachy internship with Mixxx DJ: Week 1 progress

2020-12-06T18:10:00+01:00

This is the first of many weekly progress reports that I will be publishing for the duration of my Outreachy internship with Mixxx DJ.

This week:

I submitted pull request #313 in response to this issue. I added the base commands for each platform (MacOS, Windows and Linux) onto the which the command-line options can be appended.
Currently working on issue #157 – which is documenting the Rekordbox library import. I had run into a slight problem with pulling the latest changes made by some of the outreachy applicants during the contribution phase. Luckily, some of the contributors from the Mixxx community helped me figure it out. It took me longer than I expected but I hope to have made a PR for this issue by the end of today.
I have also been working on my first video tutorial on “Getting started with Mixxx”. The plan is to make it then share the link in the chat so that I can get feedback, before I make the final. This is my first time making a YouTube tutorial, so it’s taking me a little bit of time. I wanted to record my voice as I made the tutorial but I faced some difficulty doing both at the same time (focusing on the script and my actions at the same time). So I have decided to try making the video first, then recording my voice in the video after.
Lost a day of work (maybe two) to the last two issues.
I’m thinking of a proper way to start working on the cookbook. I will need to consult on this – whether it should be in GitHub pages, a GitHub repo with *.rst files (like the manual) or….. a simple website or…. something else.

About my Outreachy internship with Mixxx DJ: Intro

2020-12-01T23:15:00+01:00

In October, Mixxx announced that it had been accepted into the Outreachy program. This program provides a three-month internship to work in Free and Open Source Software (FOSS) and I was selected as the first contributor! I will work mainly on improving the Mixxx manual while making video tutorials teaching users how to use Mixxx. While I do so, I will document my journey and work in a series of posts here on the website.

A little bit about me.

My name is Deborah Aanyu, from Uganda. I am 23 years old. I come from a family of five children – I am the eldest. I have been in Catholic (single sex) school for most of my education, and it was during this time that I got to appreciate the beauty of God in the world, and in my life. I was in mixed school for only two years, up until University. As an adventurous person, I like to try out a lot of things; from art and painting, to singing, writing, sports (basketball), web development, among other things.

I am generally optimistic and believe the good in people. I like to read and write. I like to dream, talk, listen and see the sunrise in the morning. I like to see the moonlight at night and feel the rain on my face. I like flowers. I like delicious food and comfortable shoes. I like warm clothes and a nice cup of tea. I also love babies, nature and laughter. I love food and listening to music.

I have been studying a Computer Engineering degree at Makerere University, Kampala for the last four years, and I finished my final examinations just recently. So I’ve been really excited about getting done with school and having the time to focus on what I really want to do which is software development and contributing to Open source!!

I will be working on improving Mixxx's user manual for the Outreachy Internship. Mixxx DJ is an Open Source application for DJs that gives them the power to mix songs for free. Each day that I wake up, I am so grateful for the opportunities that I am given, and looking at how I got here, I can’t help but feel enthusiastic for the journey ahead! I’m here for all of it.

I would love to travel and see the world someday, meet new people and make new friendships. There are many things that I would love to do, see, and experience. I am also working towards attaining seniority level with web development (particularly with JavaScript) and just the MERN stack (MongoDB, Express, React and Node.js) in general. (Let’s give it one more year) I aspire to be successful at everything that I do so that I can share my journey and use my experience to inspire other people, especially women. I am passionate about women empowerment and would love to see more women leaders in the technology sector.

My top three core values

Honesty

As a young teen, I was very shy – bordering on fearful. I feared everybody including my own parents. I feared to do the wrong thing because I wanted to be in everybody’s good books. I needed the approval of my friends, family and everybody who cared about me. Because of this, I was telling lies all the time. I was turning into a diabolical liar.

I didn’t even lie because I had anything to hide. I lied so that I could tell only the best version of events. I lied to avoid attracting too much attention to myself. I lied to make people happy. I lied because I was fearful of the consequences, even if my actions were not wrong.

Eventually, I got caught. I saw how my lies were affecting the people around me and my father asked, “why do you lie so much?” and I had no real reason, except for my low self esteem. So it wouldn’t be enough to just stop lying (if it was that easy), but I had to work on my self-image, how I felt about about myself in relation to the people around me. One of the hardest things I had to practice at the time, was telling the hard truth, however terrible I thought it was. I discovered that people would rather be told the harsh, disappointing, heart-wrenching (lol) truth, than be deceived with words you think they would rather hear. I found that I would rather deal with the immediate, but brief disappointment that comes with telling the truth, as opposed to the hurtful or pained expressions on their faces when they found out about the lie. I practiced this everyday, even though some days were harder than others, but it got easy. Eventually, the truth became the easier, most obvious option. I didn’t have to think twice about it anymore and concoct stories. A huge burden is lifted off my shoulders every time I tell the truth in a difficult situation, because I know it would probably be easier to lie. I did not lie, and the world didn’t cave in.

It is because of this phase in my life that I appreciate honesty so much more. I appreciate it more because I know sometimes the truth can be very difficult, and it is not always easy to say. I appreciate honesty because it comes with no burden, and it leaves you free from guilt – of hurting others or causing even more damage. I value honesty because I have seen first hand how badly it can affect relationships with loved ones, how it can end a marriage and a life long friendship. Honesty is a core value for me because it has saved me from a lot of things and I can only imagine how my life would have been if I had been transparent from the start.

Respect

Respect has been a core value in my family for ages. Sometimes it is easy to take what we have for granted and forget that there are people who do not have half as much. We make friends, and build relationships with people from different backgrounds with different stories. Along the way, we get to peek into other people’s worlds and see how things are done there. It can be easy to judge other people for the way they do certain things just because they do them differently than what you’re used to. And often times, this judgement can reflect in our actions and facial expressions, which might not be very respectful.

I believe that part of respecting other people in society is believing that we were all created differently and there is no singular way to get anything done. I also believe that however learned we might be, there is always a thing or two we can learn from the people that we meet everyday. When we respect people, then we might be humble enough to learn from their experiences and add to ourselves one way or another. We all have different personalities, beliefs and values. We don’t always have to understand other people’s routines, cultures, beliefs and likes, but we can learn to accept that they are different than what our brains have accepted as the norm and that is okay. We are all human, we bleed the same, and we shall cease to exist some day. We all have that in common.

Adventure

I truly believe everybody deserves to make the most of their time on earth! We only get one life, so don’t waste it. Try new things, go to new places and meet new people! Adventure can be applied to every aspect of our lives, from the food we eat, to the clothes we wear, to the music we listen to it. You don’t need much to try something new – just an open mind! However, I respect that some people might prefer to have a routine and live by it every single day. When we are willing to get out of our comfort zone and try something new, we learn a little bit more about ourselves. If you try chocolate ice cream for the first time and you don’t like it, then at least you know for sure that you don’t like it! You’ve learned something new about yourself!

With an adventurous mindset, we become open to learning new things. We are more willing to gain new information and accept that there could be better out there in the world. We open our minds to new knowledge and become more willing to adjust to new changes and environments. Adaptability becomes ingrained in us.

My motivation for applying to Outreachy

So my friend Jordan Rob, and I, are self-taught developers. Everything we know, we got off Stack Overflow or YouTube (lol). We have shared a number difficulties in trying to be better developers with each passing day. With this in common, we promised to always lift each other up and encourage each other to take up new opportunities. We promised that we would not get comfortable and we would always strive to get better at what we do.

So on a random day in August, Jordan tagged me in this tweet and said “let’s apply”. And I replied “kawa” meaning ‘okay okay’.

I replied rather casually after finding out how competitive the application process was. I think Jordan and I thought the same thing. “Do we even stand a chance?”

What Jordan and I have in common is that we are both passionate about software development and if we come across any opportunities for growth in the tech sector, we will always look into them. Jordan and I have had similar struggles both personally and professionally, and hence we kind of look out for each other in this particular field.

However, one of my setbacks was that I had a slight case of the imposter syndrome (a psychological pattern in which an individual doubts their skills, talents or accomplishments and has a persistent internalized fear of being exposed as a “fraud”). I was constantly thinking to myself that I needed to be a little bit better before applying for any job or internship. And so I found myself stuck in a cycle of tutorials, learning more and more and never really using the knowledge to contribute to any real life applications.

Before the start of this year, I did not know the meaning of ‘Open Source’. I had always thought that it was a fancy term for very-hard-to-code software. I had googled the term before, but the search results always brought up some blog posts (that I found quite intimidating) about “How to get started on your first contribution”, that I could not really relate with. So my friend Jordan Rob tags me, and I ask rather sternly what Open Source is really all about. And he breaks it down for me bit by bit.

Once I discovered that I could contribute to software applications that people use everyday, in a major way, my excitement grew! I did some research and found that I, too, could contribute to repositories of some of the most common and widely used software applications. I was happy because my fraudulent feeling was wrong! I didn’t have to be an absolute pro at code to contribute because there were other significant ways that I could do so! Through documentation, graphics and editing, video making, audio recording among several other ways. So when the Outreachy internship opportunity came along, I grabbed it with both hands!

But my motivation for applying for the Outreachy internship does not end here. I had always yearned for a chance to work on a project that I was really passionate about together with a group of really talented developers from whom I could learn a lot and come out of there several times better than I started. I have a strong will to gain technical expertise and use the knowledge to make people’s lives better. I was motivated by the thought that if I actively contributed to an open source project that people actively used, I would benefit from the transparency of collaboration and would be able to evaluate the risks associated with required features or bug fixes more precisely. Moreover, I could actively shape the roadmap (by contributing) or at least influence its prioritization. How cool is that?!

New in 2.3: Deck Cloning

2020-11-15T13:36:00+01:00

Deck cloning (also called "instant doubles" in some other DJ software) is a highly anticipated feature added in Mixxx 2.3. In short, it does what it says on the tin. When activated, the currently loaded song, playback state, pitch adjustment, and any playing loop will be cloned from one deck to another. This opens up a number of creative mixing possibilities, some of which we will explore below.

How Do I Use Deck Cloning?

Deck cloning can be triggered several different ways:

Double press the Load button on your controller, mixer, or keyboard (this can be disabled in the Decks page of the preferences)
Invoke the CloneFromDeck control in a controller mapping (see the complete Mixxx controls table)
Drag and drop a track from one deck to another in the UI

Any of these actions will result in the currently loaded track being loaded on the target deck at the current play position and pitch setting. If the track is playing on the source deck, it will play from the same exact position on the target deck.

What Can I Do With Deck Cloning?

The deck clone feature enables many unique and creative possibilities. Let's dive into a few of them.

Playing With a Single Turntable

Typically, in a DJ setup, you have two decks and a mixer, but with the deck clone feature, it's possible to play with a single deck. Cue, beatmatch, and mix in the next track on a single deck. Once the track is mixed in, swap it to another channel using the deck clone feature, freeing up your single deck for the next track. This is useful if you are building out a DVS setup, but you only have one turntable so far or if you need to play with a minimal setup. For example, you may not have enough space for two decks or you might want to reduce the amount of gear you have to lug around. Finally, this method can be used as a backup way to keep playing if one of your turntables malfunctions.

Beat Juggling

Beat juggling is a technique in which a DJ creates various loops and patterns by playing the same track on two decks. In its simplest, four or eight bars of a track are played on one deck (typically a drum-only break), while on the other deck, the same track is cued up to the start of the same section. When the desired section ends on the first deck, the second deck is started and the crossfader is switched to play that deck. This process can be repeated as many times as desired, back and forth between the two decks, playing a tidy drum loop.

Historically, this technique required two copies of the same record, but using the deck clone feature, the currently playing track can quickly be cued on a second deck in the right spot at the correct tempo. In modern times, with digital DJ setups, many beat jugging techniques can be done on a single deck using loops and hotcues. Still, when done using traditional methods, beat juggling is creative and impressive.

Put Your Best Hand Forward

Often, DJs and turntablists can only perform certain complex scratches with one hand or the other. The deck clone feature makes it easy to quickly swap which deck a song is playing on, enabling a performer to use whichever hand they prefer for scratching.

Doubles, Follows, and Chases

In this technique, the same track is played on two decks, but on the second deck, the track is played 1/2 a beat ahead or behind. The crossfader is used to strategically switch between the two decks, creating a delay effect. This can be executed using a deck clone followed by a beat jump of 1/2 a beat on the second track (or manually nudging the track so it ends up half a beat ahead or behind).

Current Track Preview

While playing a track, sometimes it can be useful to preview an upcoming section of the song. This can be done using the deck clone feature by cloning the playing track to the another deck, seeking ahead, and listening via the cue output in your headphones.

The examples here are just scratching the surface. There are many creative possibilities that the deck clone feature enables. This feature is included in Mixxx 2.3. Download the beta and play around with it today.

New in 2.3: Colorize your Tracks!

2020-10-24T12:00:00+02:00

As a DJ your most important job is to find and cue the track you're going to play next to make the crowd go wild. In Mixxx 2.2 you already had plenty of options to organize and add information to the tracks in your library to make this task easier. You can add them to playlists, put them into crates and access them as files in different directories via the "Computer" sidebar entry. It's also possible to order your tracks by key or BPM to find a match for the currently playing track.

For the next Mixxx version, we added another feature that helps you picking the next track to play at a glance: It's now possible to assign an individual color to each track. The track color is shown in a dedicated "Color" column in the library view. You can sort tracks by color by clicking on the respective header section like with any other column. To make it easier quickly grasp a track's color Mixxx also uses it to paint the background of the whole table row when the column is hidden.

Once you load a track into a deck, the track color is indicated on the deck itself. You can also change the color using the new track menu by right-clicking on the deck:

How you use track colors is up to you: You could assign the similar colors to tracks with the same key, BPM or generally mix well together. Another option is to colorize the tracks by energy or mood.

Are you doing live mashups and elaborate sampling? You can also use color coding to group tracks with fitting acapellas and samples.

Or you use it for keeping your library clean: Highlight tracks that you still need to prepare hotcues for or that need beatgrid adjustments. You can also mark tracks that have bad sound quality and you're planning to replace later.

Of course we also included controller support: Like we did for hotcue colors, we added controls to access and modify the track color in controller mappings. This means that if you're a mapping creator, you can now add support for displaying and modifying track colors from the your controller!

Stay tuned for more cool features in Mixxx 2.3 that we'll publish prior to the final release!

Mixxx Accepted to Outreachy. Please Donate!

2020-10-01T09:00:00+02:00

US Dollar donations	Euro donations

Realizing a More Diverse Community.

Mixxx is proud to announce that we have been officially accepted into the Outreachy program and are immediately raising funds to sponsor our first Intern for the December 2020 cycle! We first announced our intention to join with Outreachy back in June, and we're excited that our plan is coming to fruition.

Outreachy provides three-month internships to work in Free and Open Source Software (FOSS). Outreachy internship projects may include programming, user experience, documentation, illustration and graphical design, or data science. Interns often find employment after their internship with Outreachy sponsors or in jobs that use the skills they learned during their internship.

Outreachy expressly invites women (both cis and trans), trans men, and genderqueer people to apply. We also expressly invite applications from residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. Anyone who faces under-representation, systematic bias, or discrimination in the technology industry of their country is invited to apply.

More details and eligibility criteria can be found on the Outreachy website

Applications are open!

Internship Funding

Because Mixxx is an all-volunteer community, we don't yet have the funds we need to sponsor our first intern.

That's where you come in!

Our users have told us they want to give back, even though Mixxx is and always will be free. This is your chance to show your love for Mixxx. We've set up a fundraiser on OpenCollective so you can help Mixxx expand its contributor base and become a more vibrant, sustainable project. You can make a one-time donation, or you can set up a monthly contribution too. Our first goal is to sponsor our new Intern, and if we raise more than we need, we'll try to sponsor more than one.

Even though Mixxx is free, please be aware that collecting money isn't. Between payment processing fees and fundraiser hosting fees, the amount collected by Mixxx won't be as much as you pledged. If you're able to add a few dollars to help defray those costs, we'd greatly appreciate it.

We have two ways to give: OpenCollective is set up to receive donations in dollars, and we also have a GoFundMe to receive donations in Euros. Please use whichever you wish!

OpenCollective

For now, the most efficient way to donate from the U.S. is with a direct bank transfer through OpenCollective. If you're not comfortable giving your bank account information, you can use credit cards or paypal. With PayPal and credit card processing, extra fees are charged from the donated money. You can click on your donation to see how the exact fees were calculated, but generally there will be 10% deducted to pay for our fundraiser host and bank handling. PayPal may add a 5% fee on top of the donated amount if currency conversion is required. We have vetted these organizations and they are providing a great service to open source projects like ours, so we are confident that this portion of the money is going to a good place. We are working with OpenCollective on reducing these overhead costs for future fundraisers.

GoFundMe

GoFundMe's fees are optional, so it may be a better option for those who want to donate with Euros. This GoFundMe will only exist for the duration of this fundraiser, whereas OpenCollective will be a persistent platform for giving to Mixxx, and supports recurring donations.

US Dollar donations	Euro donations

New in 2.3: Color your Hotcues

2020-08-25T12:00:00+02:00

Hotcues are a neat thing and one of the major benefits of digital DJing. On analogue vinyl decks, you had had to put stickers to mark the different sections of a song and physically pick up, move and drop the needle to move to it. With the move to digital DJ setups, a new way to navigate tracks emerged: Hotcues now allow you to "bookmark" different spots in a track and quickly move to these positions in the blink of an eye, even while track is playing on the PA.

Mixxx has supported them for more than 10 years now: Initial support for numbered hotcues has been added in 2009.

However, it can be challenging to remember the correct number in the heat of the moment. Accidentally pressing the wrong hotcue pad is not something you or your audience want to hear.

Better Hotcue Labels

In 2015, support for hotcue labels was added to mitigate this problem. These can be arbitrary text that is shown on the waveforms. However, these were only shown on the scrolling waveforms, so you could not see them unless the track was close to that position. Also, it was cumbersome to edit labels because this was buried in the track Properties dialog that was only accessible from the library.

In Mixxx 2.3, we overhauled the way you can interact with hotcues using the mouse: It's now possible to see the labels on the overview waveforms. You can edit them directly from the waveform by right clicking.

If you have long, descriptive labels on hotcues that are close together, Mixxx will elide the labels so they don't overlap. You can still see the full label by hovering your mouse over an elided label. Mixxx will hide any other labels this would be drawn over so the text is legible.

Color your Hotcues

But Mixxx 2.3 has yet another next major improvement for hotcues in the pipeline: Hotcues can now have individual colors to make them visually distinguishable.

How you color code your hotcues is up to you - one example would be to set red cues 16 beats before the drop or chorus, yellow 8 beats before it and color the start of vocals blue.

Pick the colors YOU like

By default, you can pick a color from the Mixxx Hotcue Color palette. That palette contains 9 colors that are easy to distinguish.

Personal preferences differ though, and it's probably impossible to suit everyones taste. This is why - unlike most other DJ software - you are not restricted to the single predefined color palette we picked.

If you previously used Serato DJ Pro, Rekordbox, Traktor or VirtualDJ and like their color palettes better ours, we've got you covered. You can also use one of their palettes instead.

But it doesn't stop there: We also added a powerful color palette editor that can be used to rearrange and customize these palettes and even design your own palette using any RGB colors you like.

Automatic Coloring

When setting a hotcue, a single default color is assigned that you can select in the preferences. You can then go ahead and change the color to your liking.

While assigning a custom color to cue points after you set them is a nice feature, coloring all your cue points this way can be tedious and a lot of extra work. If you want, Mixxx 2.3 can color new hotcues automatically for you - based on the hotcue number.

A small example: Say you want to set a cue point before the main vocal part, and you want it colored "blue". You can configure Mixxx to always assign "blue" to the hotcues number 5, and then just set hotcue number 5 at the desired position - done.

If you do this, that also means that a hotcue of the same type (e.g. "before main vocals") does not only have the same color but is also assigned to the same hotcue pad. Hence, the possibility of getting confused during a gig is reduced even more than when just using colors as visual aid.

Bulk replace old hotcue colors

At some point, you might feel like your current scheme for color code hotcues lacking and unintuitive. Maybe you simply don't like the colors anymore and would like to switch to a different palette. Or you realize that you find the colorful hotcue buttons actually distracting and want to get rid of them. If that happens, you may want to bulk replace the colors of existing hotcue in your library.

We're not aware that any of our competitors in the DJ software market have such an option - Mixxx 2.3 has. You can find a dialog for replacing colors on the "Colors" page in the preferences window.

It allows bulk replacing hotcue colors for hotcues in your library and can be used to

replace colors by hotcue number ("Set the color of all hotcues with number 5 to blue"),
replace colors by current color ("Set the color of all red hotcues to blue"),
combine the two conditions ("Set the color of all red hotcues with index 5 to blue"),
negate them ("Set the color of all hotcues that are red but don't have number 5 to blue") or
just replace all hotcue colors in your library unconditionally ("Set the color of all hotcues to blue").

Support for colored hotcues on controllers

You're a controller mapping creator and wondered how to make use of hotcue colors on your controller? Then don't worry - we designed this feature with controller support in mind.

When it comes to hotcue buttons, there are 4 types of controllers:

Controllers without hotcue buttons
Controllers with uncolored buttons
Controllers with colored hotcue buttons that allow setting an arbitrary RGB color
Controllers with colored hotcue buttons that only allow setting certain, predefined colors

For controllers of types 1 and 2, nothing changes (obviously).

For type 3, we made the RGB color of a hotcue accessible in controller scripts, so you can go ahead and implement support for it. If your controller mapping uses our JavaScript Components library, this is quite simple: You only need to implement the HotcueButton::sendRGB(color) method, that sends the 3-byte RGB color value to the controller (e.g. via a MIDI-SysEx message, depending on your hardware).

What about type 4? Controllers that only allow choosing from a predefined color set were probably designed that way because they were sold with a software that does not allow assigned arbitrary colors to hotcues. You can think of these predefined colors as a list, and usually you can set the pad color of these controllers by sending the color's index in that list as MIDI value. For example, red could be color 1, blue is color 2, yellow is color 3, green is color 4 and so on.

We added a ColorMapper class that you can use to establish a mapping between these IDs and can be used to get the appropriate MIDI value for a given color.

But what happens if you set a hotcue to a color that isn't supported by the controller? Obviously, it's not possible to show the exact same color on your controller if the hardware simply doesn't support it - but don't worry, we've got you covered.

In this case, ColorMapper returns the ID of the color that is most similar to the color you put in. As an example, the hotcue color in Mixxx could be a darker shade of blue - ColorMapper will simply return the color for the regular blue color in this case, because it's the best match.

Seems complicated? It doesn't have to be. If your mapping already uses our JavaScript Components library, you can just create a ColorMapper object, add it to the HotcueButton and your colored hotcue pads should start working!

We also added controls to to make it possible assign a different color to an existing hotcue from your controller - for example, the mapping for the Roland DJ-505 uses the PARAMETER -/+ buttons next to the hotcue pads to cycle through the color palette for most recently activated hotcue.

Refer to our wiki if you want to integrate it into your controller mapping and check out the video below:

Guest Article: DJ on the fly with Mixxx and Raspberry Pi

2020-08-22T12:00:00+02:00

One of the things that make Mixxx special is that it works on more platforms that just Windows or macOS. Thanks to Mixxx being open-source, it's possible to create "unusual" setups that the developers didn't expect - for example by running it on a low-cost Raspberry Pi single board computer combined with a touchscreen. It's always great to see what cool stuff our users do with Mixxx, so when we discovered a video of it on Reddit, we asked Dennis to write a blog post about his project.

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Going portable

Since the advent of small, portable netbook computers and single board computers I have been trying to downsize my DJ setup. Frustrated by power issues, lack of performance and audio quality I resorted to a bulky but solid Thinkpad, a cheap controller and my software of choice: Mixxx.

This is a small story on how developments in both open source hard- and software as well as a well-equipped parts bin ends up in a somewhat specific but usable portable DJ setup using Mixxx and a Raspberry Pi.

This was until I was commissioned to make a random sound file player for an exhibition by De Player. In a move that later proved to be somewhat overkill, I grabbed a Raspberry Pi 3 that had been collecting dust and wrote some scripts to play random audio files.

Up until then I had only worked with the original Raspberry Pi and I was quite shocked at the greatly improved performance of the Pi model 3. Out of curiosity, a quick search of the Rasbian software repository brought up a match for "Mixxx"... but wait, would it actually run?

Gaining power

To my surprise Mixxx did run fine! With new found hope of building a "laptop-less" portable DJ setup I connected my USB sound card and cheap controller only to find out the Raspberry Pi could not deliver enough current to the USB port of the controller - no surprise there.

Eager to keep the setup simple and portable, I did not want to deal with external powered USB hubs. To no avail I tried various cheap USB cards and after many more low power warnings and high latencies, my eye fell on a white label brand controller (Akiyama Pulsar) with built-in soundcard. This "Traktor ready" controller had been given to me over the previous owner's frustrations with the lack of mappings for any other software than Traktor.

Putting one and two together

Being both a controller and audio interface, the Akiyama Pulsar reduced the overhead created by multiple USB devices (?) allowing the Raspberry Pi to run Mixxx smoothly with less than 20ms latency and no underruns. Note, this is without any optimizations to the Raspbian OS (no realtime kernel, no JACK) so there is possibly room for improvement!

As there was no mapping for the controller I set out to create my own. Most buttons are easily mapped using the GUI, but the jogwheels can be problematic. Starting from an existing community contributed mapping script that did not intimidate me (Icon iDJ) and by launching Mixxx with the --controllerDebug argument I was able to at least get the jogwheels to be somewhat reactive.

Skinning the fat

To make the setup extra portable I dressed my Raspberry Pi in a 2.8" Touch Screen that is long out of production. Being rather impractical, I would suggest getting a larger screen. Nevertheless, you will need a skin that accommodates the data you are interested in, while being readable on a small screen.

Again I started off with an existing skin, an older "minimal" skin found on in an old Mixxx install (< 2.0.0) only to find out there is no scaling, only absolute values for size and position as well a different naming convention for buttons, making it incompatible with newer skins and mappings ("library" verus "playlist" for example).

The skins provided by the later Mixxx distributions seemed rather indimidating at first but soon made me realized they are far more flexible than they look. Next to dynamic scaling using (e,e) units the newer default skins are somewhat modular. Departing from LateNight i simply deleted the style xml files for the buttons/sections I did not need, ending up with a minimal two deck view of waveforms, track name, bpm and using a leftover key on my controller to show and hide the fullscreen library!

The paths where Mixxx stores its default skins and controller mappings are different on various operating systems. Working with both OSX and Raspbian this was somewhat confusing at times. To add to this, the directory of the built-in skins/mappings is not the same as the user skins/mappings. As soon as you edit a default mapping for example, it gets copied to your "user" settings directory. Keep this in mind (and just edit/copy your custom mapping directly to your "user" settings folder).

In short

Get a Raspberry Pi 3 Model B or newer
Find a USB DJ controller with built-in sound-card.
Get a powerbank that can deliver the right amount of current. The specifications advertised about most electronics don't seem to tell much, there is only one way to find out...try it out and let the community know!

What is next?

The current setup is far from perfect. While being portable, allowing for a quick session at a friends place or even outdoors, the controller mapping and skin still need work. So rather than sharing an end result I hope this post will encourage you to start tweaking your own settings and contributing to the Mixxx cause!

Check out the complete how-to guide on this git repo. You will also find the skin and controller mapping there.
A separate post for the skin I modified can be found here.

GSoC 2020: Adding Experimental Meter Detection

2020-08-20T12:00:00+02:00

One of the parts where Mixxx is lacking is how it handles time signatures and downbeats. Currently, Mixxx only has individual beats but has no support for detecting or displaying additional information about the rhythm.

This is going to change during this year's Google Summer of Code (GSoC), because we have two students working on detecting and on displaying rhythm information. This post focuses on the implementation of meter detection, which is a chance to put Mixxx ahead of some of its commercial competitors that just assume a 4/4 time signature for all tracks.

The meter detection code is an extension of the tempogram as described by Peter Grosche, Meinard Muller and Frank Kurth and is based on the QM Vamp plugin that implement such features.

The tempogram is an analogy to spectogram and is a two-dimensional representation of onset detection function that captures the periodicity rate of note events. There are two main methods for capturing this periodicity the fourier transform which compares the onset function with periodic signals and the auto correlation function that compares the onsets with time shifted versions of itself. It's widely accepted that the salience of tempograms are able to capture the metrical structure of the music, but it's also easy to see that not all peaks are related to metrical information. This constitutes one of the biggest challenges for extracting the meter from such representations.

It has been reported that combining both representations helps to enhance the meter relevant peaks. This is the approach followed in the meter detection code. As proposed by Elio Quinton we call this combined tempograms the metergram.

While the metergram does indeed improve the metrical information periodicity it's still not clear and easy to distinguish the metrical peaks from other spurious saliencies. Following the ideas of Quinton we implement a musically informed peak picking algorithm based on the fact that neighbor metrical levels are related by an integer ratio. We start with out beat pulse which is computed from the QM beat tracker and then filter the integer pulses that might match the measure level considering the range of 6 to 60 beats per minute. Here we use the term beat not to refer to the beat itself but the metrical in analysis.

We then build metrical hierarchies by combining pulses that are apart by integer ratios and compute their weights by accumulating the weight of their constituent pulses and averaging them. Our chosen tempo range is usually large enough to accommodate the meter hierarchy of the accented beats inside a measure, beats per bar and phrases made of bars but this varies based on the beat pulse. By combining these pulses we are able to filter out individual pulses that do not match the metrical structure of the track.

The track Fuego by Alok & Bhaskar illustrates nicely the advantage of creating metrical hierarchies, instead of just looking at the highest peak. In this straight 4 on the floor beat, but the strongest pulse has a 17 beats length. However we can correctly detect the best hierarchy as <4,8,16>. In this case though there is an ambiguity of the phrase length, which could be 2 or 4 measures. By looking at the other hierarchies we can see that the <2,4,16> is stronger than the <2,4,8> which correctly indicates the 4 bar phrase used in this track.

A second advantage of our metrical hierarchy is that it's very common for the strongest pulse of 4/4 tracks to be of length equal 2 beats, but these could be of any simple meter, again by combining the pulses we are usually able to correctly identify if a track is 4/4 or not. There are still some challenges to address. If our best hierarchy is <2,4,8> for example, how can we possibly distinguish a 2/4 track with 2 bars phrases from a 4/4 track that has its strongest pulse of 2 beats?

One idea is to use the tempo as a hint, in the same way we can reasonably assume the right BPM is the one closest to 120, as opposed to double of half, we should also be able to reasonably assume that the a measure should be close to 2 seconds.

A track that nicely illustrates this property is All Blues by Miles Davis. It has a 6/4 meter and is around 156bpm. Our best meter hierarchy is <3,6,12> and it's strongest pulse is of 3 beats length. But a 3 beats bar would be around 1.15 seconds while the 6 beats bar is 2.3 seconds.

Finally we have a different kind of problem, that time signatures can be misleading and not always corvetely nicely in the meter hierarchy. A 6/8 time signature for example, indicates that the measure has 6 eight beats, but it's a common practice for musicians to fit 2 dotted quarter notes, instead of 6 eights on those time signatures. For example, Pat Menethy's Minuano (Six eight) is played like that. Our meter code estimates it's meter hierarchy as <2,4,8> which is wrong if we consider the time signature alone but 2 beats measure actually are correct if we consider the actual feel and meter of the song. Look how nice the 2 bar measure actually captures the six eight note onsets in this case:

On informal preliminary tests the meter detection code has an accuracy of around 80% which sounds nice on paper, but if we consider that probably 95% of tracks our users spins are 4/4 it still is more misleading than helpful.

Another huge limitation is that it uses a winner-takes-it-all strategy and is unable to find time signature changes or metric modulations. Although the meter is actually estimated at around 0.26 seconds windows, the output is to noise to be followed blindly and some smart algorithm still need to be developed with we want to follow changes.

There are still issues to address and the code is still very experimental with a lot of rough edges, but can be tested at 2877.

New in 2.3: Importing tracks and cues from Rekordbox removable devices

2020-07-20T12:00:00+02:00

Do you rock your gigs armed only with your cans and a Rekordbox prepared USB flash drive? Ever been tempted to play your carefully curated tracks on something other than a CDJ or Rekordbox, on something that is free and open-source? We have news for you!

Mixxx 2.3 will support reading the following from Rekordbox prepared removable devices on all of Mixxx's supported platforms:

Folders
Playlists
Beatgrids
Hotcues
Memory cues
Loops

You can use this new feature now in Mixxx 2.3 beta. This includes importing the key and BPM analyzed by Rekordbox, and comments and colors for tracks, cues and loops. We have to be clear however: this feature only reads Rekordbox prepared removable devices, such as USB flash drives or external hard drives. It will not read your locally stored Rekordbox collection if you also have Rekordbox installed. The main Rekordbox database (both for Rekordbox 5 and Rekordbox 6) use completely different formats from the USB drives, so reading those databases would be a whole other project.

Importing from Rekordbox to Mixxx

After you have exported music to a USB drive in Rekordbox, simply plug it in while Mixxx is running. Click on Rekordbox in the library, and all USB drives prepared with Rekordbox will be visible (attach as many as you like!). Then click on the desired removable device, and all your folders and playlists that you have so tirelessly prepared will be revealed for you to play from.

Some notes to keep in mind on how Rekordbox hotcues, memory cues, and loops are imported: Mixxx currently has one main cue point, one loop, and 38 hotcues. As such, all Rekordbox hotcues are mapped to Mixxx hotcues as expected, the first chronological Rekordbox memory cue is mapped to the Mixxx main cue, and the first chronological Rekordbox loop mapped to the Mixxx loop. All loops (including the first loop), and all subsequent Rekordbox memory cues are appended as Mixxx hotcues following the previously imported Rekordbox hotcues. A little confusing? Perhaps, but hopefully it will all make sense when you give it a whirl. Rest assured the hotcue and memory cue colors you assigned in Rekordbox are also imported, assisting in distinguishing between them. Also note that whilst the additional imported Rekordbox loops only appear in Mixxx 2.3 as hotcues, their loop details are preserved, ready for the multiple loop feature proposed for Mixxx 2.4!

Also note that as with the Serato library feature{# TODO: Add link to serato blogpost #}, we have tried our best to mitigate against certain edge cases of audio files encoded in lossy formats (MP3 and AAC/MP4), where different software's decoders can interpret conflicting timing information, leading to shifted cue points and beatgrids. We hope these are all correct, but some cases may be milliseconds off, and if you find any of these, please let us know on Zulip.

We probably didn't get every case perfect, so we have added some buttons by the beatgrid editing buttons to shift all cue points in a track by 10 ms (left click) or 1 ms (right click) so you can correct the timing yourself. This only shifts cue points, not the beatgrid (because the same problem happens with Serato and Mixxx does not yet import the beatgrid from Serato). If you want to shift the beatgrid too, you can shift the cue points, then go to a cue point and press the beatgrid shift button.

Can I prepare a Rekordbox removable device from Mixxx to use in a CDJ?

Sadly no, however this would be super cool! If you are so inclined to look at how to implement this and contribute back to Mixxx, it would be most welcome. A great to place to start would be looking into Kaitai Struct serialization which is a prerequisite for writing the PDB file format.

Shoutouts

As is often the case in open-source, the development of this new functionality was not possible without input from others. The new Mixxx Rekordbox removable device library feature builds upon the hard work already completed by Deep Symmetry for the Crate Digger library and Pedro Estrela's research about MP3 timing shifts for DJ Data Converter. Kudos and keep up the great work!

Future work: CDJs as Mixxx controllers

On a related note, we have started reverse engineering the HID protocol for the Pioneer CDJ 2000 NXS2. In future versions of Mixxx this would allow you to plug your laptop using Mixxx into CDJs via a USB cable and use your Mixxx library with the CDJs without needing Rekordbox at all. With the release of Rekordbox 6.0, this feature is now restricted in Rekordbox to customers paying a subscription fee, but Mixxx is free and unlike Rekordbox, Mixxx runs on Linux. You could even add another controller to a CDJ setup to control other Mixxx features such as an Allen & Heath Xone K2 for full control of Mixxx's effects while using CDJs!

We have documented what we have learned about the protocol so far but there is still more to reverse engineer. After that, it will be more work to write a Mixxx HID controller mapping. If you have a CDJ 2000 NXS 2 or other CDJ model and want to get involved in this reverse engineering effort, introduce yourself on our Zulip chat and let us know how you can help.

New in 2.3: Build Mixxx with CMake

2020-07-15T10:00:00+02:00

Starting with Mixxx 2.3, we're introducing experimental support for CMake. This will probably be more interesting for people who are either compiling Mixxx themselves or going hack on its code base than for regular users, but it will make the build process more straightforward in the future.

Mixxx has used SCons as its build system for more than 13 years. Since it's based on the Python programming language, it's quite flexible and can be used to customize every build step. Unfortunately, it requires lots of boilerplate code to accomplish simple tasks. This makes our build scripts hard to maintain on all platforms and has lead to problems in the past.

Hence, we added support for the CMake build system (or rather: build system generator), which many C++ developers are already be familiar with. This has several advantages:

The code is more maintainable and requires fewer platform-specific hacks. Also, less code is necessary. To give you a rough idea: We managed to reduce the line count from approximately 8000 lines of Python code down to a 2300 line CMakeLists.txt file plus modules. All in all we reduced the line count by almost 3000 lines.
If you prefer a graphical "build" button over compiling Mixxx on the command line, this is now possible: IDEs such as KDevelop, Visual Studio or CLion have support for CMake built-in. There is even a standalone GUI that you can try.
Improved caching: Unnecessary recompilation is annoying and a waste of time. To avoid this, we had a custom caching solution in SCons, which cached the compilation units based on the git branch you're working on. This solution took a lots of disk space and also had occasional issues with failed builds. With CMake, we added support for ccache (and clcache on Windows), which makes development significantly faster.
Arguably, CMake is vastly more popular than SCons, so we hope that more people be able to build and contribute to Mixxx.

Note that there are still some issues with building Mixxx on macOS with CMake, so if you own a Mac we'd appreciate if you help us out. Apart from that, it's already working quite well. Most of our core developers already switched over to CMake as their daily driver when working on Mixxx, but since it hasn't been as widely tested as we'd like, we label the support as "experimental" for the 2.3 release and stick with SCons for the release builds. We plan to drop SCons and fully migrate over to CMake in 2.4.

If you want to try out building Mixxx with CMake yourself, check the instructions in our wiki.

New In 2.3: Intro & Outro Cues, Silence Detection, and AutoDJ Improvements

2020-07-09T01:00:00+02:00

Do you use hotcues to mark the points you use to mix in and out of tracks? Have you wished AutoDJ knew to mix in and out at those points? In Mixxx 2.3, we have introduced new intro & outro cues for these purposes. You can try them now with Mixxx 2.3 beta. These are not ordinary cue points. Unlike hotcues, and unlike intro and outro cues in other DJ software, they do not mark only one point. The intro & outro are sections and each section is defined by two points.

When analyzing a track, Mixxx detects where the first and last sounds are to make it easy to skip playing silent parts at the beginning and end of the track. The analyzer places the intro start point at the first sound and the outro end point at the last sound. The first and last sound are determined by the first time the signal rises above -60 dBFS and the last time it goes below -60 dBFS.

It is up to you to decide where to place the intro end and outro start points. Marking the whole intro and outro allows Mixxx to calculate how long each section is and show it on the overview waveform. You can use this information to inform when you press play on the next track. AutoDJ can also use this information to line up tracks and determine how long to crossfade.

Mixing With The Intro & Outro Cues

As an example, you can line up the ends of the intro & outro so the energy of the new track picks up right as the old track ends.

If the intro and outro are both short enough to fit on the waveforms at the same time, you can simply watch the waveforms and press play when the markers align. Otherwise, you can watch the time remaining on the old track and press play when it is equal to the length of the intro of the next track.

If the old track has a period of silence at the end, the analyzer will mark the outro end where the sound becomes too quiet to hear. In this case, instead of watching the time remaining on the deck, hover your mouse cursor over the outro end line on the overview waveform. Mixxx will show how much time is left until that point. When that time equals the length of the intro, press play to precisely line up the end of the outro with the end of the intro. If you have changed the tempo of the track, the time remaining scales to show the real time remaining at the adjusted tempo.

Alternatively, you can line up the start of the intro & outro. In this case, watch the scrolling waveform when the outro start point is coming up on the old track. Then, press play on the new track when the old track reaches the outro start.

There are no firm rules to decide which method to use; it's an artistic judgement based on the musical content of each track, what the vibe of the crowd is at that moment, and what you want to do with the mix.

If you do not have the intro end and outro start points marked when loading a track, you can find and mark these in headphones before you mix in the track. Then, seek back to the intro start to get the track ready. If you don't have time to find the outro end point before mixing in the track, you can use the new deck cloning feature to drag and drop to a new deck, then seek ahead on the new deck and listen in headphones to mark the outro start point. If you don't have time to do that either, you can right click on the overview waveform where you think the outro starts. Then, look how far that is from the end of the track to compare it to the length of the intro of the next track.

Here, the outro is approximately 30 seconds long. However, the analyzer placed the outro end point before the end of the track, so the outro is actually a little bit shorter than 30 seconds. Without marking the outro start point, you would have to do some math in your head to find exactly how long the outro is.

Intro & Outro Cues With AutoDJ

In Mixxx 2.3, these new intro & outro section cues can be used to tell AutoDJ how long to crossfade and how to align the tracks in time. AutoDJ uses the intro & outro cues in the new "Full Intro + Outro" and "Fade At Outro Start" modes. In both modes, instead of crossfading over an arbitrary number of seconds, AutoDJ compares the duration of the outro of the old track and the intro of the new track. AutoDJ picks the time of the shorter section as the crossfade time.

If the outro is shorter than the intro, AutoDJ will align the start of the outro with the start of the intro in both modes.

The two modes work differently when the outro is longer than the intro. In the "Full Intro + Outro" mode, AutoDJ aligns the end of the intro and outro by starting the next track during the outro of the previous track. This way, the full length of both the intro and the outro are played. This mode is the most likely to sound good with the widest variety of tracks. Therefore, it is the default mode.

The "Fade At Outro Start" mode always aligns the start of the intro and outro. When the outro is longer than the intro, AutoDJ cuts off the end of the outro. This can be helpful if you want to prevent the energy of the mix from declining during a long outro. However, the transition may sound abrupt if the intro is short.

Both modes were designed so that AutoDJ sounds good fading between any pair of tracks if the intro and outro sections have been marked reasonably. AutoDJ does not take into account the volume of each track, nor the frequency content, nor the rhythms, so it's not intended to be a replacement for a human DJ. However, it is good enough to give a human DJ a break without a major disruption to the mix.

If you still want the old behavior of AutoDJ using a fixed number of seconds to crossfade, that is still available with the "Full Track" mode. The new "Skip Silence" mode behaves the same way, but cuts out the silence at the beginning and end of tracks.

Section Detection

Now that we know how useful it is to mark intro & outro sections, we are planning to take this concept further. As part of our Google Summer of Code 2020 projects, our GSOC students Harshit and Cristiano will be adding downbeat, phrase, and section markers to Mixxx and extending the analyzers to detect these. The intros & outros added in Mixxx 2.3 will become part of a timeline of sections that cover the whole track. We will add similar tools to show the duration of each section and the time remaining until section markers so you can get more creative with the temporal alignment of tracks.

Do you have more ideas for features that would allow you to DJ in new ways? Do you want to turn your ideas into reality? With Mixxx, you have the freedom to do this without begging a company to do it for you. If you want to help make Mixxx even more awesome, get involved!

#BlackLivesMatter: Taking a Stand with Terminology and Recruitment

2020-06-29T15:00:00+02:00

Alongside the protesters in the US and around the world, the Mixxx team unequivocally condemns police brutality. The systemic racism that burdens people of color every day is the responsibility of white people around the world to address. Mixxx' core development team feels it necessary not to remain silent on this issue, for "silence in the face of injustice is complicity with the oppressor."

Going beyond the hashtag, we have been discussing concrete actions we can take as a community and today we announce two efforts: first, to eliminate master/slave terminology from our code base and second, to recruit paid interns from underrepresented communities to join our contributor base.

Terminology Changes

Major projects like Python, Go, and now Github have all worked to eliminate the use of the problematic terms, "master" and "slave," and today Mixxx joins them. The issue of nomenclature and terminology in software is one example of how deeply embedded white privilege is around the globe and we hope changing these terms is one small step towards a more inclusive and diverse coding community.

Although we eliminated the use of the word "slave" back in 2016, "master" still appears in a number of places. We have a "master" code branch, a "Master Sync" feature, an "EngineMaster" object, and more. We are working to migrate our code away from these words, even in many cases where the particular meaning of "master" was never explicitly associated with a problematic context.

It’s important to note that there will be some cases where the word will remain. Many DJ controllers have buttons marked "master" on them, and we need to refer to those buttons by name. There are also the audio engineering concepts of a "master tape" or "audio mastering", so there may be areas of our documentation or code that would be less understandable if we tried to use synonyms. But in situations where "master" is used in code, we commit to changing the language we use in the next major release, Mixxx version 2.4.

But changing language is not enough.

Building A More Diverse Community

As an entirely online community that allows anyone to participate with a pseudonym, we don't know the exact demographic makeup of our contributors. Our impression, however, is that the Mixxx contributor base is largely white, male, and either from the US or Western Europe. This is especially disappointing given that people of color played a foundational role in creating DJing as an art form in the US and elsewhere. Technology companies have a tacit (and sometimes explicit) expectation that prospective employees "prove themselves" by contributing to open source projects. Companies also often value referrals, which increase the likelihood that new hires will be similar to previous hires, thus perpetuating homogeneity.

We want to break this cycle and ensure that the door to our open source network is open to everyone. It is our goal to make both the Mixxx community and the software we make as inclusive, accessible and welcoming as possible. As such, it is our responsibility to actively seek out and promote the participation of groups who are underrepresented in our community.

Research shows that blind admission and hiring tends to result in less diverse outcomes. To that end, we plan to participate in the Outreachy program and have a paid internship position by December 2020, the next available cycle. Outreachy’s stated goal is to provide "internships to work in open source and free software, for women (both cis and trans), trans men, and genderqueer people" and "residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander." They encourage "anyone who faces under-representation, systemic bias, or discrimination in the technology industry of their country" to apply.

Our goal is that this Outreachy intern will be one of an increasing number of valued contributors from more diverse backgrounds that will help us be a healthier, more sustainable open source project. Provided that we're able to raise sufficient funds, we commit to participate in Outreachy for at least 2 cycles. At that time we'll evaluate our progress and decide if we'll continue our participation or focus on other ways to support BIPOC.

One Outreachy intern will cost Mixxx $6,500 to sponsor. To fund our two cycles of interns, we'll need $13,000. As a project that is entirely community-driven, we are looking to you, our collaborators and users, to secure the funding for this effort. There is no company behind Mixxx. All Mixxx developers are volunteers that work on Mixxx in their free time. We have never and will never charge for Mixxx, so this is a chance for you to contribute money that will go directly to a person working on the project.

We are currently working out the details of our fundraiser and we hope to have it launched in the next couple weeks.

We're aware that replacing some terms and participating in Outreachy might seem insignificant in light of the discrimination and violence that people of color and Black people in particular face every day. As a project that depends on donations and volunteer work, we invite all our collaborators and users to discuss further community action on Zulip as we continue to stand against racism and discrimination. Keep protesting!

Mixxx 2.2.4 released

2020-06-25T12:00:00+02:00

Mixxx 2.2.4 has been released. Download it here.

This release fixes some bugs and adds some controller mappings, but doesn't introduce any new features. If you want to check out the new features of the upcoming 2.3 release, you can also download and test the 2.3 beta instead.

Changelog

Store default recording format after "Restore Defaults" lp:1857806 #2414
Prevent infinite loop when decoding corrupt MP3 files #2417
Add workaround for broken libshout versions #2040 #2438
Speed up purging of tracks lp:1845837 #2393
Prevent infinite loop when decoding corrupt MP3 files #2417
Store default recording format after "Restore Defaults" lp:1857806 #2414
Don't stop playback if vinyl passthrough input is configured and PASS button is pressed #2474
Fix debug assertion for invalid crate names lp:1861431 #2477
Fix crashes when executing actions on tracks that already disappeared from the DB #2527
AutoDJ: Skip next track when both deck are playing lp:1399974 #2531
Tweak scratch parameters for Mixtrack Platinum #2028
Fix auto tempo going to infinity on Pioneer DDJ-SB2 #2559
Fix bpm.tapButton logic and reject missed & double taps #2594
Add controller mapping for Native Instruments Traktor Kontrol S2 MK3 #2348
Add controller mapping for Soundless joyMIDI #2425
Add controller mapping for Hercules DJControl Inpulse 300 #2465
Add controller mapping for Denon MC7000 #2546
Add controller mapping for Stanton DJC.4 #2607
Fix broadcasting via broadcast/recording input lp:1876222 #2743
Only apply ducking gain in manual ducking mode when talkover is enabed lp:1394968 lp:1737113 lp:1662536 #2759

Mixxx GSoc Coding Begins

2020-06-08T01:00:00+02:00

This year Mixxx is again taking part in Google Summer of Code, and 3 students are working full-time for 3 months to make Mixxx even more awesome.

After one month of community bonding period, they started coding last week. Cristiano and Harshit, who are both working towards the same final feature—a new beatgrid format capable of handling not only beats, but also downbeats, phrases and sections as well varying tempos and time signatures—have already sent some initial patches to Mixxx' Git repository (#2844, #2847).

Cristiano which is focusing his work on the auto detection of such features is making weekly vlogs on YouTube to share his progress with the community. The first one is available here:

Watching embedded videos will transfer data to YouTube. To protect your privacy, you need to accept YouTubes privacy statement and terms of use first by clicking the button below.

Direct Link

Janek, who is working on a feature similar to Serato Flip, had the great idea and prepared a community call where the new and old members alike had the opportunity to get to know each other better and put some faces to their usernames.

We are looking forward to a new call in which we discuss our GSoC projects with our students, mentors and the rest of the community. If you're interested, hit us up on Zulip.

Mixxx 2.3 beta released

2020-06-07T01:00:00+02:00

We are proud to announce the release of Mixxx 2.3 beta, download it! This release brings hotcue colors & labels, Serato metadata import, Rekordbox metadata import, intro & outro cues, a revamped LateNight skin, multithreaded analysis, deck cloning, and more.

Please test it, report bugs, help translate, and contribute controller mappings. If you want help make Mixxx even more awesome, introduce yourself on our Zulip chat and read the developer documentation.

A brief overview of the changes is below. In the coming weeks, we will be publishing a series of posts on this blog discussing the new features in more depth, so stay tuned!

Hotcues

Add hotcue colors and custom labels by right clicking hotcue buttons or right clicking hotcues on waveforms (both overview and scrolling waveforms) #2016 #2520 #2238 #2560 #2557 #2362
Mouse hover cues on overview waveform to show time remaining until the cue #2238

Hotcue & Track Colors

Add configurable color per track #2470 #2539 #2545 #2630 lp:1100882
Add customizable color palettes for hotcue and track colors #2530 #2589
Add hotcue color find-and-replace tool #2547

Importing From Other DJ Software

Import cue points, track colors, and playlists from Serato file tags & database #2480 #2526 #2499 #2495 #2673
- Note: Mixxx does not yet support multiple loops per track. We are working on this for Mixxx 2.4. In Mixxx 2.3, if you import a track with multiple loops from Serato, Mixxx will use the first loop cue as the single loop Mixxx currently supports. The imported loops are still stored in Mixxx's database and are treated as hotcues in Mixxx 2.3. If you do not delete these hotcues, they will be usable as loops in Mixxx 2.4. Serato keeps loops and hotcues in separate lists, but Mixxx does not, so loops from Serato are imported starting as hotcue 9.
Import cue points, track colors, and playlists from Rekordbox USB drives #2119 #2555 #2543 #2779
- Note: The first Rekordbox memory cue is imported for the main cue button in Mixxx and the remaining Rekordbox memory cues are imported as Mixxx hotcues, starting with the next hotcue number after the last hotcue from Rekordbox.
- Note: Mixxx does not yet support multiple loops per track. Imported loops from Rekordbox are treated like imported loops from Serato, so refer to the note above for details.

Intro & Outro Cues

Add intro & outro range cues with automatic silence detection #1242
Show duration of intro & outro ranges on overview waveform #2089
Use intro & outro cues in AutoDJ transitions #2103

Deck cloning

Add deck cloning (also known as "instant doubles" in other DJ software) by dragging and dropping between decks #1892
Clone decks by double pressing the load button on a controller (with option to disable this) #2024 #2042

Skins & GUI

Aesthetically revamped LateNight skin #2298 #2342
Right click overview waveform to show time remaining until that point #2238
Show track context menu when right clicking text in decks #2612 #2675 #2684 #2696
Add laptop battery widget to skins #2283 #2277 #2250 #2228 #2221 #2163 #2160 #2147 #2281 #2319 #2287
Show when passthrough mode is active on overview waveforms #2575 #2616

Music Feature Analysis

Multithreaded analysis for much faster batch analysis on multicore CPUs #1624 #2142 lp:1641153
Fix bugs affecting key detection accuracy #2137 #2152 #2112 #2136
- Note: Users who have not manually corrected keys are advised to clear all keys in their library by pressing Ctrl + A in the library, right clicking, going to Reset -> Key, then reanalyzing their library. This will freeze the GUI while Mixxx clears the keys; this is a known problem that we will not be able to fix for 2.3. Wait until it is finished and you will be able to reanalyze tracks for better key detection results.
Remove VAMP plugin support and use Queen Mary DSP library directly. vamp-plugin-sdk and vamp-hostsdk are no longer required dependencies. #926

Music Library

Add support for searching for empty fields (for example crate:"") lp:1788086
Improve synchronization of track metadata and file tags #2406
Library Scanner: Improve hashing of directory contents #2497
Rework of Cover Image Hashing lp:1607097 #2507 #2508
MusicBrainz: Handle 301 status response #2510
MusicBrainz: Add extended metadata support lp:1581256 #2522
TagLib: Fix detection of empty or missing file tags lp:1865957 #2535

Audio Codecs

Add FFmpeg audio decoder, bringing support for ALAC files #1356
Include LAME MP3 encoder with Mixxx now that the MP3 patent has expired lp:1294128 buildserver:#37 buildserver:9e8bcee
Add Opus streaming and recording support. lp:1338413
Remove support for SoundSource plugins because the code was not well-maintained and could lead to crashes lp:1792747

Controllers

Improve workflow for configuring controller mappings and editing mappings #2569
Improve error reporting from controller scripts #2588
Make hotcue and track colors mappable on controllers #2030 #2541 #2665 #2520
Add way to change library table sorting from controllers #2118
Add support for velocity sensitive sampler buttons in Components JS library #2032
Add logging when script ControlObject callback is disconnected successfully #2054
Add controller mapping for Roland DJ-505 #2111
Update controller mapping for Allen & Heath Xone K2 to add intro/outro cues #2236

Development

Add CMake build system with Ccache support for faster compilation time #2280
- Note: The old SCons build system is still supported for 2.3. We will be removing it for Mixxx 2.4.
Make Mixxx compile even though QT_NO_OPENGL or QT_OPENGL_ES_2 is defined (fixes build on Raspberry Pi) lp:1863440 #2504

Website Redesign

2020-06-03T01:00:00+02:00

As you probably already noticed we facelifted our Website, gave it a more modern look and cleaned up the code. We will continue to update and improve its contents in the next weeks in joyful anticipation of the soon-to-be-released Mixxx 2.3 beta version.

Stay tuned!

You don't need to pay for Mixxx!

2020-05-22T13:00:00+02:00

Over the past few years there have been multiple instances of sellers that distribute paid boxed versions of Mixxx on eBay and Amazon. While it's not illegal to do this per se, we are not affiliated with these sellers and neither earn money from this nor endorse this in any way. Instead, you can download the latest version of Mixxx from the download page on our website for free.

If you want to support Mixxx financially, consider donating - we'll appreciate it!

Mixxx was, is and always will be free

In contrast our commercial competitors that offer "free" feature-reduced versions of their software, we do not impose any artificial restrictions on Mixxx. There is no "Pro Edition" or Premium version of Mixxx, even if it says so in the description of the online shop.

The Mixxx developers don't sell Mixxx, and if you "buy" Mixxx somewhere online you'll likely just get the free Mixxx version that the seller downloaded from our website and burned onto a CD. Even worse, some of these paid Mixxx versions might contain ads or malware according to Amazon reviews. Just use the free download from our website to get the ad-free, malware-free, most recent version of Mixxx.

Mixxx is free as in freedom, not just free as in "free beer"

You don't need to pay money to use Mixxx, but there's more: Its source code is accessible to everyone and if you know how to code, you can modify it and customize Mixxx to a degree that is simply not possible with any closed-source software. Even if you did get your hands on the source code of Serato DJ Pro/Lite, Rekordbox, Traktor or VirtualDJ (which is not available to their users), it would be illegal for you to modify the program or redistribute it.

Mixxx, on the other hand, is free software and grants you the four essential freedoms:

The freedom to run the program as you wish, for any purpose.
The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others.
The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

These freedoms are guaranteed by the license Mixxx uses, the GNU General Public License (GPL). Thanks to the GPL, these freedoms can never be taken away from you. It's a copyleft license, meaning anyone who distributes or modifies Mixxx has to use the same license and provide the source code.

The original Mixxx developers chose the GPL when they started Mixxx back in the early 2000s. They stopped working on Mixxx many years ago, but thanks to the copyleft terms of the GPL, you have the same freedoms with Mixxx now as when the first version of Mixxx was published. We can't take that away, nor could any future developers, nor could any company. It's free because it's yours.

If you want to know more about Mixxx' license, check out the FAQ.

Getting involved

The Mixxx project is entirely community-driven and supported by volunteers from all over the globe. None of our developers are paid; all of us are passionate about the project and work on Mixxx in our spare time.

We dedicate our time to working Mixxx, because we believe in open-source and care about delivering a decent product to our users — including ourselves! In fact, all our currently active developers started out as regular Mixxx users — just like you.

Do you want to contribute to Mixxx, too? You can! There are countless ways to get involved in the Mixxx community. You hack on Mixxx' code, create controller mappings, test new in-development features, improve Mixxx skins or design new ones, translate Mixxx into your language, write articles and make YouTube videos about Mixxx or help out newbies on Zulip Chat or our forums. Every little bit helps!

Help us make Mixxx even more awesome than it already is!

Announcing our Google Summer of Code Projects 2020

2020-05-05T01:00:00+02:00

Mixxx is participating in this year's Google Summer of Code (GSoC), an opportunity for students to work on Mixxx full-time as a 3-month summer project and receive a stipend from Google.

For this year's Google Summer of Code, Mixx has been granted 3 slots that will be filled by students from 3 different continents: Harshit Maurya from India, Cristiano Lacerda from Brazil and Janek Fischer from Germany. Congratulations!

Harshit and Cristiano will be working on making a new beatgrid format that marks bars, meter, and phrases.

Cristiano will focus on implementing autodetection of this information from audio files. This DSP- and research-heavy project will mentored by Daniel Schürmann.

Harshit will focus on creating the user interface for viewing and editing the beatgrid and using this information in other Mixxx features like waveforms, loops, beatjumps and quantization. Uwe Klotz will be his primary mentor.

Janek will be working on a macro recording feature inspired by Serato Flip to record custom edits in Mixxx without altering the audio files. His project will be mentored by Jan Holthuis.

We're going to do things a bit differently for GSoC this year than we have in the past. Before, mentors have had a lot of private one-on-one communication with students. This year we'll be encouraging students to discuss their work more publicly so the whole community is involved throughout their projects.

Thus, if you're interested in these projects check our Zulip chat for discussions and progress reports.

Mixxx accepted for GSoC 2020!

2020-02-20T20:00:00+01:00

Mixxx has been accepted as a mentoring organization for Google Summer of Code 2020, a global program that aims to bring more student developers into the world of open source development.

This means that students have the opportunity to work on Mixxx full-time as a 3 month programming project and receive a stipend sponsored by Google. For more information, check out the Google Summer of Code FAQ.

We have prepared a list of GSoC 2020 Project Ideas for Mixxx and added it to our wiki, but we're always interested in new ideas. Taking a look at our GSoC advice page is recommended if you're planning to apply. The best way to get started is to participate in the Mixxx community, so have a look at our GitHub repository and consider making a small code contribution to show that you're able to familiarize yourself with our codebase. The application period is March 16 - 31, 2020.

Past GSoC projects include Live metadata output and effects customization. A complete list can be found at our wiki.

If you're interested in hacking on Mixxx this summer, become a part of the Mixxx community and apply starting March 16th!

Mixxx 2.2.3 released

2019-12-09T16:25:00+01:00

Mixxx 2.2.3 has been released. Download it here.

Changelog

Don't make users reconfigure sound hardware when it has not changed #2253
Fix MusicBrainz metadata lookup lp:1848887 #2328
Fix high DPI scaling of cover art #2247
Fix high DPI scaling of cue point labels on scrolling waveforms #2331
Fix high DPI scaling of sliders in Tango skin #2318
Fix sound dropping out during recording lp:1842679 #2265 #2305 #2308 #2309
Fix rare crash on application shutdown #2293
Workaround various rare bugs caused by database inconsistencies lp:1846971 #2321
Improve handling of corrupt FLAC files #2315
Don't immediately jump to loop start when loop_out is pressed in quantized mode lp:1837077 #2269
Preserve order of tracks when dragging and dropping from AutoDJ to playlist lp:1829601 #2237
Explicitly use X11 Qt platform plugin instead of Wayland in .desktop launcher lp:1850729 #2340
Pioneer DDJ-SX: fix delayed sending of MIDI messages with low audio buffer sizes #2326
Enable modplug support on Linux by default lp:1840537 #2244 #2272
Fix keyboard shortcut for View > Skin Preferences lp:1851993 #2358 #2372
Reloop Terminal Mix: Fix mapping of sampler buttons 5-8 lp:1846966 #2330

Mixxx 2.2.2 released

2019-08-15T07:06:00+02:00

Mixxx 2.2.2 has been released and is available on the download page.

This release includes many stability and usability fixes. Please note that we had to disable writing of file tags for .ogg files with the current TagLib version 1.11.1 that would otherwise corrupt your precious files. Upgrading from version 2.2.1 is strongly recommended.

Changelog

Fix battery widget with upower <= 0.99.7. #2221
Fix BPM adjust in BpmControl. lp:1836480
Disable track metadata export for .ogg files and TagLib 1.11.1. lp:1833190
Fix interaction of hot cue buttons and looping. lp:1778246
Fix detection of moved tracks. #2197
Fix playlist import. lp:16878282
Fix updating playlist labels. lp:1837315
Fix potential segfault on exit. lp:1828360
Fix parsing of invalid bpm values in MP3 files. lp:1832325
Fix crash when removing rows from empty model. #2128
Fix high DPI scaling of RGB overview waveforms. #2090
Fix for OpenGL SL detection on macOS. lp:1828019
Fix OpenGL ES detection. lp:1825461
Fix FX1/2 buttons missing Mic unit in Deere (64 samplers). lp:1837716
Tango64: Re-enable 64 samplers. #2223
Numark DJ2Go re-enable note-off for deck A cue button. #2087
Replace Flanger with QuickEffect in keyboard mapping. #2233

Mixxx 2.2.1 released

2019-04-23T21:18:00+02:00

Mixxx 2.2.1 has been released and is available on the download page. This update includes fixes that were in 2.1.7 and 2.1.8. There were a few performance improvements which have an especially big impact on macOS. Mac users who were staying with 2.1.x versions because 2.2.0 was too slow are advised to upgrade to 2.2.1. Other fixes include:

LED output for the Traktor Kontrol S4 Mk2 on Windows has been fixed.
Mute and volume controls for microphones have been fixed.
The QuickEffect enable button can now be selected in the controller mapping wizard.
Fix a bug where the cover art window could not be closed.
Numark Mixtrack (Pro) 3 mapping: fix bug where TAP + FX level to move the beatgrid changed the effect unit mix knob.

Note that we are currently having an issue updating the Ubuntu PPA. Ubuntu users can install the .deb file from the download page or wait until we get the new update in the PPA (or build from source code).

Mixxx 2.2 released

2018-12-24T18:07:00+01:00

Mixxx 2.2.0 has been released, download it! Since we are now releasing Mixxx more often, the changes are not as big as between Mixxx 2.0 and Mixxx 2.1. Here is a quick overview of the changes since Mixxx 2.1:

General

Update from Qt4 to Qt5.
Use Qt5's automatic high DPI scaling.
Vectorize remaining raster graphics for better HiDPI support.

Effects

Add mix mode switch (Dry/Wet vs Dry+Wet) for effect units.
Add support for LV2 effects plugins (currently no way to show plugin GUIs).
Add preference option for selecting which effects are shown in the list of available effects in the main window (all LV2 effects are hidden by default and must be explicitly enabled by users).

Library

Text searches without any field qualifiers (such as "title: some-title") now search crates.

Skins

Add 8 sampler and small sampler options to LateNight.
Add key / BPM expansion indicators to Deere decks.
Add skin settings menu to LateNight.

Controllers

Add controller mapping for Numark Mixtrack Platinum.
Update controller mapping for Numark N4.
Add spinback and break for Vestax VCI-400 mapping.

Miscellaneous

Add preference option to adjust the play position marker of scrolling waveforms.
Add preference option to adjust opacity of beatgrid markers on scrolling waveforms.
Support IRC/AIM/ICQ broadcast metadata.

The focus of development for Mixxx 2.2 was switching from Qt 4 to Qt 5. Qt is the toolkit that allows us to write one Mixxx application that runs on Linux, macOS, and Windows. For users, the most noticeable difference from this will be improved support for scaling the graphical user interface (GUI) for high pixel density (high DPI) screens. The scaling we used with Qt 4 in Mixxx 2.1 scaled most parts of the GUI, but some small parts like the arrows on menus and widgets in the preferences did not scale. Now with Qt 5, everything scales automatically according to the operating system scaling settings. Going forward, we will be able to use new features of Qt sooner (for example, work is ongoing for supporting ECMAScript 7 in controller scripts). Note that Qt 5 requires Windows 7 or later, so Mixxx 2.2 no longer supports Windows XP and Windows Vista.

We have added a new button to the effects units that adds a new mode for mixing effects. Previously, the mix knob always crossfaded between the dry signal (input to the first effect) and wet signal (output of the last effect). This is now called Dry/Wet mode and is the default. The new Dry+Wet mode always keeps the dry signal at full volume and the mix knob controls how much of the wet signal is added. This allows for adding sounds with effects without modifying the underlying track. For example, with the effect unit in Dry+Wet mode, you can load an equalizer or filter effect before the Echo effect to remove bass frequencies from the echoed signal without removing the bass from the track.

Mixxx 2.2 introduces initial support for LV2 sound effects plugins. Many GNU/Linux distributions package LV2 effects plugins that can be installed separately from Mixxx. Because many LV2 plugins are not useful for DJing, you must explicitly enable plugins in the Effects section of the preferences before you can load them in the Mixxx main window. Currently there is no way to show the GUI for LV2 plugins in Mixxx. While LV2 effects are technically cross-platform, in practice there are very few LV2 plugins that are distributed for macOS and Windows. Mixxx 2.2 has LV2 support enabled for GNU/Linux and macOS, but not for Windows.

Want to help make Mixxx more awesome? We could always use more people, whether you can write code or not. If you are interested in getting involved, join us on our Zulip chat and introduce yourself.

2.1.3 released

2018-08-20T22:42:00+02:00

Hello again, everyone. Another release so soon?? It seems a performance regression slipped into 2.1.2, but the great people working on Mixxx found and fixed it quickly so we have 2.1.3 ready for you now!

You know where to get it. :)

As always, report any issues using our bug tracker and check out our support resources.

Mixxx on!

Mixxx 2.1.2 released

2018-08-19T21:52:00+02:00

Hello, Mixxxers. We're happy to announce our latest bug fix release of 2.1.2. Here's a summary of what has changed:

Allow maximum deck speed of 4x normal
Don't always quantize hotcues, a 2.1.1 regression, bug #1777429
Fix artifacts using more than 32 samplers, bug #1779559
Store No EQ and Filter persistently, bug #1780479
Pad unreadable samples with silence on cache miss, bug #1777480
Fixing painting of preview column for Qt5 builds, bug #1776555
Fix sampler play button tool tips, bug #1779468
LateNight skin: Fix play button right click, bug #1781829
LateNight skin: Added missing sort up/down buttons
Shade skin: remove superfluid margins and padding in sampler.xml, bug #1773588
Deere skin: Fix background-color code
ITunes: Don't stop import in case of duplicated Playlists, bug #1783493

If you encounter any problems, please report at https://bugs.launchpad.net/mixxx/+filebug.

We are also of course working towards Mixxx 2.2.0 which will include new features and be built on QT 5. We can always use more help with programming, testing, documentation, translations and so on, so please get involved!

Until next time, have fun!

Mixxx 2.1.0 has arrived!

2018-04-16T17:56:00+02:00

After more than two years of hard work, we are pleased to announce the release of Mixxx 2.1.0! Since Mixxx 2.0, we have overhauled the effects system, redesigned the skins, added and improved lots of controller mappings, rewrote the audio file decoders twice, and of course fixed a bunch of bugs.

Download Mixxx 2.1.0 Now

Available for Windows, macOS, and Linux.

Here is a quick summary of what is new in Mixxx 2.1:

Graphical interface scales for high resolution screens
Overhauled Deere and LateNight skins
New Tango skin
Resizable waveforms
Effects are synchronized to the tempo
Effects are processed post-fader and post-crossfader and can be previewed in headphones
One metaknob per effect with customizable parameter control for intuitive use of effect chains
Nine new effects: Autopan, Biquad Equalizer, Biquad Full Kill Equalizer, Loudness Contour, Metronome, Parametric Equalizer, Phaser, Stereo Balance, Tremolo
Loaded effects and their parameters are saved and restored when Mixxx restarts
More transparent sounding equalizers (Biquad Equalizer and Biquad Full Kill Equalizer)
Improved scratching sounds with jog wheels, vinyl control, and dragging waveforms with the mouse
Simplified looping and beatjump controls
Configurable rows of 8 samplers with up to 8 rows available for a total of 64 samplers
Files loaded to samplers are reloaded when Mixxx restarts
Improved volume normalization algorithm (EBU-R 128)
Filter library table by crates
Sort musical keys in library table by circle of fifths
Write metadata tags back to audio files
New JavaScript library for controller mapping
Configure multiple Internet broadcasting stations and use multiple stations at the same time
Broadcast and record microphones with direct monitoring and latency compensation
Broadcast and record from an external mixer
Booth output with independent gain knob for using sound cards with 6 output channels without an external mixer
Prevent screensaver from starting while Mixxx is running
CUP (Cue And Play) cue button mode
Time remaining and time elapsed now take into account the tempo fader
Clicking cover art now shows it full size in a separate window
and of course, lots and lots of bug fixes./li>

Hardware Support

Here are controllers with mappings that have been added or updated since the 2.0.0 release. Mappings marked with an asterisk (*) have been updated for the new effects interface:

Important Announcements for Upgrading from 2.0.x

For users upgrading from Mixxx 2.0.x or older, we have a few important announcements. First, if you are using Windows, you will have to uninstall any old versions of Mixxx before you can install 2.1.0 (unless you were using the 2.1.0 beta or release candidate). How to uninstall Mixxx varies on different versions of Windows:

Windows Vista, 7, and 8: Start > Control Panel > Programs > Uninstall a Program
Windows 10: Start > Control Panel > Programs > Programs And Features > look for Mixxx > Uninstall

If you are upgrading from Mixxx 2.0.0 or older and have MP3 files in your library, we have another important announcement. The good news is that we fixed a bug where the waveforms and audio playback of MP3 files were misaligned. The bad news is that we have no way of knowing which MP3 files were affected or how much the offset was. That means that waveforms, beatgrids, cues, and loops from older versions of Mixxx may be offset by an unknown amount for any MP3 file. Only MP3 files were affected by this bug; other audio file types are unaffected. You can either correct your beatgrids and cue points manually for each track, or you can clear this information for all MP3s and start fresh. Regardless, we recommend clearing the waveforms for all MP3 files. To clear these, type "location:mp3" into the library search bar, press Control + A to select all tracks, right click, and select the information you want to clear from the menu.

Bugs and Feedback

You can help improve Mixxx by reporting any bugs you find . Your feedback plays a crucial role in Mixxx's development cycle, and even filing a quick bug report makes an important contribution to the project. We want to hear from you! Please send us feedback, file a bug, write us an email, post to the forums, or chat with us on Zulip.

Join Us!

Want to help make Mixxx even more awesome? The biggest thing we need is more people. You do not need to be a programmer to help out. Giving feedback on the design of new features as they are being made is very valuable. Refer to the Testing page on the wiki for more information on how to get involved with that. Reporting bugs and telling us your ideas on the Launchpad bug tracker is a big help too! We cannot fix problems we do not know about, so please let us know if you find any issues with Mixxx. If you would like to help translate Mixxx into another language, refer to the Internationalization wiki page. Of course, more programmers could always help! Read the Developer Documentation on the wiki for tips on getting started contributing code to Mixxx.

We hope you have as much fun with Mixxx as we do!

Announcing Mixxx 2.0!

2015-12-30T00:59:00+01:00

The wait is finally over. After years of hard work, the Mixxx development team is pleased to present Mixxx 2.0!

Download Mixxx 2.0 Now

Available for Windows, Mac OS X, and Linux.

Mixxx 2.0 is the culmination of over a decade of work by hundreds of DJs, artists, and software engineers. We hope you enjoy it! If you tried our betas then you already know what you're in for. If not, check out this quick tour of the new features in Mixxx 2.0.

A Sneak Peak at Mixxx 2.1

In order to prevent a repeat of the long delay between the 1.11 and 2.0 releases, we are making changes to allow us to release new versions more rapidly. As part of those changes, we will soon cut the release branch for Mixxx 2.1 to get the ball rolling on our next release targeted for Q1 2016.

Our focus for this iteration will be an already-completed rewrite of our Audio File Decoders and improved Controller Support.

If you'd like to help out or even provide commentary / advice, see below for details on how to join us in making Mixxx great.

Help Translate Mixxx

We want Mixxx to rock parties around the whole world and we need your help to do it! If you speak a non-English language, we could use your help translating Mixxx as well as our manual and website. Check out our Transifex page and internationalization wiki for details on how to get started.

Bugs and Feedback

You can help improve Mixxx by reporting any bugs you find. Your feedback plays a crucial role in Mixxx's development cycle, and even filing a quick bug report makes an important contribution to the project. We want to hear from you! Please send us feedback, file a bug, write us an email, post to the forums, or chat with us.

Join Mixxx

We're always looking for new contributors who are interested in working on Mixxx. If you're a hacker, artist, or translator and want to work with a creative, enthusiastic team, hop on our IRC channel (#mixxx on Freenode) or sign up for our developer mailing list.

What's New in Mixxx 2.0

2015-12-19T18:50:22+01:00

New to Mixxx?

Mixxx is free, open source DJ software that gives you everything you need to DJ and mix music live at your next party or club gig. Download it today and mix like a pro on Windows, Mac OS X, and Linux.

Three years in the making, we've added so many new features to Mixxx that we had to call it 2.0. As always, Mixxx 2.0 is available as a free upgrade for all existing Mixxx users.

Dynamic, Resizable Skins

Each of our three professionally-designed skins can stretch to fill whatever size screen you have. Turn parts of the interface on and off to reveal the features you use most.

4 Decks with Master Sync

Supporting the latest DJing techniques, Mixxx supports up to four decks playing back simultaneously. Combine tracks with loops and samples to create sophisticated on-the-fly remixes.

Holding your mix together is the new Master Sync engine, a powerful feature that holds all of your tracks perfectly aligned even if you change the speed of the mix.

Built-in Effects

Mixxx's new effect processing system allows you to apply up to 4 chains of effects to any mixer channel. Mixxx 2.0 comes with 5 high-quality effects and 4 equalizer effects with many more to come!

Flanger
Moog 4-pole Ladder Filter
Echo
Reverb
BitCrusher
Bessel 4th Order EQ
Bessel 8th Order EQ
Linkwitz-Riley 8th Order EQ
Biquad 8 band graphic EQ

Harmonic Mixing with Musical Key Detection

Mixxx now detects the musical key of your tracks and allows you to fine tune them to be in key with the rest of your mix. With support for Traditional, Open Key, Lancelot, and custom key notations, you'll feel right at home no matter what system you're used to.

RGB Waveforms

See the sound of your music. With RGB waveforms, bright red means killer bass, blue glints where you find crisp hihats, and soft greens show you when the lyrics come in. A quick glance at the waveform overview and you'll know if a track is banging or just right for sunrise.

Four Microphones, Four AUX Inputs, Microphone Ducking

Radio DJs, MCs, and users with external gear will appreciate the flexibility of 12 total external audio inputs. And with auto-ducking, listeners will always be able to hear you over the music.

Vinyl Passthrough

Calling all vinyl addicts — you can now switch off between vinyl timecode records and vinyl audio records with the new vinyl passthrough feature.

Like what you see? Download Mixxx for FREE and Start DJing:

Download

Cover Art Support

Mixxx reads cover art from your tracks and displays it in the library, on your decks, and on the spinning vinyl widgets.

Core Mixing Engine Improvements

Improved, high-fidelity equalizers.
Improved time-stretching algorithm for better sounding key-lock.
Multi-soundcard Synchronization Improvements
Mono / Stereo Output
Mono Mixing
Split Cueuing
Master/Headphone Delay
Latency Usage Meter
Improved Broadcasting Stability
Improved Microphone Routing

Upgraded Library

The Mixxx music library was designed from the ground up for DJs. Powered by a high-performance database, accessing and organizing your music is easy and intuitive.

Auto DJ Crates

Need an extended bathroom-break? Automatically expand your Auto DJ queue with Auto DJ crates.

Multi-Core Library Scanner

Got a huge library? Mixxx will fly through it with its new multi-core scanning support.

Cover Art Support

Evoke the feel of thumbing through your record crate. Mixxx now shows slivers of cover art in the library table.

Improved Auto DJ Stability

We've worked closely with heavy users of Auto DJ to identify problems, clean up code, and add internal tests to make Auto DJ more reliable than ever.

MusicBrainz Tag Lookup

Fingerprint your tracks and fetch missing tags from MusicBrainz.

Improved, Expanded Support for DJ Controllers

Thanks to generous DJs and our vibrant forum community, Mixxx 2.0 brings support for an exciting new range of DJ controllers.

Newly Supported DJ Controllers

New Mixxx Certified Controllers

Traktor Kontrol S4 MK2
Denon HS5500

New Mixxx Community Supported Controllers

American Audio RADIUS 1000
American Audio RADIUS 3000
Denon MC6000MK2
Denon SC2000
DJ-Tech Kontrol One
DJ-Tech Mixer One
Electrix Tweaker
Korg nanoKONTROL 2
MixVibes U-Mix Control 2 Pro
Novation Launchpad Mini
Numark MixTrack Pro II
Pioneer DDJ-SB
Pioneer DDJ-SB2
Reloop Beatpad
Reloop Terminal Mix 2
Vestax VCI-100 MKII

Want to know if your DJ controller is supported in Mixxx? Please check the full technical specifications.

Ready to Upgrade? Download Mixxx for FREE and Start DJing:

Download

Surprise! Release Candidate 1

2015-12-05T19:04:00+01:00

Hi Mixxx-heads,

Are you ready for a surprise?

The Mixxx 1.12 beta period has been going quite smoothly and we're almost ready to launch this baby. This release packs a punch. It's our single biggest release ever and adds more headline features than we've ever put in one release. We decided that it was time -- time to drop the "1.1" (it's cleaner):

Mixxx 1.12.0 will be... Mixxx 2.0!

We've been working towards this release for many years now. But we still need your help to make this our best ever.

We need your help translating and testing.

Today we're releasing Mixxx 2.0 Release Candidate 1. If all goes according to plan, we're going to get some more testing in from the community and have Mixxx 2.0 ready for all of your New Year's Eve parties!

Please help us out!

Download Mixxx 2.0 RC1 Now

Available for Windows, Mac OS X, and Linux.

Help Translate Mixxx
In order to make this release rock in every language we need your help with translations! This is the first release we are offering translations of the Mixxx manual in addition to the app itself. We are currently in dire need of translations for Spanish, Chinese and Japanese (among many other languages).
Check out our Transifex page and internationalization wiki for details on how to get started.

Call for Controller Presets
Support for MIDI/HID controllers is historically one of Mixxx's biggest weak points. If you have built a controller preset for a device, please consider submitting it for inclusion in Mixxx as a community-maintained preset! Check out the guide on our wiki for more details.

Bugs and Feedback

You can help improve Mixxx by reporting any bugs you find . Your feedback plays a crucial role in Mixxx's development cycle, and even filing a quick bug report makes an important contribution to the project. We want to hear from you! Please send us feedback , file a bug , write us an email , post to the forums , or chat with us. .

Join Mixxx

Mixxx 1.12 Beta Released!

2015-04-29T03:12:00+02:00

Hi Mixxxers -- did you miss us? The Mixxx team has been quietly toiling for over 2 years to bring you Mixxx 1.12. This will be our biggest release ever and we need your help to make sure that it's our best ever as well. We've been doing alpha testing with our dedicated forum users for a while now and are ready to release Mixxx 1.12 Beta!

Download Mixxx 1.12 Beta Now

Available for Windows, Mac OS X, and Linux.

There are too many new features and fixes to list all of them, but here's just some of the new things Mixxx can do:

4 Decks with M aster Sync
New Effects Framework with 4 Effect Units and 5 Built-in Effects:

Flanger
Bit Crusher
Reverb
Echo
Filter
More to come!

Configurable, Resizable User Interface with 3 Brand New Skins
Cover Art Display
Music Key Detection and Shifting
Vinyl Audio Pass-Through
4 Microphone inputs and 4 Auxiliary inputs
MIDI Mapping GUI and Improved Learning Wizard
RGB Musical Waveforms
Hundreds of Bug Fixes and Improvements
New Pitch-Independent Algorithm for Better-Sounding Key-lock.

If you tried the Alpha release, be sure to check out the Beta. There are a ton of new features and fixes even since then. And we'll be updating the Beta every week, so you can always have the latest updates.

Help Translate Mixxx
In order to make this release rock in every language we need your help with translations! We are currently in dire need of translations for Chinese and Japanese (among many other languages).
Check out our Transifex page and internationalization wiki for details on how to get started.

Bugs and Feedback

You can help improve Mixxx by reporting any bugs you find . Your feedback plays a crucial role in Mixxx's development cycle, and even filing a quick bug report makes an important contribution to the project. We want to hear from you! Please send us feedback , file a bug , write us an email , post to the forums , or chat with us .

Join Mixxx

Google Summer of Code 2013 Projects!

2013-05-29T22:14:00+02:00

The Summer of Code is upon us! Google has just announced which students Mixxx has accepted into the Google Summer of Code 2013 program. Students were competing for one of four slots awarded to Mixxx by Google. This year we received a high volume of applications from many skilled students which made the decision-making process very difficult.

After over two weeks of deliberation, we're pleased to introduce our Google Summer of Code students for 2013:

Wei Xin from Dalian University of Technology in Liaoning, China
Carl Pillot from The New England Conservatory of Music in Boston, USA
Nazar Gerasymchuk from Taras Shevchenko University in Kiev, Ukraine
Chris Johnson-Roberson from Brown University in Rhode Island, USA

Wei Xin will build a community-powered controller mapping portal . This will allow Mixxx users to download the latest controller presets for their devices, rate and comment on presets, and share their own presets with the community. All of this will be possible from within Mixxx!

Carl Pillot will build a loop recorder for live remixing . This will allow DJs to record samples from their live mix and play them back live, providing them with yet another opportunity to get creative with their performances.

Nazar Gerasymchuk will re-design Mixxx's database concurrency model to fix a long-standing issue Mixxx has with locking the GUI for database queries. This should make the Mixxx interface smoother than ever!

Last but not least, Chris Johnson-Roberson will build an intelligent track suggestions feature which aims to helps DJs with the most important choice there is in DJing: what to play next.

This summer's Google Summer of Code projects will be a huge step forward for Mixxx both in functionality and polish. We can't wait to get these students integrated into the Mixxx community and get their work into a release. The 4 will be mentored by our mentoring team: RJ Ryan, Max Linke, Daniel Schürmann, Owen Williams, Sean Pappalardo, and Albert Santoni. As always, we're very grateful for Google's generosity in enabling this work.

Meanwhile, the Mixxx team is working full-speed ahead on Mixxx 1.12, which we hope to release by Christmas 2013. Look for an alpha release in the near future!