Plugins: Document API for JukePlugSys

[unclet]

No need to apologize to me .... I did not take it personally.   

I understand the amount of effort you put forth with your proposal but I just thought an easier approach might exist for me so I decided to share my ideas with everyone in this thread.   I had a lot of free time at work today so my mind started to wander thinking an easier approach for me.

Again, no need to apologize to me ......

[Space Fractal]

Why was the SDK very complicered, that was only about 10 commands to fit it all and only one file? It only sending commands that might take time, but I asumed all used a class for that (I have these commands I allready listed).

I wrote even a simple litte wrapper where HeadKaze allready got working in VB6 to been included in your project (which I removed by now)?

Instead you just did go other way and never accepted this SDK? I also listed the commands you could use with your parser?



The Queue section in my SDK need a redesign, sence it seen too been complicered.

The most compliced seen to been queue things?

Should I redesign it to use a queue file instead, so the plugin can detect any files that is changed using that, and just use QueueChanged() to tell the queue have been changed?

Let me know other ideas to this section, so it can been easier for you and for writers.

I have tried to change this section, so it much easier. The only missing is which format queue.txt can been used.


I have changed the commandlist system as well. It now pretty much UncleT with very minor change. I hope you like it. Since I added a Juke_Config(), why not tell the plugin the whole commandlist to been used? Hence I can now use UnlcleT's idea with this change I made in the SDK.

Only Queue things is not need to doing that way (that is hearvy changed to been simple now).


Please note:
I also axed some never used commands and have joined Juke_SongBegin() and Juke_SongEnd() to QueueChanged().

I guess QueueChanged() is all you need to tell a plugin the queue have been changed (hence a new song started), so its reread the queue.txt (that can been empty) anyway?

 

[loadman]

 

It's at the point that where backbone stuff has been tested and it seems like it is going to work technically.

The only question is there going to be a one system or not.?? 

My personal view is I will going along with UncleT's choice of system (when he decides) as that's the Video Jukebox I've decided to use in my GameRoom. 

But it would be a SUPER BONUS if Space Fractual (using his obvious Enthusiasm, ideas and energy  ) was able to work with UncleT to make a common system so my Plug-ins (and others) could be used on your (and other JukeBox's too) 

So I think to make things efficient you should not worry about these threads anymore   

I think the only hope for a Global Format is for Space Fractual and UncleT to have direct discussions as you are the two major players who have been interested in contributing to these threads

I will sit back and wait to see what happens.

Thanks everyone (Barcrest, HeadKaze) for your efforts and Suggestions    

The next time I post here will be to announce to release of my first JukeBox Plug-in 

[Barry Barcrest]

 

I knew this was how it was going to end... At the end of the day there is little point developing another system if no one will code plugins for it.

Anyway a big thanks to HeadKaze for sorting out the VB code and sharing that.

[Space Fractal]

as for my self, thanks to HeadKaze for offet VB6 support when I tried to get to work to my wrapper.

Let see what UncleT said after I inveted the SDK and cleared out issues in the first post....

first after I would write a wrapper again for fit to VB6 and BlitzMax.

[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.
 

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

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. 

The plugin would then store COIN_INSERT command in its config settings to remember that command.

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?

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

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.

[unclet]

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?

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.

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.

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.

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()...

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!

....and find it on the stored command in its plugin

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   

[Space Fractal]

** 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  

YES, Here is the screen shot how i would make a common sound plugin (sending COIN_INSERT@MOVE_UP@MOVE_DIGIT(1,2,3,4) as a commandset string)

Since this sound plugin dosen't need digit values, the plugin will simply just ignorie them.

You software might use other commandset, but the plugin would then just change the list in the "Select a Jukebox Command" in the screenshot to suit your software....

[unclet]

YES !!

I think we just made some progress   

Let me think about all of this for a bit (and get some actual real job work done now) and I will get back to this later.   At least I understand what you want to do now! 

[Space Fractal]

Why did I not create a screenshots a long ago?

Thanks headkaze for jumping in. It help alots.

No we have a future progress and it seen the SDK soon can been done.

[unclet]

Quickly thinking about this, I think the idea of having the plugin know all the commands up front will work for some plugin functions (like your example of associating a sound to a command) but I think for other commands, which are added to the SDK in the future, the plugin application will be required to be manually updated by the plugin author. 

For example, some commands are going to be stand-alone commands which require the plugin author to provide a new setting option within their plugin application.   

Let me think about all of this now .....

[Space Fractal]

or course, this depend which type of plug-in he write....

Sometimes they might of course want to use given commands, that might have different names. Here the user can tell the plug-in config which command name that is excepted to been used.

If a plugin would use some screensaver mode, a user would either select SCREEN_SAVER (MultiJuke) or ATTRACT_MODE (UncleT Jukebox) in its plugin config. These commands does nearly the same.

I also think we should only use ON/OFF/DISABLE and any numbers as a argument to the command?

[unclet]

Oh yeah .... now that I understand what you are trying to do ......

Here is my idea regarding how text strings can be sent into the jukebox application:

A new set of command name\value strings which are used to send data into the jukebox would be defined:

TO_JUKE_ENTER_DIGIT_1.0           digitNum> 
TO_JUKE_SONG_PAUSE_1.0           n/a
TO_JUKE_CLEAR_QUEUE_1.0          n/a
TO_JUKE_ATTRACT_MODE_1.0       on/off>
etc... etc...

Note: Of course commands sent from the jukebox would have a prefix of "FROM_JUKE_xxxxx" now

Our jukebox standard would define a standard file name (ex: cmdToJuke.txt) which will exist in the "plugins" directory.  When data wants to be sent to the jukebox application, a "command name" string and "command value" string would simply be stored in the file.  The file will only ever have one line in it indicating two strings with a format of:

+-----------------------------------------------
|cmdNameString    cmdValueString
|
|

For example:
When an application wants to inform the jukebox the digit "4" has been pressed, then it simply puts the following text in the file:

+-----------------------------------------------
|TO_JUKE_ENTER_DIGIT_1.0   4>
|
|


The jukebox software only has to create a Timer task (which runs every 1/2 sec or so) to check whether the file timestamp has changed.  If the file timestamp changed then read the first line from the file only and determine what action should be performed based on the command name and command value strings provided.  I think it is pretty easy. 


PS:  Lets not discuss format of commands yet ...... lets get a full working idea of how everything "should" work together first.

[Space Fractal]

I have created a helper dll function you should try to test. I hope this is a working around without needing a text file (which elsewice is a good idea). The dll file in this post contain 2 functions:

PeekByte(memory)
Peek a byte from memory

TestString()
This return a test string retured as a integer pointer where the string is in the memory.


You can so try to translate this Blitz Max code to visual basic and hope you got it work:

Code: [Select]

StringPointer=TestString()
Local Name$=""
Repeat
Local char=PeekByte(StringPointer)
If char=0 Then Exit
StringPointer=StringPointer+1
Name$=Name$+Chr(char)
Forever
Print "NAME: "+Name$

Make sure to stop when it found a char value to 0 which is the end pointer.

[unclet]

In your screenshot you indicate "COIN_INSERT", "MOVE_UP" and "MOVE_DOWN" and would like to assign sounds to these commands.   

"MOVE_UP" and "MOVE_DOWN" are commands specific to your jukebox of course.  I am assuming your jukebox software only has one screen which allows the user to move up or down only within one area of the screen.  In my jukebox software I have multiple screens which have various areas in which the user can move up/down.  As a result having one set of generic "MOVE_UP" or "MOVE_DOWN" commands would not work for me.   

I would need more specific commands like the following:

"SONG_QUEUE_MOVE_UP"
"SONG_QUEUE_MOVE_DOWN"
"PLAYLIST_SELECT_MOVE_UP"
"PLAYLIST_SELECT_MOVE_DOWN"
"SONG_TRACK_SELECT_MOVE_UP"
"SONG_TRACK_SELECT_MOVE_DOWN"

I do understand that this is your whole point about having the jukebox software supplying the plugin with the jukebox's specific commands.  Your jukebox would supply "MOVE_UP and MOVE_DOWN" only and my software would supply a larger set of commands (as listed above).

I have been thinking about this and believe that I am really not that interested in trying to automatically have the plugin update itself when new commands are added or when the plugin is used in a different jukebox have the plugin realize all the commands specific to this jukebox automatically.  I think the plugin should do all this by hand.   


The new direction I am thinking about is simply telling the plugin which jukebox is currently using the plugin so the plugin code can know exactly what command values are related to specific jukebox applications.   I believe trying to keep the plugin application in sync (in a general matter) with all different jukebox applications out there is too much work.

Here is what I propose:

     .... got busy and had no time to think about this stuff yet.

[Space Fractal]

hey, look for the commandset I have before commands.txt was dropped (these 3 commands was just to test). MultiJuke is not that simple as through, I have about 25-30 commands. Due you send a commandlist() with full commandset to the config, you can use any number of commands and command names as you wich.

There is no need to tell the plug-in about which software it use.... They might detect which software that is in use using the commandlist(), if they found that command they want to use.

Did you got the little dll working (before we using the text file idea)? I likelig to avoid the text file, if you can.

[headkaze]

Did you got the little dll working (before we using the text file idea)? I likelig to avoid the text file, if you can.

I got the dll working in VB6...

Code: [Select]

Declare Function TestString Lib "PeekMemory" () As Long

Declare Function SysAllocStringByteLen Lib "oleaut32" (ByVal lpString As Long, ByVal lLen As Long) As String

Declare Function lstrlen Lib "kernel32" Alias "lstrlenA" (ByVal lpString As Long) As Long

'Convert a string pointer to a VB string
Public Function PtrToVBString(ByVal lPointer As Long) As String
    PtrToVBString = SysAllocStringByteLen(lPointer, lstrlen(lPointer))
End Function

Private Sub Form_Load()   
    ' Outputs "WORKING"
    MsgBox PtrToVBString(TestString)
End Sub
unclet: Now we can recieve strings from the CallFuncPtr() function! So you can now recieve plugin info! I will update the source code in a minute.

[unclet]

Space Fractal
You want the plugin to know all of the commands supported by the specific jukebox software which is running so the plugin can populate the listbox with the command names so the user can map "sounds" to each command.   

I just do not like having to supply the plugin with a list of commands so it can populate a listbox correctly.   If there are multiple listboxes which should be populated with different commands, then there would be multiple command lists which then need to be supplied to the plugin and I do not want to get into this type of coding.

I will think about this stuff some more.

PS:  If headkaze and you have found a way to get a string into the jukebox then that is great ..... dont worry about using my file text idea then ..... it was just an idea   

[Space Fractal]

Another purchase is for network remote controller....Neat to control a jukebox outside the jukebox machine itself, good for adminstrator, if they example want to shutdown or such thing outside or anything else.

But I do think the value$ (the second argument) should been limit to very few commands. Maybe ON OFF DISABLE LEFT RIGHT UP DOWN and any integer numbers?

Then join all "moving" into one command for each set? Like "PLAYLIST_SELECT_MOVE_UP" and "PLAYLIST_SELECT_MOVE_DOWN" to "PLAYLIST_SELECT_MOVE"?


HeadKaze, I submit your code into the first post and I update the SDK to suit this one and post the source code.

[headkaze]

Yay! It works

Here is the dll code

Code: [Select]

JUKEPLUGIN_API PCHAR __stdcall Juke_GetPluginInfo(int Value)
{
sprintf(m_buffer, "%s,%s,%s", PLUGIN_NAME, PLUGIN_AUTHOR, PLUGIN_VERSION);

return m_buffer;
}
And here is the code to get the info back...

Code: [Select]

Dim sPluginInfo As String
Dim sArray() As String

sPluginInfo = PtrToVBString(CallFuncPtr(pDC, pGetPluginInfo, vbNull))
   
sArray = Split(sPluginInfo, ",")

If UBound(sArray) + 1 = 3 Then
PluginInfo.Name = sArray(0)
PluginInfo.Author = sArray(1)
PluginInfo.Version = sArray(2)
End If
Attached is the complete code

[Space Fractal]

HeadKaze, I have chaged the SDK a lots, due UncleT and I wasnt agree.

I removed a lots of commands and is now very few, but should been very powerful commands.

It fine to have a demo to tryout, headkaze.

UncleT, I have changed SDK a bit again, ok now?

LoadMan, Headkaze as plugin writer, anything we should look on?

[unclet]

Good work on finding a way to get information back to the jukebox software   

Space Fractal
Regarding my concern of the command list being supplied to the plugin.......

I believe all standard commands (for the most part) should be displayed in the listbox for sound mapping, not just particular ones.   It should not be up to the jukebox software to determine what commands should have sound associated with them or not.   Simply let the plugin author determine which commands they would like to support for sound mapping or not.  It should be really up to the plugin author.   

I believe I was thinking to much on this issue when the solution is really to not do anything different.   

So I now I still believe there is no need to inform the plugin which commands should be populated or not.  The plugin author will read the SDK description and determine which commands they want to support to allow for sound mapping.  Each plugin should have a page in it's configuration window which details which SDK commands they support.

Now, I believe you might mention that MultiJuke does not have a mode called "Attract Mode" but has a mode called "Screensaver" instead.   Well I was thinking about this on the ride home from work today and I think this is just a standards issue.   We should not create two commands called "SCREENSAVER" and "ATTRACT MODE" but simply agree on one naming convention that is generic enough to represent both modes with one command.   

Now, in this case, I believe JUKE_ATTRACT_MODE is a very generic common command name which most people use to refer to a "mode" which tries to attract people to the machine when nothing is going on to try to get them to insert money, play a song, etc.... so I would propose keeping this name and have MultiJuke (in this example) simply send the "JUKE_ATTRACT_MODE" when it's screensaver activates.

Anyway, I think I might spend some time tonight defining some command names which can be sent (and received) by the jukebox software.

[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]

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?

Explain what these buttons do in your jukebox and how a user uses them and I will let you know.

How could I feedback a jukebox software, if I want to make a remote controlling plugin, but dont know all commands?

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.

Would a Freebox plugin developer research for other software out here for other commands?

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.

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.

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: [Select]

int Juke_Initialize(int Value);
int Juke_Shutdown(int Value);
PCHAR Juke_GetPluginInfo(int Value);
PCHAR Juke_Command(PCHAR Name, PCHAR Value);
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: [Select]

Dim RetVal() As String
RetVal = plugin.Command("PLUGIN_INSERT_COIN", "REPEAT|2")
MsgBox RetVal(0) & "," & RetVal(1), vbOKOnly, "Juke_Command"
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.

[headkaze]

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?

It just returns information when you send a command.

Eg.

Code: [Select]

Dim mp3Tag() As String
mp3Tag = Juke_Command("JUKE_GET_MP3_TAG", "C:\Music\MySong.mp3")
MsgBox "SongName:" & mp3Tag(0) & "Album:" & mp3Tag(1)
If you want to be able to receive data from the plugin at any time create a timer and put in a special command that is sent over every 2 seconds to check for data

Eg. Juke_Command("JUKE_DATA_CHECK_TIMER", "STATUS")

Then you can check for data from the plugin and the plugin can send it over whenever it wants to. But I don't really see a need for such a thing, do you?

3) Why do we need more than these two routines?

Juke_GetPluginInfo()
Juke_PluginCommand()

*snip*

Because it's just standard programming practice to do it that way. I know you could put everything into a command and have one magic function called Juke_Command() that does everything. But these are important functions that every plugin needs therefore it's my opinion they should be in there to make it clear to the plugin coder they must contain the initialization and shutdown code.

All plugin systems need to have that, so I think they should have functions of their own. Now we can just accept this and move on or debate it until our heads turn blue. It's really not an important thing to be concerned about, all the code is already written to support it now anyway. It's best to just finalize the basic plugin structure now and move on to the more important Jukebox commands.

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.

Again, a few extra functions are ok. Most is done in Juke_Command() anyway. The JukePlugin class module is already VERY basic anyway. Let's just accept these other functions please, as debating these minor points only holds up any more progress. (It's starting to sound like commands.txt all over again lol)

[unclet]

If you want to be able to receive data from the plugin at any time create a timer and put in a special command that is sent over every 2 seconds to check for data

Eg. Juke_Command("JUKE_DATA_CHECK_TIMER", "STATUS")

Then you can check for data from the plugin and the plugin can send it over whenever it wants to. But I don't really see a need for such a thing, do you?

I believe Space Fractal wants to be able to implement a remote control for his jukebox so he can press a button and have the jukebox do stuff.  I guess I thought his remote control interface would need to go through some plugin interface and then to the jukebox.  If so, then the plugin would need to send messages to the jukebox at anytime.   Perhaps I am wrong?
 

Because it's just standard programming practice to do it that way.

If those are standard plugin functions I can live with them ... no problem.   I like how most all commands

Again, a few extra functions are ok. Most is done in Juke_Command() anyway. The JukePlugin class module is already VERY basic anyway.

Yes, I wrote those questions before checking out your slimmed down JukePlugin class module.   Lets get on with defining the cmdName and cmdValue strings now.

[loadman]

Yay! It works

Here is the dll code

Code: [Select]

JUKEPLUGIN_API PCHAR __stdcall Juke_GetPluginInfo(int Value)
{
sprintf(m_buffer, "%s,%s,%s", PLUGIN_NAME, PLUGIN_AUTHOR, PLUGIN_VERSION);

return m_buffer;
}
And here is the code to get the info back...

Code: [Select]

Dim sPluginInfo As String
Dim sArray() As String

sPluginInfo = PtrToVBString(CallFuncPtr(pDC, pGetPluginInfo, vbNull))
   
sArray = Split(sPluginInfo, ",")

If UBound(sArray) + 1 = 3 Then
PluginInfo.Name = sArray(0)
PluginInfo.Author = sArray(1)
PluginInfo.Version = sArray(2)
End IfAttached is the complete code

                  

I even got it a Dll made in Delphi to send the data back to the VB6 test app
 

Code: [Select]

library JukePlugin;

uses
  Dialogs;
{*****************************************************************************}
var
PLUGIN_NAME : pChar = 'LCD Display';
PLUGIN_AUTHOR : pChar = 'Loadman';
PLUGIN_VERSION : pChar = 'Beta A';
{*****************************************************************************}
function Juke_GetPluginInfo(A:integer):Pchar ; stdcall;
begin
result := PChar(PLUGIN_NAME+','+ PLUGIN_AUTHOR+','+PLUGIN_VERSION);
end;
{*****************************************************************************}
procedure Juke_SongStart(A: Integer); stdcall;
begin
Showmessage('DLL has recieved Juke_SongStart message');
end;
{*****************************************************************************}
procedure Juke_Shutdown(A: Integer); stdcall;
begin
Showmessage('DLL has recieved Juke_Shutdown message');
end;
{*****************************************************************************}
  exports
  Juke_GetPluginInfo,
  Juke_SongStart,
  Juke_Shutdown;

