Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
Space Fractal:
if a plugin authors ask for more spefics commands, let me known. We can allways create a v1.1 of the command list.
Btw do any use the coin commands (can also been detected as a juke command)?
If nobody need this, I grant to remove them..... Then I dont add that in MultiJuke.
Juke_config() is now finnaly added with a WindowID argument (that can been set to 0). I so need to if I can make a workaround, so the dosent break the OpenGL output, but that is now mine problem to fix. I asume it not a problem in VB6 with a seperate configs....
unclet:
1) I decided there is no need for a new JukeConfigure() routine to handle a plugin configuration request. Instead I just added a new command called "JUKE_PLUGIN_CONFIGURE", which has no values associated with it.
2) I changed all "@" separator characters to ">" characters since a "@" character is a valid filename character and this would interfere with the parsing of course .... thanks SpaceFractal!
3) I also added ">" characters to the end of all my command values so parsing each value will be easier since each supplied value will now have a trailing ">" character.
** Keep in mind if some jukebox software does not have all command value information then they do not need to be supplied with the command, but the command value format should remain constant (ie: the same number of ">" separator characters should always be used)
Example1 (album number "1135" and track number "002" is known when song starts):
--- Quote ---Juke_PluginCommand("JUKE_SONG_STARTED", "Dirty Pool>Stevie Ray Vaughn>Texas Flood>1135>002>Rock>200>
--- End quote ---
Example2 (album number "1135" and track number "002" is NOT known when song starts):
--- Quote ---Juke_PluginCommand("JUKE_SONG_STARTED", "Dirty Pool>Stevie Ray Vaughn>Texas Flood>>>Rock>200>
--- End quote ---
Basically, as long as the correct number of ">" separator characters are used then the plugin can parse the text the same exact way and then determine which data has been provided
4) I added "Party Lock" and "Attract Mode" commands
See my updated commands/values list below:
--- Quote ---int Juke_PluginCommand(String cmdName, String cmdValue)
cmdName cmdValue
-------------------------------------------------------------------------------
JUKE_APPLICATION_OPENED n/a
JUKE_APPLICATION_CLOSED n/a
JUKE_PLUGIN_CONFIGURE n/a
JUKE_SONG_STARTED name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_SONG_FINISHED n/a
JUKE_SONG_RESTARTED n/a
JUKE_SONG_SKIPPED n/a
JUKE_SONG_PAUSED n/a
JUKE_SONG_RESUMED n/a
JUKE_SONG_FAST_FWD_STARTED currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_FWD_FINISHED currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_REV_STARTED currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_REV_FINISHED currentPositionSecs>totalDurationSecs>
JUKE_SONG_PLAY_POSITION currentPositionSecs>totalDurationSecs>
JUKE_QUEUE_USER_ADD_SONG queuePos>name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_QUEUE_SYSTEM_ADD_SONG queuePos>name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_QUEUE_DELETE_SONG queuePos>
JUKE_QUEUE_MOVE_SONG oldQueuePos>newQueuePos>
JUKE_QUEUE_CLEARED n/a
JUKE_VOLUME_CHANGE up/down/set>volumeLevel>
JUKE_VOLUME_MUTE_STATUS on/off>
JUKE_VOLUME_RANGE minVolumeLevel>maxVolumeLevel>
JUKE_ENTER_ALBUM_NUM_DIGIT digit(0-9)>
JUKE_ENTER_TRACK_NUM_DIGIT digit(0-9)>
JUKE_ATTRACT_MODE onActive/onNotActive/off>
JUKE_PARTY_LOCK on/off>
--- End quote ---
In my mind, the "standardization" which should occur is coming up with command name/value strings which all jukebox software should adhere to "if" they wish to implement the command at all.
For example, Barcrest prefers to only implement the song start, song finish, configure and attract mode commands only. No problem at all .... however, if he agreed to use my approach then he would at least use the "standardized" command names/values:
--- Quote ---JUKE_PLUGIN_CONFIGURE n/a
JUKE_SONG_STARTED name>artist>album>albumNum>trackNum>totalDurationSecs>
JUKE_SONG_FINISHED n/a
JUKE_ATTRACT_MODE onActive/onNotActive/off>
--- End quote ---
Again, I would not expect anyone to implement every command name/value, but it would be nice to use one from a standard defining list if you were going to use one ..... instead of coming up with a different one on your own.
Space Fractal:
you going to create you own standard? Or is is just a internal parser before sent to the Jukebox functions?
If it the last one, remember to backslash any titles or such that contain @, or your parse would break.
I think you can use that parser as internal, but plugin writers can not use any of them, since it would been very compliced for the pluginwriter to support that. The problem is they never known wich command that is used by a JB software....
unclet:
I like to keep it very simple and like my approach best so I might stick with it. There is one routine (ie: Juke_PluginCommand() routine) which takes two parameters (command name and command value) and that is it. It is very easy to add new command names/values, it is easy to expand existing command names/values and it is easy to understand and implement.
I like "easy" since I do not plan on spending a lot of time on this. I would like to use something that any plugin author can understand and implement easily thus not having a need for me to constantly explain how to use certain commands and such. Basically, I would like to implement this plugin stuff and then have people be able to figure out how to use it on their own.
As for what a plugin author would create ..... I really have no idea and really do not care, but I would like to provide them with as many events as possible to let their imagination run wild. If they would like to recreate their own personal software display instead of looking at my jukebox display screen .... then that is fine with me ..... no problem. With the commands I supply they should be able to replicate the song queue as well as the currently playing song information along with certain song controls (play, skip, mute, etc...).
I will not be supplying commands for "everything" my software can do since I think that would be overkill, but things I think might be incorporated into a plugin I will provide events.
Good point about "@" character being able to be the text ...... I changed the separator character to ">" instead .... thanks.
Space Fractal:
sorry to edit my last post (did you read that, if that, forgot it).
The only problem is painfully for the plugin writer to known all commands used, since they never known which command is used, and then can come very fast out of date.
Hence I used real functions with no parser for the plugin. That is much easier for Plugin Writer to use.
Easy for Jukebox Author, but really hard for plugin writers, or did I misforstood something...
______
Plugins is NOT intended to create a new software based on a existing software with same functions...
They are just small feedback things.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version