Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
Space Fractal:
This projects seen to been dead since we now have diffecent standards?
I seen UncleT have moved into his own system, so a standard can not been created.
I really hope you write a wrapper as well to sync to the main SDK listed in the first post.
Ny now I wont comment any longer before I hear others what now.
unclet:
Seems pretty easy to me if I was a plugin writer.
Create the Juke_PluginCommand() routine (see below). When the routine is called, then determine which command name is provided, parse the value string appropriately (only if required) and then perform your plugin function.
--- Quote ---int Juke_PluginCommand(String cmdName, String cmdValue)
{
switch(cmdName)
{
case "JUKE_APPLICATION_OPENED":
//execute plugin code
break;
case "JUKE_APPLICATION_CLOSED":
//execute plugin code
break;
case "JUKE_PLUGIN_CONFIGURE":
//execute plugin code
break;
case "JUKE_SONG_STARTED":
//parse 6 values from cmdValue string
//execute plugin code
break;
case "JUKE_SONG_FINISHED":
//execute plugin code
break;
case "JUKE_SONG_RESTARTED":
//execute plugin code
break;
case "JUKE_SONG_SKIPPED":
//execute plugin code
break;
case "JUKE_SONG_PAUSED":
//execute plugin code
break;
case "JUKE_SONG_RESUMED":
//execute plugin code
break;
case "JUKE_SONG_FAST_FWD_STARTED":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_SONG_FAST_FWD_FINISHED":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_SONG_FAST_REV_STARTED":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_SONG_FAST_REV_FINISHED":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_SONG_PLAY_POSITION":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_QUEUE_USER_ADD_SONG":
//parse 7 values from cmdValue string
//execute plugin code
break;
case "JUKE_QUEUE_SYSTEM_ADD_SONG":
//parse 7 values from cmdValue string
//execute plugin code
break;
case "JUKE_QUEUE_DELETE_SONG":
//parse 1 value from cmdValue string
//execute plugin code
break;
case "JUKE_QUEUE_MOVE_SONG":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_QUEUE_CLEARED":
break;
case "JUKE_VOLUME_CHANGE":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_VOLUME_MUTE_STATUS":
//parse 1 value from cmdValue string
//execute plugin code
break;
case "JUKE_VOLUME_RANGE":
//parse 2 values from cmdValue string
//execute plugin code
break;
case "JUKE_ENTER_ALBUM_NUM_DIGIT":
//parse 1 value from cmdValue string
//execute plugin code
break;
case "JUKE_ENTER_TRACK_NUM_DIGIT":
//parse 1 value from cmdValue string
//execute plugin code
break;
case "JUKE_ATTRACT_MODE":
//parse 1 value from cmdValue string
//execute plugin code
break;
case "JUKE_PARTY_LOCK":
//parse 1 value from cmdValue string
//execute plugin code
break;
}
return 1;
}
--- End quote ---
Why do you think these commands will be obsolete and that the plugin author will be constantly trying to keep up with newer versions of these commands?
I understand some new commands might be created/added and even some existing commands might be updated to have more "command value" text associated with them in the future, but that should not cause that many problems.
In fact, this is what I am going to do. All my "command names" are going to have a "version" number associated with them (see my next post).
unclet:
There is a possibility a "command name" might be updated to include additional "command value" text with it in the future an that plugins which have been released might not have been updated to reflect this change. As a result, a version number could be added to each command string. Once a particular command name version has been implemented in the software then it should never be removed or changed. If the command is updated in the future to add additional data then a new command name (with increased version) would be created and implemented in the code. This way, both versions of the command will constantly be supported by the software.
For example
Lets say the current JUKE_SONG_START command did not have "totalDuration" value but it was added in the future. This would result in 2 versions of the command:
--- Quote ---JUKE_SONG_STARTED_1.0 name>artist>album>albumNum>trackNum>genre>
JUKE_SONG_STARTED_1.1 name>artist>album>albumNum>trackNum>genre>totalDuration>
--- End quote ---
Note1: I do not see this happening a lot, so maintaining multiple versions of the same command in the software should not a real problem. Just means two calls are made to the "Juke_PluginCommand()" routine in a row instead of only one.
Note2: I really do not need to add versions to each defined command as long as the plugin only parses the correct number of text values from the "command value" string by only parsing each value up to the next trailing ">" separator character only. Basically, any additional values which have been added to the end of the command value text string in the future should simply be ignored and cause no real problem.
Now, should I consider all plugins to parse corrcetly, or should I actually use the version numbering commands shown below? Hmmm .....
--- Quote ---int Juke_PluginCommand(String cmdName, String cmdValue)
cmdName cmdValue
-------------------------------------------------------------------------------
JUKE_APPLICATION_OPENED_1.0 n/a
JUKE_APPLICATION_CLOSED_1.0 n/a
JUKE_PLUGIN_CONFIGURE_1.0 n/a
JUKE_SONG_STARTED_1.0 name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_SONG_FINISHED_1.0 n/a
JUKE_SONG_RESTARTED_1.0 n/a
JUKE_SONG_SKIPPED_1.0 n/a
JUKE_SONG_PAUSED_1.0 n/a
JUKE_SONG_RESUMED_1.0 n/a
JUKE_SONG_FASTFWD_STARTED_1.0 currentPositionSecs>totalDuration>
JUKE_SONG_FASTFWD_FINISHED_1.0 currentPositionSecs>totalDuration>
JUKE_SONG_FASTREV_STARTED_1.0 currentPositionSecs>totalDuration>
JUKE_SONG_FASTREV_FINISHED_1.0 currentPositionSecs>totalDuration>
JUKE_SONG_PLAY_POSITION_1.0 currentPositionSecs>totalDuration>
JUKE_QUEUE_USER_ADD_SONG_1.0 queuePos>name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_QUEUE_SYSTEM_ADD_SONG_1.0 queuePos>name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_QUEUE_DELETE_SONG_1.0 queuePos>
JUKE_QUEUE_MOVE_SONG_1.0 oldQueuePos>newQueuePos>
JUKE_QUEUE_CLEARED_1.0 n/a
JUKE_VOLUME_CHANGE_1.0 up/down/set>volumeLevel>
JUKE_VOLUME_MUTE_STATUS_1.0 on/off>
JUKE_VOLUME_RANGE_1.0 minVolumeLevel>maxVolumeLevel>
JUKE_ENTER_ALBUM_NUM_DIGIT_1.0 digit(0-9)>
JUKE_ENTER_TRACK_NUM_DIGIT_1.0 digit(0-9)>
JUKE_ATTRACT_MODE_1.0 onActive/onNotActive/off>
JUKE_PARTY_LOCK_1.0 on/off>
--- End quote ---
Space Fractal:
The only problem can a plugin writers want to known which commands that would been used in ALL software?
Example I have not a ATTRACT mode but I have a SCREENSAVER, but would the plugin writer ever known about it (example if they are fan of a other application)?
Otherwice, I have just contacted LoadMan and HeadKaze what we do now, since none of us can agree a standard, It just because they before have wrote plugins (MALA example) and have lots of knownable about it.
____
seen your edited text:
Let see what LoadMan mean about it, and see what he thinks as a commen plugin writer (I also wanted to write a few). I through I finalized SDK from the very first post (as I changed over the time)....
unclet:
--- Quote ---The only problem can a plugin writers want to known which commands that would been used in ALL software?
--- End quote ---
On my "plugin" page, the user can click a button to display all plugin commands my software supports along with an explanation of each. Now, as I mentioned before, in a more centrally located place (ie: Jukebox Wiki, PlugMyJuke website, etc..) ALL of the plugin commands should be listed and for each command, a description should be provided along with which jukebox software supports it.
--- Quote ---Example I have not a ATTRACT mode but I have a SCREENSAVER, but would the plugin writer ever known about it (example if they are fan of a other application)?
--- End quote ---
The word "attract" is used to simply indicate that the jukebox has some sort of way to try to "attract" a user to the jukebox machine when no songs are playing (ie: page flipping automatically, having sounds heard, lights flash, etc...) It does not mean your software actually has an option called "AttractMode" in it. (Same thing relates to "PartyMode" .... does not mean a jukebox has an option called "PartyMode" in it ..... it just means the jukebox software offers a way of locking party guests out of your configuration screens or from doing other stuff you do not want beer drinking hackers to try to do :P)
Based on my format, your software would still use the "JUKE_ATTRACT_MODE" command. The documented description of the "JUKE_ATTRACT_MODE" command would simply inform the plugin author that this command relates to "MultiJuke's screensaver function", "UncleT's Jukebox page flipping attract mode function", etc...., etc....
Basically, the plugin author will understand what each command does based on their reading of the each command description which should definitely occur before they start coding their plugin.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version