Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
unclet:
1) I do not like having to keep a queue.txt text file up to date to be synchronized with the queue contents. I wonder whether exporting all the queue contents is important at all? Do you think plugin authors really want to maintain what is in the queue and not?
2) Why do we need a Juke_Initialize() routine? I think we only need two routines:
Juke_GetPluginInfo()
Juke_PluginCommand()
3) I am thinking that having separate commands for each action is worth while now. It is more clear to me since all commands are not cramed into one format.
I have not looked through all your commands yet I will do that later. I will spend time tonight coming up with my proposal as well and see if we can combine both of our thoughts.
Please confirm whether you still believe we need to inform the plugin with a command list and whether you agree the queue.txt file can be omitted.
Space Fractal:
The most problem is with a default set, do other software out here use ACTION_BUTTON_1, ACTION_BUTTON_2, ACTION_BUTTON_3 and ACTION_BUTTON_4 using in MultiJuke, which is the most important commands in MultiJuke, they act like a arcade button?
What about if a command that can been lighted to a contain button (Ledwiz), but dosen't exists, due to a unique command, due to above unique commands?
How could I feedback a jukebox software, if I want to make a remote controlling plugin, but missing some major comands?
Would a Freebox plugin developer research for other software out here for other commands?
I can't see that hard to send a string to a plugin, and let them use what they want, if they also want to use that command? Up to them.
The sound example is a best example I can give, why I need all or most commands used.
songs in queue would been nice to show to a LCD example. I know not all plugins use it, but you can let user enable or disable that feature. I planing do the same, or could can we do that better way to resubmit all (or some) songs at once and should I bring some commands back (Song_Begin() maye)?
Juke_Init() is used for let plugin reading its config and init the hardware, if a hardware is used. Juke_shutdown does the other way.
unclet:
--- Quote ---The most problem is with a default set, do other software out here use ACTION_BUTTON_1, ACTION_BUTTON_2, ACTION_BUTTON_3 and ACTION_BUTTON_4 using in MultiJuke, which is the most important commands in MultiJuke, they act like a arcade button?
--- End quote ---
Explain what these buttons do in your jukebox and how a user uses them and I will let you know.
--- Quote ---How could I feedback a jukebox software, if I want to make a remote controlling plugin, but dont know all commands?
--- End quote ---
All of the commands will be listed in the SDK, just read it and find what commands are allowed to be sent to the jukebox and then design your remote control plugin.
--- Quote ---Would a Freebox plugin developer research for other software out here for other commands?
--- End quote ---
A Freebox developer would not have to research what commands are for what software because he will just read the SDK to see what the generic commands exist and will then code a plugin around those commands only.
--- Quote ---Juke_Init() is used for let plugin reading its config and init the hardware, if a hardware is used. Juke_shutdown does the other way.
--- End quote ---
I would prefer to use the following commands to do this instead of introducing more routines:
Juke_PluginCommand(JUKE_APP_OPENED)
Let the plugin do what it wants when the jukebox app starts ..... stuff like init itself as well as any hardware.
Juke_PluginCommand(JUKE_APP_CLOSED)
Let the plugin do what it wants when the jukebox app closes ..... stuff like uninit itself or stop hardware things.
Basically, you do not need different routines for all this stuff .... simply create a new command to inform the plugin what is going on and let the plugin figure out what they want to do. For example, what if the plugin wants to initialize itself when the first song starts playing instead of when the jukebox application starts? Basically, why should the jukebox decide when to init the plugin. The jukebox should simply just "inform" the plugin on what events are occuring and let the plugin decide what to do and when to do them.
Also I can not implement a "queue.txt" file since in my software the user can move songs around in the queue and after each "move" request I would need to rewrite the entire "queue.txt" file. So if the user wants to move a song from position 20 to position 1 in the queue, this occurs one queue position at a time, so that would mean the software would generate 20 "queue.txt" files in a row to always keep the queue file up to date. Not real interested in doing it this way.
Now there is nothing wrong with having a standard to provide queuing information in two different ways, which is what I think shold probably happen here. The plugin can get the complete queue contents by reading the queue.txt file or can get the information one command at a time.
Come to think of it I have an option where a bunch of selected songs can be randomly inserted into the queue, thus making the order of the songs all change at once. I might end up using the "queue.txt" file in this one case, but use the other commands (one at a time) for other cases.
headkaze:
Okay I've rewritten the plugin and this should be final :)
It has the following functions
--- Code: ---int Juke_Initialize(int Value);
int Juke_Shutdown(int Value);
PCHAR Juke_GetPluginInfo(int Value);
PCHAR Juke_Command(PCHAR Name, PCHAR Value);
--- End code ---
Now I've update Juke_Command to return a string. So now any command you send to the plugin can return values. If you need multiple arguments for a command the values you send to the plugin need to be split up with a pipe character ('|').
In the plugin demo it just returns back the same parameters you send to it. In the VB6 wrapper I automatically split the returned string using the pipe character so you have an array of strings. This is for testing purposes. In a real plugin it can return any values it wants Eg. ("Value1|Value2|Value3|Value4")
I also added a description to the Juke_GetPluginInfo() function.
Here is an example of sending data to the plugin and getting info back
--- Code: ---Dim RetVal() As String
RetVal = plugin.Command("PLUGIN_INSERT_COIN", "REPEAT|2")
MsgBox RetVal(0) & "," & RetVal(1), vbOKOnly, "Juke_Command"
--- End code ---
Remember the test plugin just returns the same paramters you send to it so the output is "REPEAT,2".
I think that should just about do it! Now all Space Fractal has to do is get his code working with the example plugin in this archive (JukePlugin.dll) and your all set. I'll help loadman convert the C++ code into Delphi and he can start writing his plugin. You guys just have to figure out what commands and paramaters (and possible return parameters) are needed :)
Heres the code...
unclet:
headkaze
1) Actually I was going to ask you to add a "description" to the GetPluginInfo() similiar to your plugin manager you displayed. I think this would be nice to have
nevermind ... I see you added this already :)
2) How does the plugin send information back to the jukebox software? Does the jukebox software have to do anything special to check whether a the plugin has sent it information?
I see in your code that when the Juke_Command() routine is called, then the plugin can return a string, but how does the plugin send information to the jukebox software on it's own (ie: without being called first)
3) Why do we need more than these two routines?
Juke_GetPluginInfo()
Juke_PluginCommand()
I do not think we even need these commands .....
int Juke_Initialize(int Value);
int Juke_Shutdown(int Value);
.... since the Juke_PluginCommand() routine can be called this way to do the same thing:
Juke_PluginCommand(JUKE_APP_OPENED)
Let the plugin do what it wants when the jukebox app starts ..... stuff like init itself as well as any hardware.
Juke_PluginCommand(JUKE_APP_CLOSED)
Let the plugin do what it wants when the jukebox app closes ..... stuff like uninit itself or stop hardware things.
Basically, you do not need different routines for all this stuff .... simply create a new command to inform the plugin what is going on and let the plugin figure out what they want to do. For example, what if the plugin wants to initialize itself when the first song starts playing instead of when the jukebox application starts? Basically, why should the jukebox decide when to init the plugin. The jukebox should simply just "inform" the plugin on what events are occuring and let the plugin decide what to do and when to do them.
4) I am thinking that having separate commands for each action is worth while now. It seems nice to have separate commands so the plugin can have one big case statement only and the JukePlugin class module can be less involved. Basically we use
the "Juke_PluginCommand()" routine for everything and simply standard the cmdName and cmdValue string values which can be passed as parameters.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version