Is there a Mixxx plugin/extension API similar to Virtual DJ's plugin API?

Asked by Ryan Smith

Is there a Mixxx plugin/extension API similar to Virtual DJ's plugin API? I was doing some research on DJ application APIs, and I came across Virtual DJ's plugin API here (https://www.virtualdj.com/wiki/Developers.html). Their plugin API (among other things) allows users to query and set values in VDJ's control system.

I found the Mixxx control system here (https://www.mixxx.org/wiki/doku.php/mixxxcontrols), but I was unable to locate documentation about how to query this from a plugin or another application. Does such an API exist?

If so, how would I go about writing a plugin, framework, or other construct that allows me to query information from the Mixxx control system and pass it to another application? If not, where might I look in the Mixxx source to add a patch to the same effect?

Background: I am starting a project to rewrite my sequenced light controller (similar to Vixen [http://www.vixenlights.com/] or Light-O-Rama [http://www1.lightorama.com/]) to remove a number of issues in its programming. Programs like this store a sequence of events or an array of channel values, and play them over a protocol like DMX or MIDI synchronized to a song. A medium to large-scale example of a show like this would be this youtube video [https://www.youtube.com/watch?v=z5dfpe_-Lgg], which utilized Light-O-Rama.

Right now, my program uses LibVLC for the audio playback. It loads a light sequence from a file (written by Vixen 2), determines which audio file to play, and tells LibVLC to load and play that audio file. While the song is playing, the program checks VLC's playhead position on a high-frequency loop (it needs to query the playhead position at least every 25ms to match control resolution with DMX), calculates a position in the sequence from LibVLC's playhead information, and outputs the data at the calculated position to DMX, effectively using VLC as a stopwatch to time out the file. That way, the sequence is always pointing at the same place the audio player is and they never go out of sync.

Since the sequence execution engine only requires minimal (if high frequency) integration with the audio engine, it would be easy to use different audio APIs as plugins in my program. My idea for integration with Mixxx is for the plugin on Mixxx's side to push the current file metadata (artist, track, filename), playposition, track_samples, and volume (including crossfader) for each deck over a pipe or socket to my program, which would determine which sequence file to run based on the metadata, and sync to Mixxx using playposition and track_samples (it's basically the same thing I already do with VLC, except this time it's communicating with Mixxx instead). To reduce the data and processing footprint, the metadata and track_samples would get pushed on deck changes, and the playposition would get pushed to or queried by my program every loop. Because my program does not rely on internal timers to calculate sequence position, it could keep lock-step with Mixxx, even if the audio is being scratched, spun backward, or having its speed mangled.

Ever since I discovered light sequencing, I have always wanted to develop a method of integrating some sort of a DJ control into it.

Love the project, keep up the amazing work!

Question information

Language:
English Edit question
Status:
Solved
For:
Mixxx Edit question
Assignee:
RJ Skerry-Ryan Edit question
Solved by:
Daniel Schürmann
Solved:
Last query:
Last reply:
Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) said :
#1

Not exactly. The closest thing we currently have is the controller subsystem, where your application could converse with Mixxx via MIDI or HID. But that doesn't yet support non-numeric data like track names and such (though we have wanted to add it for a long time.)

Because of Qt's signal/slot mechanism, it shouldn't be too terribly difficult to create a new class that instantiated ControlProxies then connected slots that communicated via the API to their signals for the Controls you were interested in. (And vice-versa: when data comes in via the API, the class would signal the applicable ControlProxy so the rest of Mixxx reacts to it accordingly.) The only downside to that is if new ones are added in the future, they'd have to be manually added to your class as well.

In fact, if you do this carefully, we may be able to use it as the basis for a replacement of the existing Controller subsystem where the ControlProxy QObjects are exposed to QScript functions directly...

I'm nowhere near an expert on Mixxx's architecture though, more just thinking out loud. RJ Ryan would be the best to offer ideas here.

Revision history for this message
Best Daniel Schürmann (daschuer) said :
#2

The good news: Mixxx is free and open source so there is no need for an extension API :-P

Back to serious mode:

We had a very similar request of Jakob Braun in:
https://www.mixxx.org/forums/viewtopic.php?f=6&t=8003

Here is the working result:
https://github.com/jakobbraun/mixxx/commits/osc_support

Unfortunately he never did a pull request.

OSC is a thin layer on top of UDP and TCP and should fit exactly to your needs.

I would love to see the star wars house driven by Mixxx :-)

Revision history for this message
Daniel Schürmann (daschuer) said :
#3

I would be happy to give you a helping hand to continue the osc_support branch.

Revision history for this message
Ryan Smith (computergeek125) said :
#4

All right! You guys are awesome. I got a few projects I have to finish up first, but I'll get to work on this later this summer. Hopefully, if all goes well with the other projects, I can get this working by the end of the year.

Revision history for this message
Ryan Smith (computergeek125) said :
#5

Thanks Daniel Schürmann, that solved my question.

Revision history for this message
Ryan Smith (computergeek125) said :
#6

Although, since this is my first foray into Mixxx development, do you have any pointers for where to start working on the osc_support branch?

Revision history for this message
Daniel Schürmann (daschuer) said :
#7

https://www.mixxx.org/wiki/doku.php/bugfix_workflow is a good start to read, apart from the links above.
A first step could be to check out the osc_support branch build ant test it, using the OSC command line tools.

Don't forget to ask for help ;-)

By the way: on which OS are you?

Revision history for this message
Ryan Smith (computergeek125) said :
#8

My primary machine is a dual-boot macOS 10.12.6 Beta (16G16b) / Windows 10 Insider Preview plus a few Linux VMs. I personally prefer Unix-like OSes, so it looks like that's going to work out since you guys work with Linux a lot. I'll beef up one of my Linux VMs so that it can compile faster.

I read through the link (and followed a bunch of references), so I'm starting to get an idea of where everything fits together. We might even be able to partially solve https://bugs.launchpad.net/mixxx/+bug/1282127: you could use the time code from this to power a lyric display.

Revision history for this message
Daniel Schürmann (daschuer) said :
#9

That sound great! I am looking forward ... B-)

Revision history for this message
Be (be.ing) said :
#10

Have you looked at the MIDI clock output script included in Mixxx?
https://mixxx.org/wiki/doku.php/midi_clock_output