-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scripted auto dj #7102
Comments
Commented by: daschuer Hi Jan, thank you for your grate proposal. I would be realy happy If we make Mixxx more felxible in how to sellect new tracks. While a scripting interface is surely the most powerfull solution, it will be also most dificult to use. But IHMO it is a fine addition to the other approches curently under development. There is:
For now this would be fit the best ontop of auto-dj-crates. It sound you have the skills to do important pats of the project yourselfe. If so and you can offer some of your spare time, I would be happy to give you helping Hand to start. So do not hasitate to asks your yestions at mixxx-devel or at #mixxx on freenode. http://www.mixxx.org/get-involved/ It sound that you have the right. Kind regards, Daniel |
Commented by: lodrovic Hi Daniel, Although i do not have enough spare time for engaging with the project, i will take a closer look to learn more and maybe then see if i can help and how. I haven't seen any of the code as of yet, so this is just a guess on how it could work. In preferences there could be a field to set the full path to the external script. Then, next to the 'enable auto-dj' button, there could be a toggle button to enable/disable the external script usage. When enabled, the auto-dj would execute the script whenever it needs to load a deck and use the script's output as a full path to the file to load, thus bypassing any other means of finding a file to load into the deck. So my guess is that an if statement checking if scripted feeding of decks is enabled should suffice. If not enabled, it continues to any other ways of loading the deck, but if enabled it executes the external script instead, gets the file path from the script's output and loads the file into the deck. If the path is invalid or if it fails to load, the external script option should be disabled (turn the toggle button off), thus going back to feeding the decks through any other means available (i.e. crates, library, etc) to prevent entering an endless loop where it keeps executing the script and failing to load a file. Of course, this may not be that simple to implement because of the different platforms and how scripts are executed on each of them. Best regards, |
Commented by: daschuer A first step is done here: |
Reported by: lodrovic
Date: 2013-07-08T18:50:03Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1199105
Tags: autodj
An option to get auto-dj to query an external script for the file to be loaded into the deck, instead of getting it from the internal auto-dj queue. When enabled, the specified user defined external script would be executed whenever the auto-dj needs to load a new file into a deck. Whatever the script prints to stdout would be treated as a full path and if the file exists would be loaded into the deck. If the file does not exist or fails to load, the auto-dj should disable itself. It would be up to the external script to ensure its output is a valid path to a supported file.
ezstream has a similar feature, and it allows me to create web interfaces to manage the queue and then have a script simply query this queue whenever ezstream finishes streaming the current track and needs a new one. Although Mixxx itself could eventually provide tools to manage its auto-dj queue externally (e.g. through command line options), i think it would be much more effective to simply execute a user defined script and use its output to load the next track, just like ezstream does.
With this feature, users can developed their own web interface, allowing for the auto dj queue to be controlled remotely, even from a mobile phone, while keeping Mixxx in the background (i.e. not directly exposed to the network), behind the web server.
The text was updated successfully, but these errors were encountered: