Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
unclet:
--- Quote ---If the command is not stored (saved), how would it know the command next time you start your jukebox Software up, and the user have already configuration the plug?
--- End quote ---
I think the problem is that I do not understand what "configuring a plugin" really means.
Based on your comment above, it seems when a plugin is configured (ie: probably only once when the plugin is first loaded) you want the plugin to remember the command set for some reason and if the jukebox software is restarted then you believe the plugin might be "out-of-date", however, I still do not understand why.
If you will please explain exactly what a plugin would do when the "Juke_Configure()" routine is called, then I might be able to understand all of this better.
--- Quote ---As with Jukebox software do not need to know how they have saved the config settings after a juke_config(). I don't care here. They simple save the settings they need to do.
--- End quote ---
I do not understand this statement at all. Perhaps you are just indicating that it is up to the plugin to save the data it needs during it's configuration? If this is correct, then please see my above comment which asks you to explain exactly what "configuring a plugin" means.
--- Quote ---The plugin is of course not need to listen to a command using a loop. They would get it sooner or later when you send it using Juke_CommandSend()...
--- End quote ---
Good ... the plugin is not looping looking for a command. We agree we can simply call one main routine in the plugin to supply the plugin with the current command. Good!
--- Quote --- ....and find it on the stored command in its plugin
--- End quote ---
This I do not understand.
Once the plugin receives the command name string via the "Juke_CommandSend()" routine then why does the plugin have to look up the command in some stored table?
For example, what exactly do you expect the plugin to do when the "Juke_CommandSend()" routine is called with a "JUKE_COIN_INSERT" text string? The plugin is going to look into some table (which it maintains) to look for the "JUKE_COIN_INSERT" text entry to do what ?
Space Fractal:
For your last line, yes.
How can I example tell a plugin which sample I want to play, if there is no configuration screen to that plugin?
How the configuration screen is made is totally up to the plugin writer. We just call Juke_Config() with these 2 arguments, and let the plugin do the configuration work, includning storing a command table and so on.
Hence Juke_Config() should only been called once at all, it when the user press a plugin config button somewere in your software.
Im are going to create a demo plugin with the Sound Effect sample.
headkaze:
I think I might be able to help by explaining what Juke_Configure() means to me. The way I went about designing a plugin system for GameEx was to have a Plugin Manager application that would read all the plugins in and allow you to configure them all from a central location. I recommend you go this way as it works well and doesn't require separate configuration applications for plugins.
Attached is a screenshot of the Plugin Manager I wrote and also of the configuration screen of a plugin I wrote for it. Note that the plugin author handles the actual configuration, it's in the plugin dll file he opens a window and provides the interface to configure his plugin. He will write the config to a file so when the Plugin is Initialized in the Jukebox software he will read back in this config.
Space Fractal:
Hey, Thanks for these screenshots.
It that what juke_config() (or what the command would named) is needed and is very very important.
Mightbe HeadKaze can help you under that part (mightbe as a standalone application)?
unclet:
My software has already been updated with a Plugin Page which looks almost exactly what headkaze's "Plugin Manager" look like.
The user selects a plugin from the list and clicks the "Configure" button. This will cause the jukebox software to call the "Juke_Configure()" routine for that particular plugin. The code inside the "Juke_Configure()" routine (written by the plugin author) would be in charge of opening up a plugin specific configuration application window (exactly like Headkaze's example shows). The user of the jukebox software can now configure the plugin exactly how they would like it to be configured. When all configuration has been completed and the plugin configuration application window is closed I would expect the plugin to store all the configuration settings to some file which the plugin maintains itself.
Note: When the jukebox software starts up, there is no reason to automatically call a plugin configuration routine at all ie: no need to call "Juke_Configure()" at all during startup). The user can simply go into the plugin manager page and click the configure button for the plugin they want to configure. The user can actually configure the plugin many times over and over if they forgot stuff or want to change settings. There is no need to limit the "Juke_Configure()" routine of a plugin to only be called one time.
Now, with this description of how a plugin should be configured stated above, I do not see a need for any plugin to "store" any command sent from the jukebox.
This is how I would expect the procesing of a "coin insert" event to occur:
1) User starts the jukebox software up
2) User goes to the plugin manager page (within the jukebox software) and sees their plugin listed, highlights their plugin and clicks the "Configure" button to bring up the plugin configuration window.
3) In the plugin configuration application window, there is a section where the user can select which sound they want to hear when a "COIN_INSERT" command is received. The user simply chooses a sound and then saves the configuration, then closes the configuration window which will take them back to the jukebox plugin manager page once again.
4) While in the plugin manager page the user clicks the little checkbox next to the plugin name to enable it (ie: so it can receive command indications) and then exists the plugin manager page to return to the main jukebox application.
5) User then wants to buy a song so they put a coin in the slot of their machine which makes the jukebox software send a Juke_PluginCommand("JUKE_COIN_INSERT", cmdvalueText) to the enabled plugin application.
6) The plugin will determine the type of command is a "JUKE_COIN_INSERT" command and will then look up in it's own configuration file what exact sound should be played when a coin insert command is received and then will play the sound.
That is exactly how I see it working ...... still no need for the plugin to "remember" what command is being sent because it is sent the command directly everytime. Now, the plugin obviously has to offer a way for a user to indicate what sound should be played when a JUKE_COIN_INSERT command is received, but that is all up to the plugin application to figure out how to do that and how to save the information for look up later.
Based on this example above I still see no need at all for a complete list of commands to be sent from the jukebox into the plugin for storage. The plugin author should know what exact commands can be sent from the jukebox software to the plugin by simply reading the plugin SDK documentation. Once the plugin author knows which commands are valid to be received, then the actual plugin application can be created to offer the user settings for each of these commands which will define exactly what should happen when the command is received by the plugin. But again, this is up to the plugin author to code the application and store all the mappings for each command ..... the jukebox software should not have to worry about any of this. Again, no command list of any kind is required to be stored by the plugin.
** Now ..... perhaps you wanted the plugin application to be "automatically" updated somehow when new "commands" are added to the SDK and somehow have the plugin application understand that a new command exists now without the plugin author having to update their plugin application manually everytime a new command was defined in the SDK? Is this what you were trying to do? I personally would not know how to do something like this but it might explain why you wanted the plugin application to know about all existing commands. Perhaps ..... this is just a guess obviously.
PS: Thanks headkaze for providing the Plugin Manager pics :applaud:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version