{$R *.res}

begin
end.

[unclet]

headkaze
Your latest code has a problem in my software.  When the Form_Unload() routine is called, my project crashes when the ShutDown routine is being called.  If I go into the JukePlugin class module and comment out the call to CallFuncPtr for the ShutDown call, then my project no longer crashes.

[headkaze]

I believe Space Fractal wants to be able to implement a remote control for his jukebox so he can press a button and have the jukebox do stuff.  I guess I thought his remote control interface would need to go through some plugin interface and then to the jukebox.  If so, then the plugin would need to send messages to the jukebox at anytime.   Perhaps I am wrong?

No, this is a great idea! In fact I have some C++ source code for recieving messages from an MCE Remote. Although come to think of it most buttons on that remote are read as keyboard input so it would work without a plugin anyway. But I like the concept and it's certainly easy to implement using the current plugin design.

Since this is input you would need to send a command, say, every 200 milliseconds to check for input. That's so you when you press a button there is no delay from the Jukebox to process it.

Eg.

Code: [Select]

Plug_Command("JUKE_READ_INPUT", "MCE_REMOTE");
Something like that that is called every 200 milliseconds in a timer. The thing is now Juke_Command() has two way communication you can do anything you like with it. All you have to do is set up a timer if you need to constantly check for data from the plugin. In most cases though a timer would not be necessary.

If those are standard plugin functions I can live with them ... no problem.   I like how most all commands

 

Yes, I wrote those questions before checking out your slimmed down JukePlugin class module.   Lets get on with defining the cmdName and cmdValue strings now

 

I even got it a Dll made in Delphi to send the data back to the VB6 test app

Sweet!

Your latest code has a problem in my software.  When the Form_Unload() routine is called, my project crashes when the ShutDown routine is being called.  If I go into the JukePlugin class module and comment out the call to CallFuncPtr for the ShutDown call, then my project no longer crashes.

Okay I did add some extra code to check for these sort of problems. The follow code will make sure after shutting down no call to the library can be made again.

Code: [Select]

Public Function Shutdown() As Long
    Dim RetVal As Long
    If pShutdown <> 0 Then
        RetVal = CallFuncPtr(pDC, pShutdown, vbNull)
    End If
    FreeLibrary hDll
   
    pGetPluginInfo = 0
    pInitialize = 0
    pShutdown = 0
    pCommand = 0
   
    Shutdown = RetVal
End Function
Try the new one attached.