Mixxx status files + settings

[Eve00000]

Statusfile:
If checked, a Statusfile will be created in map with the custom controllermappings.
A statusfile is a javascriptfile that contains

• Track-Artist
• Track-Title
• Time
  The Artist and Title can be used for display on the controller-screen.
  The time-field can be used in case you want to control 4 decks with a 2 deck-
  controller. Mixxx reloads the controller mapping each time something changes.
  When a new track is loaded and statusfiles are written, the decks switch to 1 and 2.
  With the time field you can set the focus on the last manipulated decjk (1-2 and 3-4).

So if you ejected a track in deck 4, the focus can stay on deck 4 to load another track.
The statusfiles need to be included in the header of the xml-file.

Statusfiles are named:
Status[ChannelX].js, Status[ChannelY].js ...
Status[SamplerX].js, Status[SamplerY].js ...

The contents:
var TrackDeckX = {
Artist : "trackartist",
Title : "tracktitle",
Time : "12:52:44",
};

In the beginning of the controller.js file you can load the contents of the Statusfiles
in arrays to use them for displaying.

[JoergAtGithub]

Creating a JavaScript file with fixed artist/song title, which is automatically reloaded during a DJ session when it's changed is not the proper way to implement this.
But there is clearly the need to get such strings into controller mapping scripts, because there are controllers with alphanumeric displays controlled by MIDI-Sysex commands.
The correct way to implement this, would be to create a variant of our control objects (CO) with type string. Than you could implement something like [Channel1],song_title or [Channel1],artist

[Eve00000]

Thank you, Joerg, for your reaction ,
but fjieuw , your reaction was rather short .

I've made quiet a progression in the Mixxx-world.
I started with getting the info out of the logfiles then I used OCR ...) It was also my first idea to get the data into the mapping in the same way as duration, samples ... But that wasn't available and as I understood it should not be made available to the controller-engine. Getting the data into my controller is not the only reason why I want status files (I called it that way from the early start), as I always combined computers with my dj-ing (special mixes, samples, visuals, artist&title-marquee )

When I started about getting the status-info in the decks (artist - title) to get it in my controller (#12823 I got the hint/tip: "I think parsing the log is a okayish but brittle hack, a more robust / easier solution would be to write the state changes to individual files (per deck)." and the link to a PR #3483 (expose current track metadata to external APIs).
So I've been swimming and diving into the code (almost drowned) for many, many hours. There was also the discussion about 'exposing metadata' like for midi for light, Listenbrains, MPris, broadcasting live metadata ...).

That is why I made my status-files solution, and I'm quiet proud on it, for being a Mixxx/C++ nitwit 2 months ago I achieved a working solution. There are many parts / features / possible improvements in Mixxx that need a good and definitive solution or rewriting, but they get only attention when someone puts his/hers teeth in it. It's a persons motivation to have a certain feature that makes evolution and progression. The trackdata-route has been chosen and abandoned many times.

This is a next step, as you mentioned it it's a feature that is wanted by DJ's but also by people making radio-shows, podcast, lighting engineers... because they can use it to share information. When the information should come from the control object the info cannot be used in websites or send to lightingcontrollers (adapted light show for that song) or as information for the public.

It is defenitively not an 'OR' (control object or statusfiles) , it should be an 'AND', and that is way this should be seen as a
next step,
It contains also:

• a solution concerning deck switching (1-3 & 2-4) with the timefield in it.
• also a (WIP) in linking the url of coverart in order to make it visible (projection) for the audience
• making an interactive requests / playlist for the audiance (in combination with the NowPlaying-feature the statusfile can trigger an alert for people who made the request)

I don't see it as a closed chapter, so I hope you want to explain me how and help me with obtaining the control objects for [ChannelX],song_title and [ChannelX],artist.

Kind regards.

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.

[acolombier]

With the WIP on OSC, is that something we want to keep? If yes, this might need a bit of cleanup before it can be reviewed. Marking it as draft for now, but feel free to mark it ready once we should give it another go!

[Eve00000]

I originally created these to get trackartist/title to my controller.
I don't use the for that anymore, They are perdectlt fine to update a website or public bulletin board or ... whatever.
I linked these pr to different people who need playing a loaded track.
OSC communicates only with OSC-capable devices.
Draft is OK.

[acolombier]

They are perdectlt fine to update a website or public bulletin board or ... whatever

My worry is introducing yet another bespoke API to maintain here. A website will likely have to implement a backend to deserialise this file and the text format will likely cause trouble. There is also many field I would imaging would be lacking for this usecase (e.g artwork)

OSC communicates only with OSC-capable devices.

My point is, if somebody wants to create a bespoke artifact from Mixxx state (e.g a text file with some selected metadata), they should build on top of the OSC interface, instead of embedding logic into the Mixxx directly (Mixxx <-> OSC <-> Logic <-> Consumer, rather than Mixxx <-> Logic <-> Consumer). Of course, nothing wrong in prototyping something on Mixxx directly, but I don't see this being something we would want to merge