Main > Audio/Jukebox/MP3 Forum

Plugins: Document API for JukePlugSys

<< < (18/80) > >>

unclet:
Space Fractal
I will try to look through your new ideas some time today/tonight.   I am off to work today and I am not sure whether I can spend time at work again reading BYOAC ..... but I will see  :)

Now, just so I understand fully ..... will you please tell me exactly why a plugin needs to know the full set of commands when the jukebox is opened for the first time?   Is the plugin going to store this full command set and then do something with them itself at a later time?  It seems to me sending individual commands from the jukebox to the plugin only when an event occurs would be sufficient.   I understand you want the plugin to be able to send commands to your jukebox software.  Now, although this will not work for VB jukebox applications I am open to the idea of trying to make something standard which would allow other software applications to have this ability.

I know I do not want to use is a "wrapper" routine which I did not create and can not maintain over time.  I do not think this is required for my jukebox software to offer plugin capability.  What is the main function of this wrapper again?  Basically, why do you need it ...... what will it let the jukebox software do again?

Space Fractal:
First I know there is a pitfall about sending strings back, which is completly why I wrote the wrapper. I need to write it anyway to fit BlitzMax, that have same issues (but can get strings directly). All it really doing is redirect the commands to the plugins. A another purchase about that wrapper is it did all the dynamic loading for you.

I have even tried to write 2-3 help functions to trying to get the strings back to Visual Basic 6, but I can't test that by my self. HeadKaze seen to have a work around, so it can been used two of these helper commands to get the strings back.

And yes, you are correct about the full command list. The user can choice which commands that should do that (example playing a sample) and let the plugin store these used commands, so it can listen to these commands, the user have choiced. In that way the command names can been anything as long the plugin know about it.

Example (see from plugin user point) I could choice a plugin to listen to a COIN_INSERT command, so it can play that sample I want. The plugin would then store COIN_INSERT comand in its config settings to remember that command.

Since I added the Juke_Config() command, there is no need to use a commands.txt anymore. Instead it use a string format simular to your system.

And of course if the command list is changed due to the update, its just matter of reconfig the plugin again, so the plugin can find the command again and listen to that.

unclet:
I think I have an easy solution for getting strings back to the jukebox software ..... but lets not talk about sending data "back" to the jukebox software yet ...... lets just resolve sending data to the plugin first.   I will tell you my idea later.  I consider these items to be two separate things so lets just discuss one at a time for now.
 


--- Quote ---I could chose a plugin to listen for a COIN_INSERT command, so it can play that sample I want.
--- End quote ---


Based on the statement above, it seems like you would prefer the plugin to implement a "forever" loop so it can constantly look for a new incoming command.   Is this correct?  If so, why do you want the plugin to constantly be looking for incoming commands instead of having the jukebox software simply call the plugin routine directly only when necessary? 

Instead of the plugin constantly looking for a command and then performing some function, why not have the plugin only perform that same function when a certain plugin routine is called directly?

For example, when a coin has been inserted and your jukebox software recognizes this action has occurred then have your jukebox software send a JUKE_COIN_INSERT command to the plugin by calling the Juke_PluginCommand() routine "one time".   The plugin would then recognize the command received was a JUKE_COIN_INSERT command and then play the sound you want one time.   In this example, there is no need for a plugin to be "waiting" for a COIN_INSERT command, but rather the plugin only performs certain functions when the Juke_PluginCommand() routine is called directly from the jukebox software.

I am really trying to understand why the plugin needs to "constantly be looking for commands" rather then "the plugin routine being called directly with the appropriate command" ...... but I am having trouble.  :dunno



--- Quote ---The plugin would then store COIN_INSERT command in its config settings to remember that command.
--- End quote ---

This is the statement which I do not understand the most.   You clearly want the plugin to remember a "COIN_INSERT" command is a valid command which can be sent from the jukebox software to the plugin but I do not understand why the plugin must "remember" this command at all?  Basically, you do not explain why the plugin needs to store this command?  Is the plugin going to use it in the future for something?   

