Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
unclet:
My goal is NOT to simply come up with a list of commands which ALL software can use, but to define a standard set of commands which MIGHT be used by some software. If some jukebox software does not use one of these commands, then no big deal .... that software will simply not send the command to the plugin. However, the command can still be standardized for other software to use if required. Standardization is my main goal, not simply trying to find a subset of commands which everyone wants to use for sure.
Space Fractal
In your example of mapping a sound to a command, the plugin author will put any of these commands they want into the listbox to have sound files be mapped to any of them they want. If your software does not support some of these commands then the sounds which are mapped to these commands (if any) will never be heard since your software will never send these commands in the first place. This is what I mentioned earlier. I do not think it is important to have a plugin only list the commands which a specific software uses ..... the plugin can list all the commands and allow the user to map sounds to them, but if you software does not support certain commands then some of those sounds will just not be heard. Which should be fine since your software does not support those commands in the first place. How will the user of the jukebox software know which commands are related to your software? The user should know how your software works before trying to set up plugins for it, so they should understand what commands are relevant or not. I also intend to add a button on my plugin page that when clicked will display a description of which plugin commands my software supports along with a description of the command as it relates to my software. The user has to know what they want to configure before they actually do it .. right?
--- Quote ---These commands does not exists is mine software, instead they can been used to send as extra commands like I said above, using commandlist$:
JUKE_QUEUE_USER_MOVE_SONG
JUKE_SONG_FASTFWD_START
JUKE_SONG_FASTFWD_FINISH
JUKE_SONG_FASTREV_START
JUKE_SONG_FASTREV_FINISH
JUKE_SONG_PLAY_POSITION
--- End quote ---
If these do not exist then simply do not send them. No need to remove them since these are general enough commands which could be used by anybody's software whch has this capability. It is not a bad thing to have commands defined which are not used by some software.
--- Quote ---JUKE_SONG_START does not need any argument about songinfo.. allready got it using queue.txt or such that?
--- End quote ---
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.
BTW: If the software is idle and a song is started, do you first enter the song into the queue even though it can be played right away? If you do not enter it into the queue first then how will the "queue.txt" file help you get the song information for the song?
--- Quote ---QUEUE:
JUKE_QUEUE_CHANGED
JUKE_QUEUE_CLEARED
these are all as needed for the plugin to know the queue is changed.. Extra commands should then removed and goes as extra unique commands intead.
--- End quote ---
If you are going to use the "queue.txt" file all the time then I agree, but I can not do this (see above).
--- Quote --- JUKE_SYSTEM_VOLUME_CHANGE and JUKE_USER_VOLUME_CHANGE can been joined into one command:
JUKE_VOLUME_CHANGE?
Does the plug need that info, if it system or user that changed to volume?
--- End quote ---
Yes then can be joined but I prefer individual commands for each action. It just seems cleaner instead of trying to crame everything together. We can make as many commands as we need!
I believe it might be useful for a plugin to know whether the volume has been "increased" or "decreased" in case someone wants to do something with LED lights perhaps. The other case is when the system simply changes the volume to a certain level by itself (like volume normalization for each song ..... which I might start thinking about).
--- Quote ---ENTER DIGIT COMMANDS:
only used in MultiJuke in Jukebox GUI. I think it should been removed and use them as a extra unique commands?
--- End quote ---
My software offers the user the ability to manually enter album number and track number digits in order to select a song. Actually my kids have some album number and track numbers memorized so they go over to the juke and enter their favorite song all the time this way. Again, having commands defined which are not being used by some software is allowed. Your software will simply not send these commands, but at least we can define a standard for the software who wants to send them.
--- Quote ---FEATURE:
JUKE_FEATURE_PARTY_LOCK is not standard of all software. again, can use as sending to commandlist$ as extra commands to the plugin?
--- End quote ---
Again, having commands defined which are not being used by some software is allowed. Your software will simply not send these commands, but at least we can define a standard for the software who wants to send them.
--- Quote ---JUKE_QUEUE_CHANGED can also been used as a command as seen..
--- End quote ---
Not sure what this means....
--- Quote ---NAVIGATION:
I haven't have any of these commands.
These commands should been removede from the default sets, but istead using commandsend$ as extra unique commands?
--- End quote ---
Then there is no need for your software to use them, but at least we can define a standard for the software who wants to send them.
Space Fractal:
can we not use both the works, so the plugin get full list if not defined in this list.
I update the SDK soon to sync very much here.
I could maybe drop the Juke_Init(WINDOW_ID, command$) and instead something like this:
JUKE_UNIQIE_COMMAND(ACTION_BUTTON_1|CREATE) bofore juke_config().
arguments would can then allways only been ON OFF and CREATE, and then the plugin can find extra commands in the list.
When I like to send the new command, this can been done simple use ON or OFF instead of CREATE (like JUKE_UNIQIE_COMMAND(ACTION_BUTTON_1|ON)
queue.txt can also been removed completly and replace with a command:
JUKE_QUEUE_LIST(PLACE, songs....) instead when some things in queue is manipulated? Beware, some song titles might been UTF8 for unicode support, so russia and other languages can been supported. UTF8 is backward combatible with ASCII.
| should been used as a seperator, because I havent se strings using this seperator.
ETC I change the SDK to suit these soon....
unclet:
The code provided by headkaze has really one main function defined which is used to send stuff to the plugin:
Public Function Command(cmdName As String, cmdValue As String) As String()
I am simply trying to standardize the "cmdName" and "cmdValue" interface parameters to this routine only. This means trying to create a set of generic command names (ie: cmdName) as well as defining what string values (ie: cmdValue) is required for the commands.
I am not really thinking about trying to remove a bunch of these commands and try to send them to the plugin using another routine. This one routine seems like it is suitable to send anything to the plugin, we just need to define a standard set of commands to pass to it.
Regarding your "ACTION button" stuff ...... I am assuming when an action button is pressed then some event happens. Based on this event why cant you send the appropriate command to the plugin using the Command(cmdName As String, cmdValue As String) routine. If the event you are doing is not in my list, lets add another command to my list to cover that case for your software. Perhaps you can list all the commands you would like to send to the plugin from your software and they we can simply define more commands in my list to make sure all your events are covered.
headkaze:
unclet
There is no need for a trailing "|" at the end of the paramter list ;)
--- Quote from: loadman on January 08, 2008, 10:16:52 pm ---Mate, It seemed to work but I will do it your way as you know better coding practice ;D
--- End quote ---
The main problem with your code is you were using "," instead of "|" to return arguments so all the Plugin Info was stored in the "Name" variable
Also you should definately use a global buffer when returning a string pointer (in fact don't forget the little snippet for changing Plug_GetPluginInfo() to use a buffer). Ie. Sending a PChar as a return value of a temporary variable is a no no.
--- Quote from: unclet on January 08, 2008, 10:49:20 pm ---About the two way communication thing....... I assumed the plugin would be able to send a command to the jukebox software. For instance, if the plugin wanted to skip the current playing song then the plugin could send a "JUKE_SONG_SKIP" command to the jukebox software.
--- End quote ---
No the Jukebox can't send a command to the Jukebox software. A plugin is just a host, it can only return values from a call to one of it's functions.
--- Quote from: unclet on January 08, 2008, 10:49:20 pm ---I am not sure how you recommendation of a timer would work. When the plugin wants to inform the jukebox to skip the current playing song, then what does the plugin need to do? Does the plugin have to somehow remember that a "skip request" should be sent, so when the jukebox's 200ms timer expires and it sends a "JUKE_READ_INPUT" command to the plugin then the plugin can then return the "skip text"? This sounds odd, so please explain how this would work from the plugin side please.
--- End quote ---
Okay it would work like this, set up a Timer with an interval of say 200 milliseconds.
In the Juke software...
--- Code: ---Timer_Elapsed()
{
Plugin_Command("JUKE_TIMER", null);
}
--- End code ---
In the plugin
--- Code: ---string Juke_Command(string Name, string Value)
{
switch(Name)
{
case "JUKE_TIMER":
if(bSkipCurrentSong == true)
{
bSkipCurrentSong = false;
return "JUKE_SKIP_SONG";
}
}
}
--- End code ---
This is a very basic example but if the plugin software sets bSkipCurrentSong = true, then next 200 milliseconds the Jukebox software calls the JUKE_TIMER command the plugin will return the "JUKE_SKIP_SONG" command back to the Jukebox software. Now the Jukebox software skips the song. In 200 millisecond calls it will be pretty much immediately so you won't notice any delay when the plugin sends back a command.
loadman:
--- Quote from: headkaze on January 09, 2008, 12:05:54 am ---The main problem with your code is you were using "," instead of "|" to return arguments so all the Plugin Info was stored in the "Name" variable
--- End quote ---
I knew that :banghead:
--- Quote ---Also you should definately use a global buffer when returning a string pointer (in fact don't forget the little snippet for changing Plug_GetPluginInfo() to use a buffer). Ie. Sending a PChar as a return value of a temporary variable is a no no.
--- End quote ---
I could get 'burnt' one day could I depending on what size and for the string was? So the Buffer it just to make sure what I return back is Legal?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version