AutoDJ play as fast as possible with start/stop triggers for recording

[nvdl]

Feature Description

Mixxx 2.4.0-beta
Git Version: 2.4-beta-347-gc323d0cd54
Platform: Linux x86_64
OS: Debian 11

It is very exciting to use the synchronized cross-fading of AutoDJ to create mixes.

However, I have found two issues that may already have solutions unknown to me.

1. If I want to record the "performance", there is no way to play as fast as possible to get the final media file. Now, I just play the playlist and come back when it is about to be over.
2. There is no way to start the recording exactly when the "performance" starts (to prevent silence at the beginning). Same applies to stopping as well.

It would be nice to:

1. Play as fast as possibly to get the final media file (while muting the output to the hardware).
2. Make recording start/stop support triggers with configurable delay(s). The recording starts/stops after the trigger and the configured delay(s).

[daschuer]

For 1. I recommend to just delete the tracks form the auto DH before the two you want to practice with. Will this work or did I miss something?

The 2. is an aspect of #6796

[Swiftb0y]

If I want to record the "performance", there is no way to play as fast as possible to get the final media file.

I think this refers to essentially freewheeling mixxx, where the audio engine runs at 100% throughput instead of realtime to "render" (similar to a DAW) the mixxx out.

[nvdl]

Yes, I was referring to the free wheeling mode.

Have you toyed with the idea of exposing an API to be able to write plug-ins?

For example, the triggers can come from the core of mixxx while a plug-in (let's say written in Python) handles the needed responses specific to that plugin.

In this way contributions can be faster without changing the core all the time for the new wishes.

[daschuer]

Ah, got it. Since this covers two issues, can you file another one and change the title of this bug to the other topic?

Mixxx can already run without sound card using the network clock in hardware preferences. A first step would be to remove

mixxx/src/soundio/sounddevicenetwork.cpp

Line 543 in 59ca3a2

m_pThread->usleep_(sleepUs);

There are more timers that need to be fast forward. This avoids that Mixxx dropping frames to catch up.

[nvdl]

Sorry, it is not clear to me.

can you file another one and change the title of this bug to the other topic?

Yes, file another one about which issue?
Which bug are you mentioning?

From my perspective, there are two feature requests:

1. Free wheeling (recording)
2. AutoDJ triggers (signals -> slots)

[ronso0]

Please file a new one for

Make recording start/stop support triggers with configurable delay(s). The recording starts/stops after the trigger and the configured delay(s).

Or maybe, to keep it simple:
"Allow to start Recording with first sound"
We can reuse the 'first audible sound' threshold from the analyzer.

[nvdl]

#12696

[daschuer]

Do you have interest to dive into coding? This project can be done by try and error. Poking around until it is working.

I see no blocker that prevents it from work, but findinding all bits that need to be adjusted might be a challenge.

The first step is building Mixxx from source.
Do you have interest, do you need help?

[nvdl]

I am already building it from the source.

Have joined the Zulip chat as "nvd".

I can start with the code work but where to ask for questions?
Zulip or here?

I need some exposure about the architecture.

[ronso0]

If you need help with building Mixxx you better ask on Zulip.
I think as soon as you get started with the actual implementation just open a Draft Pull request, IMO it's easier to discuss specifc code here on GH.