Perhaps you want your plugin to remember each valid command so the plugin can eventually send that same command back to the jukebox software thus allowing the plugin to control the jukebox software over the internet or something?




--- Quote ---All the wrapper is really doing is redirecting the commands to the plugins. A another purpose about that wrapper is it did all the dynamic loading for you
--- End quote ---

I just do not like using 3rd party applications which perform all functionality for me.  When feasible, I like to have total control over how my software actually functions.  I actually prefer doing all the dynamic loading of the plugins so I have control over the plugin somewhat.  Also, if I use your wrapper which redirects the commands to the plugin for me then I have introduced an additional layer between my jukebox software and the plugin which I do not control.  I do not like doing that sort of thing.

Now, I also do not understand why a wrapper would be required to redirect commands to a plugin when the jukebox software can call the plugin routine directly.   I realize a wrapper would save the jukebox software from having to keep track of all the existing plugins as well as saving the jukebox the time of having to loop through each plugin to call the Juke_PluginCommand() routine each time for each plugin.   Basically, I understand that if a wrapper did these functions for the jukebox software then the jukebox software would not have this extra work to perform.  However, the task of maintaining loaded plugins as well as looping through each plugin and calling the Juke_PluginCommand() main routine is really not that hard to do and I actually prefer doing this so I can maintain control in my software of how the plugins get called   Basically, it does not make sense for my software to use a wrapper to take care of this functionality for my software.  I would rather my software perform the required functionality itself instead of relying on a 3rd party wrapper I can not control.

Now, if you still want to use a wrapper to maintain all plugins for you as well as redirect incoming commands to the appropriate plugins in your software, then you can still do this.   Just create an internal MultiJuke plugin which defines the Juke_PluginCommand() routine but instead of processing the incoming command in this routine, your "Juke_PluginCommand()" routine would simply redirect the command to all the "real" plugins loaded in your software.  This way, your jukebox software only ever interacts with one plugin (ie: "MultiJuke plugin") and then the "MultiJuke plugin" can interact with all the "real" plugins.

Seems like this approach would allow your software to use your wrapper to control all plugins while my software does not have to use your wrapper at all.  Basically, your software would only ever interact with "one" plugin (ie: MultiJuke plugin) by calling the "Juke_PluginCommand()" routine while my jukebox software will interact with all plugins by calling the "Juke_PluginCommand()" for each one.  Hope that made sense.

Space Fractal:
Wrapper: Up to you of course.

If you got a full workaround and want to share the code, let me know. I granted to include that example to the SDK. I just need a wrapper for my language I use, so I still need to use it by myself.


If the command is not stored (saved), how would it know the command next time you start you jukebox Software up, and the user have allready once time configurated the plugin (ETC a COIN_INSERT to a given sample)?

A Plugin would of course need to save (store) its configurated content, so it can been used next time (Juke_Initialize()
) without needing to reconfig again. As a Jukebox software author I do not need to know how they have saved the config settings after a juke_config(). I dos't care here. They simple save the settings they want to need.

Juke_Shutdown() was also created to get the plugin saved its config contect to a file and/or shutdown any device used.

The plugin is of course not need to listen to a command using a loop. They would got it sooner or later when you sendt it using Juke_CommandSend(), and find it on the stored command in its plugin. You are completly right here....

Its of course only the OTHER way that might doing that, example each screen flip or when polling the mouse or something like it when listin to the string (example the first two song commands might been needed).

Barry Barcrest:
I thought in laymans terms the wrapper was to allow you to recieve information back from the plugin. This is because you know that DLL and can load it into VB in the non dynamic way. The DLL then dynamically handles the plugins so you still have that facility but you can recieve information from the plugins.

Navigation

[0] Message Index

[#] Next page

[*] Previous page