Since scheduled GitHub workflows unfortunately only run on the default branch, we'd have to modify main's workflow accordingly, e.g.

diff --git a/.github/workflows/update-mixxx.yml b/.github/workflows/update-mixxx.yml
index 0715f62..500cc06 100644
--- a/.github/workflows/update-mixxx.yml
+++ b/.github/workflows/update-mixxx.yml
@@ -9,10 +9,14 @@ on:
 jobs:
   automerge:
     runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        branch: ['2.4', 'main']
 
     steps:
     - uses: actions/checkout@v3
       with:
+        ref: '${{ matrix.branch }}'
         fetch-depth: '0' # to compute the monotonic version correctly
         submodules: true
     - name: Configure Git user

The issue is that the build currently depends on a workflow_run trigger, for which I am not sure if it triggers in the way we would expect across branches: Given that the scheduled workflows run on main, 2.4's build workflow would likely not end up being triggered. We might be able to work around that by using e.g. a repository_dispatch event, but I am not sure if workflows on non-default branches will receive these events. This would be something to investigate.

Probably a silly question, but I am new to mac world so not sure: will m1xxx fork work for m2 (macbook air 2022)?

Status

The wasm branch contains experimental forks of mixxx and vcpkg for targeting wasm32-emscripten.

You can try it out, there is a GitHub Pages-hosted build at https://fwcd.dev/m1xxx, but be warned: It may take a while to load (tne Wasm binary is ~300 MB, the assets are ~90 MB) and there is no audio (the experimental "Web Audio" backend is not functional yet, hence why it is disabled by default).

On the technical side, there are still some major roadblocks to be resolved:

• Mixxx will crash when building with -sASSERTIONS, see
  • This Qt forum post: https://forum.qt.io/topic/155159/cannot-have-multiple-async-operations-in-flight-at-once-during-qapplication-initialization
  • This Emscripten issue: emscripten-core/emscripten#18412
  • This Qt issue: https://bugreports.qt.io/browse/QTBUG-102827
• PortAudio is still lacking a Web Audio backend
  • See PortAudio/portaudio#887
  • The interaction between Web Audio's asynchrony and Qt's issues with asynchrony seem to bring up some more issues: emscripten-core/emscripten#18853 (comment)
    • Given that we already have to build Mixxx without -sASSERTIONS, any multiple in-flight async operations are effectively undefined behavior and manifest themselves in hard-to-debug failures at runtime (e.g. "unreachable" errors in the console, freezes, etc.)
    • Loading a track when the "Web Audio" backend is selected seems to also freeze the application, therefore it is disabled-by-default for now: fwcd/mixxx@21e45c5

Something to investigate would be whether we could replace -sASYNCIFY entirely with -sPROXY_TO_PTHREAD, i.e. move the "main" thread to a Web Worker where we can block synchronously. Unfortunately, there seem to be some complexities involved in making this work with Qt:

• https://forum.qt.io/topic/118350/proxy_to_pthread-support/3

We may have to check whether setting USE_PTHREADS=1 for Qt would help here (or whether that would be redundant because our vcpkg triplet already sets -pthread).

Another option would be the recently-added C++20 co_await integration, which uses native LLVM coroutines and thus hopefully shouldn't be bound to the same limitations as Asyncify: emscripten-core/emscripten#20413

Given that PortAudio exposes a C interface, I am not sure how well we could integrate C++ coroutines there, however.

Motivation

Being able to run Mixxx on the web would be pretty cool. Qt supports WebAssembly, we would however also have to compile all of the other dependencies. This would probably take some work, but should not be impossible.

