Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
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: --- 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$
--- End code ---
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:
:dunno .... 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:
--- Quote from: Space Fractal on January 08, 2008, 03:30:27 pm ---Did you got the little dll working (before we using the text file idea)? I likelig to avoid the text file, if you can.
--- End quote ---
I got the dll working in VB6...
--- Code: ---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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version