Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
unclet:
I think I will wait until you guys figure out everything you want and get it working and then I can have a look at it and try to implement what I can. I am not too crazy about using one common wrapper to interface and gather information for each plugin. If something needs to be changed, then I have no control over editting this wrapper function. Also, I am not sure how all ofthese routines should be used correctly so I might wait until people get all of this stuff working before I jump in.
--- Quote ---This will sort of work, I thought this thread was to sort out the compulsary options only.... Anything else can then be added individually with any plugin using those will being jukebox specific
--- End quote ---
This is exactly my point ....... if we can standardize some of these "anything else" routines which are not yet common to all software applications then when the functionaility is added to the software at a later date, then the standardized routine interface can be used instead of having new routines added individually.
If a brand new routine is required which is not yet used by any other jukebox application then the jukebox software author can document the new routine interface in the Jukebox Wiki (for example). Then as other jukebox software adds this functionality, then they can use this new standardized routine instead of making one which is jukebox specific
Anyway, I think I might be slowing the progress down in this thread a bit, so I will sit back and watch for awhile to see how it goes. In the meantime I will work more on my own jukebox build ..... need to get that done now before I spend more time on this new activity.
Space Fractal:
--- Quote from: unclet on January 05, 2008, 08:23:22 pm ---I think I will wait until you guys figure out everything you want and get it working and then I can have a look at it and try to implement what I can. I am not too crazy about using one common wrapper to interface and gather information for each plugin. If something needs to be changed, then I have no control over editting this wrapper function. Also, I am not sure how all ofthese routines should be used correctly so I might wait until people get all of this stuff working before I jump in.
--- Quote ---This will sort of work, I thought this thread was to sort out the compulsary options only.... Anything else can then be added individually with any plugin using those will being jukebox specific
--- End quote ---
This is exactly my point ....... if we can standardize some of these "anything else" routines which are not yet common to all software applications then when the functionaility is added to the software at a later date, then the standardized routine interface can be used instead of having new routines added individually.
If a brand new routine is required which is not yet used by any other jukebox application then the jukebox software author can document the new routine interface in the Jukebox Wiki (for example). Then as other jukebox software adds this functionality, then they can use this new standardized routine instead of making one which is jukebox specific
Anyway, I think I might be slowing the progress down in this thread a bit, so I will sit back and watch for awhile to see how it goes. In the meantime I will work more on my own jukebox build ..... need to get that done now before I spend more time on this new activity.
--- End quote ---
Not all commands is even need in MultiJuke, one of them was a ideas by Barcrest. I have not planing to support Juke_SongTags() by my self, because I do not use videos. Pretty sure it would work by your software, if you a day want id3 tag support using a plugin.
And example MultiJuke and your software is different how the queue can been handled. Multijuke can insert a whole album, auto added by system, but yours can manipulate queue directly (not used by MultiJuke). Here I got the idea to use a resubmit system, that can suit its all.
These brown marked commands is not important ones to been used, but they can been very useful. Im are pretty sure any Plugin Writes make sure its would works with all software, even they now not all brown marked commands is not used by a software. Some plugins might do speciel on these commands alone, hence they would write about it (tagging example).
I guess I even got all your requests in the SDK (queue changes and remote controlling).
If you are not sure how a command should been used, let me know. I might wrote some mistakes in the first post.
Of course I can still update the wrapper with new commands, even after version 1.0 and I have even included the source code as well to been ported to other languages. That dll is completly open source....
Oterwhice, Do you have other requests?
unclet:
I think you are doing a fine job .... it is just hard for me to spend a lot of time on this right now. I will see how it all works when everything is designed and then add stuff in my software as well.
headkaze:
I really don't see the point to the commands.txt file. If the Jukebox never sends the command to the plugin it will never receive it therefore there is no support it. If a Jukebox does support the command it will be sent it and the plugin can do something with it. Why does the plugin need to know which commands the jukebox supports? I like unclet's idea of having a list of standard commands and just send over the ones you use.
They could be either constant's/enums that represent numbers or just string constants. Strings would probably be easier.
Eg. (from unclets post)
JUKE_PLAY
JUKE_VOLUME_UP
JUKE_VOLUME_DOWN
JUKE_PARTY_LOCK_ON
JUKE_PARTY_LOCK_OFF
JUKE_MUTE_ON
JUKE_MUTE_OFF
Since they are just strings you can have unique commands for your juke and commands that are supported by most jukes.
Space Fractal:
I removed the commands.txt and create a function instead that does the same. I update the SDK to have some mean with these commands.
I would want to create a remote plugin with full support of all commands constain in a software. Some commands might have a on/off commands (Juke Party example).
In MultiJuke I example have 4 action commands that does defficent things, that would been good for commanddisable and commandenable events for Ledwiz control.
In DWJukebox example in the singles view, that last buttons light could been disabled off if the list of songs is scrolled to the bottom (or disable lights on other letters if I pressed D button example).....
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version