We take a similar approach to the iOS port (#16) and use custom WASM branches for mixxx and vcpkg, along with an integration branch in m1xxx, then gradually upstream the required changes.

Porting the dependencies to WebAssembly

• Configure Qt correctly with GL ES 3.0 and without dbus
• Fix libflac, libmad and libmodplug
• Fix sleef build by using fftw as an alternative FFT backend
• Fix qttools build (or figure out how to remove non-host qttools dependency from qttranslations)
  • Upstream issue: microsoft/vcpkg#37106
  • Solution: We don't actually need qttools
• Fix undefined _qt_test_emscripten_version in Qt6WasmMacros.cmake during Mixxx configure
  • Patched out in fwcd/vcpkg@e80fbb4, though we may want to look for a better solution before we attempt to upstream this
• Update Qt to 6.6.2
  • This provides WASM stack traces in log messages and exceptions, which is really useful for debugging

Porting Mixxx to WebAssembly

• Figure out why WrapRt cannot be found when configuring Mixxx:

  Qt6Core could not be found because dependency WrapRt could not be found.
  

  Digging into FindWrapRt.cmake shows that the check_cxx_source_compiles failed, which (as build/CMakeFiles/CMakeConfigureLog.yaml revealed), failed due a missing clang-scan-deps binary:

  "CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND" -format=p1689 -- /opt/emsdk/upstream/emscripten/em++ -DHAVE_STDATOMIC_WITH_LIB  -fdiagnostics-color=auto  -std=gnu++20 -x c++ /Users/fredrik/git/m1xxx-wasm/mixxx/build/CMakeFiles/CMakeScratch/TryCompile-QIjor4/src.cxx -c -o CMakeFiles/cmTC_0948e.dir/src.cxx.o -MT CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi -MD -MF CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.d > CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.tmp && mv CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.tmp CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi
  /bin/sh: CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND: command not found
  ninja: build stopped: subcommand failed.
  

  Presumably we hit emscripten-core/emscripten#21042, possibly because Mixxx uses C++20 (this would also explain why vcpkg builds of Qt passed, despite running the same FindWrapRt check).
  • Fix the problem (a704a27)
• Solve this linker error

  wasm-ld: error: --shared-memory is disallowed by sqlite3.c.o because it was not compiled with 'atomics' or 'bulk-memory' features.
  

  The issue is likely that we have to compile (all?) our dependencies with -pthread (as per this discussion). This should in principle be possible via the triplet, just setting VCPKG_C(XX)_FLAGS does not work, however:
  microsoft/vcpkg#30108
  • Fixed by introducing new triplets (wasm32-emscripten-pthread(-release)) and setting

    set(ENV{EMCC_CFLAGS} "$ENV{EMCC_CFLAGS} -pthread")

Upstreaming the Mixxx patches

• mixxxdj/mixxx#12910
• mixxxdj/mixxx#12913
• mixxxdj/mixxx#12914
• mixxxdj/mixxx#12915
• mixxxdj/mixxx#12916
• mixxxdj/mixxx#12917
• mixxxdj/mixxx#12918
• mixxxdj/mixxx#12921
• mixxxdj/mixxx#12922
• mixxxdj/mixxx#12924
• mixxxdj/mixxx#12930
• mixxxdj/mixxx#12931
• mixxxdj/mixxx#12940
• mixxxdj/mixxx#12944
• mixxxdj/mixxx#12945
• mixxxdj/mixxx#12952

Upstreaming the vcpkg patches

to microsoft/vcpkg

• microsoft/vcpkg#37086
• microsoft/vcpkg#37088
• microsoft/vcpkg#37090
• microsoft/vcpkg#37101
• microsoft/vcpkg#37103
• microsoft/vcpkg#37105
• microsoft/vcpkg#37230

to mixxxdj/vcpkg

• mixxxdj/vcpkg#134
• mixxxdj/vcpkg#135
• mixxxdj/vcpkg#136
• mixxxdj/vcpkg#137
• mixxxdj/vcpkg#138
• mixxxdj/vcpkg#139
• mixxxdj/vcpkg#140
• mixxxdj/vcpkg#141

TBD:

• Cherry-pick the PortAudio patches (Web Audio support)
• Cherry-pick the taglib patch, i.e. either rebase it or wait until Mixxx fully supports Taglib 2.0:
  • mixxxdj/mixxx#12708
  • mixxxdj/mixxx#12790

to upstream projects

• PortAudio/portaudio#887

Nice to have

• CI for Emscripten/WebAssembly
  • GitHub Pages deployment: https://fwcd.dev/m1xxx
• Support for local files/persistence
  • See https://emscripten.org/docs/api_reference/Filesystem-API.html#filesystem-api-filesystems
  • We could use e.g. IDBFS to persist the .mixxx directory
  • For music, it would be best to let the user pick tracks from the host file system, if possible somehow
• Updating the install logic in CMakeLists to produce a proper archive when e.g. cpack -G TGZ is used
  • Currently we get a desktop-like file structure with bin etc.
  • Instead we want a flat directory with mixxx.{data,html,js,wasm,worker.js}, qtloader.js and qtlogo.svg
    • From there, emrun mixxx.html can be used to launch the web app locally

Useful resources

• https://doc.qt.io/qt-6/wasm.html

E.g. with the ability to specify a list of PRs to include. We could either model this by automatically updating a fork of Mixxx or by dynamically applying the merges during CI.

A slightly adjacent idea would be the ability to build with different vcpkg environments, e.g. different Qt versions. Since this is generally non-trivial to perform automatically, we would likely have to pin a custom vcpkg revision for that.

Hi,

Firstly, thanks for the work you've done making an m1 build available, it's really nice to have it running natively!

Unfortunately, I haven't been able to get my DVS setup working, the program does not detect the timecode signal coming from the audio interface. I suspect it might be because m1xxx does not request microphone access when starting up.

I didn't observe this behaviour with the official (intel) build, any idea what the issue could be? My best guesses are that the builds based off master do not currently support this, or alternatively, that the fact that this is an unofficial build restricts the access given to the program (launching the app requires going into system preferences and clicking "Open anyway"). I'm not a macOS expert, so any help with this would be amazing!

Now that the main branch can be built directly without patches (see #5), we would simply have to regularly update the mixxx submodule to point to the recentmost main commit.

Since we need the binary dependencies for building Mixxx already, we could provide it as an artifact too (this could be convenient for building Mixxx locally on Apple Silicon without having to build all the dependencies manually).

Caching artifacts with ccache (in conjunction with the GitHub Actions cache) would be cool.

This should likely be able to piggyback off most of the work on iOS support (#16), we might have to configure Mixxx to omit the storyboards when targeting tvOS.

This would be nice for use on a Raspberry Pi, especially given that from-source builds under QEMU take very long. We'd have to figure out whether building all the dependencies from scratch via vcpkg is the right approach or whether using the distribution-provided libraries would be better after all.

Currently the repo only builds the dependencies, not Mixxx itself yet. We should do so and perhaps figure out whether we could pass the (relatively few) patches to the CMake build files as command line arguments to avoid having to patch the mixxx tree itself (this would also make it easier to e.g. provide regularly updated nightly builds of Mixxx, at least while the dependencies don't change).

The release artifacts are currently overwritten even if the release already exists/the version hasn't changed. This leads to broken checksums in the Homebrew repository. We should fix this by e.g. not overwriting release assets or by automatically updating the Homebrew repository (e.g. via a repository_dispatch event? This would however muddle the clean separation between homebrew-fwcd polling for changes and this repository).

See this GitHub blog post. We should migrate to updating the env, as described in this doc.

We should clarify that we're building against glibc 2.35 since that's what Ubuntu 22.04 (Jammy) uses.

Many of the blockers mentioned in the README (in particular waveforms requiring a legacy widget to render, thus preventing an update to a newer Qt version) are no longer applicable as of

• mixxxdj/mixxx#10989
• mixxxdj/mixxx#11608

We should therefore update the description to reflect the current status and ideally make the link to the official ARM snapshots more prominent (especially once a stable ARM version is released).

There are also still a few minor issues with the official snapshots that this unofficial build doesn't have, in particular this signing/sandbox-related issue:

• mixxxdj/mixxx#11552

This would also help us get rid of the vars scripts.

This would however require automatically tracking Mixxx's dependencies, which might first be possible once they migrate to manifest mode.

For some reason this hash check is failing again

macOS 10.15 runners are deprecated and upstream did so too:

• mixxxdj/mixxx#4863

We should cherry-pick whatever we can use from main (Linux support probably won't work with our patched Qt 5.12).

A cron-scheduled workflow for building regular nightly versions of Mixxx would be cool (though we should tackle #5 first).

$HOME is not resolved in this context, so the current solution does not work:

We can, however, use ~ to resolve the directory, see:

• https://stackoverflow.com/questions/65801828/how-do-i-cache-an-installed-tool-between-runs-in-github-actions

#48 addresses this by adding ccache_path to the matrix with the correct paths. If that PR turns out to be a larger blocker, we might consider extracting that logic (including the step that saves the ccache even if the run fails).

Statically building Mixxx on Linux (using vcpkg) is not officially supported by upstream, but is still nice-to-have and exercises some corner cases that the standard builds using system packages don't.

Mixxx patches

• mixxxdj/mixxx#12284
• mixxxdj/mixxx#12291
• mixxxdj/mixxx#12292
• mixxxdj/mixxx#12294
• mixxxdj/mixxx#12295
• mixxxdj/mixxx#12297
• mixxxdj/mixxx#13085
• mixxxdj/mixxx#13087

vcpkg patches

to mixxxdj/vcpkg

• mixxxdj/vcpkg#95
• mixxxdj/vcpkg#112

Status

The ios-qt6 branch contains experimental forks of mixxx and vcpkg that support compiling Mixxx and its dependencies for iOS, i.e. for arm64-ios-release. Most changes to Mixxx have been upstreamed, vcpkg upstreaming is still in progress. iOS CI passes.

Documentation and general stuff

• Add instructions to README.md
• Build dependencies and Mixxx for iOS in CI

Porting the dependencies to iOS

• Fix the dependencies (running scripts/install-vcpkg-deps with the arguments given in the aforementioned instructions should pass)
  • Fix ffmpeg build by setting --disable-audiotoolbox
  • Skip libusb and hidapi for now
  • Add patched ports for iOS under vcpkg/overlay/ios
    • Fix mp3lame by setting --disable-frontend (otherwise the build would error with missing curses.h headers)
    • Fix portaudio by patching in an experimental iOS CoreAudio backend (source)
    • Fix portmidi by patching use of legacy Carbon APIs and unavailable CoreAudio APIs (e.g. by replacing the hosttime calls with the mach time APIs as suggested by this Q&A doc)
    • Disable rubberband due to licensing issues (GPL + App Store) and build issues
    • Patch Qt as needed (it builds but hasn't been tested yet)
      • Disable _debug suffix for libraries (not needed since we already place them in a /debug subfolder, additionally they cause the Mixxx build to fail as Qt5CoreConfig.cmake looks for unsuffixed libraries (e.g. libQt5Core.a instead of the actual libQt5Core_debug.a))
    • Update to Qt 6
      • Add gles3 feature to qtbase (otherwise the port is identical to upstream vcpkg)
      • Figure out the right combination of features (Notably opengl, gles2, gles3 and sql-sqlite, but not sql-psql)
    • Figure out if we can link Qt and all non-permissively/non-App Store-clause-licensed libraries dynamically or ideally exclude them/make them optional (this includes Rubberband, xwax, libkeyfinder and potentially others)
      • For libkeyfinder it might be worth asking the rightholders nicely for a relicensing under GPL + App Store clause, given how essential the library has become
    • Patch harfbuzz with iOS sdkroot
• Support building a patched version of Qt 5 too (as an alternative to Qt 6)
  • Build Mixxx for iOS 12
• Add support for targeting iOS simulator
  • Requires building for arm64-ios-simulator-release (instead of arm64-ios-release)
  • Needed fix to disable PCRE2 JIT

Porting Mixxx to iOS

• Successfully configure mixxx.xcodeproj with the cmake command in the README
• Use QIOSIntegrationPlugin
• Add option for disabling rubberband (RUBBERBAND)
  • Fix build issues (see CI logs, we probably want to test this extensively with the regular desktop macOS build)
  • Perhaps we can upstream this?
• Figure out potential OpenGL build issues (on iOS we only have OpenGL ES)
• Successfully build iOS target in generated Xcode project
• Successfully run Mixxx on an actual iOS device
• Fix missing precision qualifier in shader
• Bundle skins for small screen sizes:
  • LateNight Mini: A modified version of @dennisdebel's LateNight skin: https://github.com/dennisdebel/pi_dj
  • Pioneered: https://github.com/timewasternl/Pioneered
• Successfully load a track from within the sandbox (i.e. Mixxx's documents directory, which the user can access via the files app, e.g. to import music or to export recordings)
• Implement screen lock suspension for iOS
• Disable tool tips on iOS
• Default audio backend to patched PortAudio's "iOS Audio"
  • Figure out why we still don't get any sound when using speakers (headphones work, strangely)
• Investigate how to read files within the iOS sandbox (especially user-picked ones, e.g. via QFileChooser in MixxxMainWindow::slotFileLoadSongPlayer, which is invoked by File > Load Track to Deck ...)
  • Perhaps "import" files by always copying them to the sandbox/documents folder when loading them to a deck?
    • This would probably be required anyway to (permanently) add them to the library
• Investigate how much of the macOS sandboxing logic we can reuse
  • Bookmarking seems to be possible, but in a slightly different fashion, see
    • fwcd/mixxx@8e0a652
    • https://bugreports.qt.io/browse/QTBUG-67522
• Set dragMode to scrolling on scrollable views (library, preferences etc.)
• Make preferences (and other modals such as "about"?) full-screen
  • Ideally, these modals should probably be a sheet-presented view controllers, but it is unclear whether Qt supports this natively
•  Use MediaPlayer (instead of iTunesLibrary) framework to access music library on iOS
  • Figure out how we can make the sandbox play these tracks (the same issue as for files outside the sandbox)

Packaging Mixxx for iOS

• Bundle resources with iOS app
• Update qResourcePath logic to handle iOS app bundles (which use a flatter file structure than macOS bundles)
• Add iOS app icon (custom SVG, derived from the macOS icon without rounded corners + script for rendering it)
• Add custom Info.plist (including the permission for users to access Mixxx's documents directory via the Files app)
• Customize LaunchScreen to use Mixxx logo
• Investigate why the IOS variable is not automatically set by CMake when setting CMAKE_SYSTEM_NAME to iOS
  • This variable is first set on the project call. We check the vcpkg triplet instead now and set CMAKE_SYSTEM_NAME automatically as needed.

Upstreaming the Mixxx patches

• mixxxdj/mixxx#12646
• mixxxdj/mixxx#12649
• mixxxdj/mixxx#12650
• mixxxdj/mixxx#12661
• mixxxdj/mixxx#12662
• mixxxdj/mixxx#12663
• mixxxdj/mixxx#12664
• mixxxdj/mixxx#12665
• mixxxdj/mixxx#12666
• mixxxdj/mixxx#12672
• mixxxdj/mixxx#12673
• mixxxdj/mixxx#12674
• mixxxdj/mixxx#12675
• mixxxdj/mixxx#12676
• mixxxdj/mixxx#12684
• mixxxdj/mixxx#12687
• mixxxdj/mixxx#12688
• mixxxdj/mixxx#12689
• mixxxdj/mixxx#12690
• mixxxdj/mixxx#12698
• mixxxdj/mixxx#12714
• mixxxdj/mixxx#12716

TBD:

• Disable features (RUBBERBAND, HID, BATTERY, QTKEYCHAIN) for iOS in upstream CMakeLists and remove them from our README (and user presets as needed)
  • rubberband and qtkeychain-qt6 have been fixed, so we could investigate reenabling them
• The LateNight Mini skin
  • Should be discussed on Zulip first, though a general purpose "small screen" skin would probably be useful for other use cases too (e.g. Raspberry Pis)

Upstreaming the vcpkg patches

to microsoft/vcpkg

• microsoft/vcpkg#26978
• microsoft/vcpkg#36373
• microsoft/vcpkg#36407
• microsoft/vcpkg#36613
• microsoft/vcpkg#37054
• microsoft/vcpkg#37055
• microsoft/vcpkg#37059
• microsoft/vcpkg#37101

to mixxxdj/vcpkg

• mixxxdj/vcpkg#111
• mixxxdj/vcpkg#116
• mixxxdj/vcpkg#117
• mixxxdj/vcpkg#119
• mixxxdj/vcpkg#127
• mixxxdj/vcpkg#128
• mixxxdj/vcpkg#129
• mixxxdj/vcpkg#130
• mixxxdj/vcpkg#133
• mixxxdj/vcpkg#137

TBD:

• Upstream our updated vcpkg.json manifest
• Figure out a solution to the SDKROOT workarounds

to upstream projects

• PortAudio/portaudio#881
• PortMidi/portmidi#65

TBD:

• Find a way to get rid of the workaround of explicitly setting an SDKROOT for some ports

Ideas for future work

• Investigate replacing the native (deprecated) OpenGL ES framework with ANGLE, which runs on top of Metal
• Hot reloading for skins over the network

We should run xattr -cr Mixxx.app on the binary since otherwise macOS won't let us run the app by default due to an invalid signature:

Once the scripts from #9 are merged, we should update the README with a short description on how to build Mixxx locally on arm64 macOS.

We could e.g. generate a list of the added commits (perhaps only the merge commits/PRs) from the last release.

This would let us produce proper dependency archives (the current ones cannot really be used to compile Mixxx on arm64 hosts since the Qt tools are still built for x86_64 in CI).

I can only assume this is an oversight or for some other reason ? Also thanks for the builds !

Upstream did, so we should too: mixxxdj/vcpkg#80

See title, this variable from qt_port_hashes.cmake isn't being updated correctly.

i.e. use arm64-osx-min1100-release instead of arm64-osx-release and x64-osx-min1015-release instead of x64-osx-release etc. by default in scripts/install-vcpkg-deps. Both our and upstream's CI already uses these by explicitly specifying the corresponding triplets, but it would be nice to do this for local developers too to fix the corresponding linker warnings when building Mixxx.