Plugins: Document API for JukePlugSys

[Space Fractal]

About PlugJukeSys:

Here is a more indepth information, what this JukePlugSys is really do:
http://www.jukeplugsys.com

Here is a command list for PlugJukeSys:

This Document API is a plugin system, named Jukebox Plug-In System, which is available to create and use plugins to your favorit software, that can use this system. This system is universal and can been used by any jukebox software.

Please Notes:

• All returned string MUST been a adress reference to the memory where the string is.
• All values might also sendt as a string, even it sat it a value.
• UTF8 unicode coded strings can been used for unicode support for all strings (both send and retrieved).
• Plugin file names would been named JPS, which is a renamed DLL file.
• Since This SDK is V1.X now, no major changes to all commands or removals would been used.
• Not all commands is required to been used by Jukebox Software.
• New commands can allways been added, if needed....

!! STATUS: V1.06 (March 21, 2008) !!

1.06: No commands added, but just write some info about subdirectory in the plugindir, some plugins might use.
1.06: Removed old no needed info in JUKE_SONGLIST_ADD_SONG (no changes required in exist apps).
1.06: Better destription for JUKE_SONGLIST_CURRENTPOSITION, most targeted for Plugin Writers.
1.06: A little note for JUKE_APP_UNICODE.
1.05: Added a Filename to the JUKE_SONGLIST_ADD_SONG, JUKE_SONG_START and JUKE_SONG_NEXT commands.
1.05: Changed destription about JUKE_SONGLIST_CURRENTPOSITION, but it does the same.

1.04: Just added a note about JUKE_PLUGIN_EVENT_GET to not use " as returned string, since some software (like Uncle'T Jukebox) might not like them.

1.03: IMPORTANT: PLUGIN_EVENT_CREATE renamed to JUKE_PLUGIN_EVENT_CREATE

Plugin Writers: Make SURE to checking if the jukebox application have added the JUKE_ Prefix. If the software diddent do that, please add that to the string BEFORE parsing the string in your plugin.

1.02: Just added 2 new commands, marked in red.
1.02: JUKE_SONGLIST_SUGGESTION can now send more than one file back.
1.02: examples in PLUGIN_EVENT_CREATE: () didden't march... Just A document error.
1.01: The JUKE_SONGLIST_SUGGESTION is changed (was a really bad description).

Directory Format for Plugins:

• There should exists a subfolder where the JST files can been placed where the Jukebox Application is installed.
• This subfolder can been called "JukePlugSys", but is not required to call precision like that (but use here as reference).
• The Jukebox application should only search for JST or DLL (in debugger state) files at exists in the "JukePlugSys" subfolder.
• Plugins in main plugin folder should use the same name, like this (of course unless when used in a subfolder):
  
  JukePlugSys\
   \JPSAttractSounds.jps
   \JPSAttractSounds.ini
   \JPSAttractSounds.txt
  
  

• A Plugin can can even want to create a subfolder to, if it plans to use many support files or folders, like this:
  
  JukePlugSys\
   \JPSAttractSounds\ (folder)
   \JPSSoundFX\ (folder)
     readme.txt (can been any filename)
     any other files or more subfolders
   \JPSAttractSounds.jps (file)
   \JPSSoundsFX.jps (file)

MAIN DLL FUNCTIONS DEFINED:

These functions should been defined by a DLL.

PCHAR Juke_GetPluginInfo();
Return a string contaion this info with this format:
PLUGIN_NAME + '|' + PLUGIN_AUTHOR + '|' + PLUGIN_VERSION + '|' + PLUGIN_DESCRIPTION


int Juke_Initialize(value);
Init the plugin throuch under the Jukebox Software startup. return 1 if succes.

int Juke_Shutdown(value);
Init the plugin throuch under the Jukebox Software startup. return 1 if succes.

int juke_Configure(HWND hWndParent);
Invoke plugin configuration screen with the Plugin Mangager WINDOW ID. The Plugin can use as its parent windows, so the configuration window can have the current focus.

If a Jukebox Application dosent know what it is, this can been set to 0.


Juke_Command(Name:PChar; Value:PChar):PChar;
Sending a string (UTF8 or ASCII formatted) with a name and a value, and some commands might return a string pointer to a jukebox softare (also UTF8 or ASCII formatted).

APPLICATION COMMANDS:

Juke_Command("JUKE_APP_GAINFOCUS","")
When the user just switched to the jukebox software for activate the main Window.

Juke_Command("JUKE_APP_LOSTFOCUS","")
If the jukebox application lost focus for the main window.

Juke_Command("JUKE_APP_RESTORED","")
When the application is restored.

Some application might not use the GainFocus command, and others might use both.

Juke_Command("JUKE_APP_MINIMIZED","")
When the applications is minimized.

Some application might not use the LostFocus command, and others might use both.


UNICODE_SUPPORT$=Juke_Command("JUKE_APP_UNICODE","TRUE or FALSE")
Does the Jukebox Application support Unicode or not? Then a UTF8 formatted encoded string can been used as send and retrive. This allow other langauges to been used as well.

If the plugin itself does support UTF8 strings, it can return a "TRUE" string back, so it make sure plugins can understand UNICODE.

To Jukebox Authors:
It is optimal to add a option to disable or enable this feature in the config manager API.


Juke_Command("JUKE_APP_HOST","SOFTWARE NAME")
The Jukebox software name.

If a jukebox application support UNICODE, the arguments would been JUKE_APP_HOST_UNICODE his string would been used, otherwice empty. If the Jukebox Software is not used any unicode string, that would been no need to convert UTF8 strings by both plugin and jukebox software.

!! Plugin Writers: Please don't reject other jukebox software, if you have a favorit !!

PLUGIN_EVENT COMMANDS:

These PLUGIN_EVENT commands is very powerfull, where a Jukebox Software host can define any features it have. Some features can go for a KEY_EVENT, other can example go for some light events and so on.

Your software does NOT need to meet any features another software might have, that part is up to you (as jukebox authors) to define.

Please Note: Any CHAR value at 34, which is a ", should been removed from ValueStr before parsing, if they are added by the Jukebox software  (SEND, CREATE), but do NOT add them when sent back from the Plugin (GET).


JukeCommand("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"valueStr"")

where:

valueStr = text string indicating which types of values which are allowed to be sent to (and received from) the plugin.   This string consists of any of the following text values listed below.  Each value is space delimited.

• ENABLE = allow the user to provide input or invoke change  (ie: allow users to delete queued songs)
• DISABLE = DO NOT allow user to provide input or invoke change (ex: do not allow users to delete queued songs)
• NUMBER = a number can be provided (ex: set volume level)
• LETTER = a letter can be provided (ex: jump to album covers starting with a certain letter). a UTF8 letter can also been sent for unicode support.
• ON = a feature or setting has been turned on (ex: repeat song ON, mute volume on)
• OFF = a feature or setting has been turned off (ex: repeat song OFF, mute volume off)
• KEYDOWN = a button has been pressed
• KEYUP = a button has been released
• KEYCLICK = a button has been pressed and released (a empty valueStr, "", is act like a KEYCLICK)

Examples:

• To indicate whether something is on or off then the following command would be created:
  JukeCommand("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ON OFF"")

• To indicate a number or letter can be associated with the event:
  JukeCommand("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"NUMBER LETTER"")

• To indicate you can enable or disable (like lights) something as well as indicating you can receive some keyEvent for it:
  JukeCommand("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ENABLE DISABLE KEYDOWN KEYUP KEYCLICK"")

• Now, "just for fun" lets say there is an event which allows the plugin to enable/disable it, also allows it to enter a number and a letter:
  JukeCommand("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ENABLE DISABLE NUMBER LETTER"")

Juke_Command("JUKE_PLUGIN_EVENT_SEND", "eventName|valueStr")
Sends a previously defined jukebox-specific command to the plugin with a valueStr.

where: eventName = a text string in this format ---> PLUGIN_EVENT_(name)|"valueStr"

retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")
Send a defined command back to the Jukebox Software.

where: retvalStr = a text string in this format ---> PLUGIN_EVENT_(name)|valueStr

Please Note: Some jukebox software does not like " in the returned string, so do NOT add them here.

[/color]

SONGLIST COMMANDS:

For Jukebox Authors: If the song contain a | char (I never seen that), remove that before send the string.

Juke_Command("JUKE_SONGLIST_ADD_SONG",
"system|postition|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|more|FileName")
Add a song into that position in the songlist.

Info about arguments:

• System is set to 1 if the song was added by the system
• Some songinfo "tags" might been empty if not used.
• Some songs might not contain TotalDuration, and hence sent as 0.
• TrackNr and AlbumNr is the same value types as enter DIGIT commands.
• If more songs is going to submit at once, the more vaule is set to 1.
• FileName is stored with full path (might not used by all JB software).

Juke_Command("JUKE_SONGLIST_REMOVE_SONG", "position")
Song removed from the songlist by user or system.

Juke_Command("JUKE_SONGLIST_MOVE_SONG", "oldPosition|newPosition")
Song moved from the songlist.

Juke_Command("JUKE_SONGLIST_CLEAR", "")
The songlist has been cleared.

Juke_Command("JUKE_SONGLIST_CURRENTPOSITION", "position")
Some software do NOT delete songs from the songlist after the song is played finish (JUKE_SONG_FINISH). Instead this software just jump to the next song in the SONGLIST and play that. This command tell the plugin which song that is in playing from the SongList (likely the same way Winamp do).

This command should been used <b>BEFORE</b> JUKE_SONG_START and is not required by jukebox software to support this (example if JB software only use these SONGLIST as a QUEUE).

Plugin Writers:
If you want to support all songlist/playlist/queue scremes a jukebox software might use, you can threat the current played song as song position 0, if this command is NOT used by the jukebox software software (Like Uncle'T Jukebox).

example when this command is never used:
 if plugin got a "JUKE_SONG_START" then convert it to a "JUKE_SONGLIST_ADD_SONG" with song position at 0.
 if plugin got a "JUKE_SONG_FINISH" then convert it to a "JUKE_SONGLIST_REMOVE_SONG", "0"
 if plugin got a "JUKE_SONG_SKIP" then convert it to a "JUKE_SONGLIST_REMOVE_SOMG", "0"
[/i]

Hence you make sure it works with any software, that might use diffecent, like these in MultiJuke, Uncle'T Jukebox.


SuggestionFile=Juke_Command("JUKE_SONGLIST_SUGGESTION", "LastPlayedFile")

Get a file from a plugin. This command can been used when the songlist is empty or last song is played finish from the PlayList. Neat for applications like MUSIC_IP.

The Jukebox software would send the last played file with full path to the plugin and return a another file(s). If more than one file is returned and seperated with |.

The returned string can been some thing like this:
D:\Musik\Albums\Bjørn Lynne\Accelerator (Bjørn Lynne) (2001)\01 - Turbo Grid.mp3"

Please Note: If no of the returned files is listed in Jukebox software database, the software might change to radio, idle modes with automatic playing. When the new song is played finished it trying send this command again.

SONG PLAYING COMMANDS:

Juke_Command("JUKE_SONG_START","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|FileName")
New song is just started (system is set to value one if it added by the system).

Please Note: FileName is stored with full path. Some Jukebox Software might send nothing to that argument.

Juke_Command("JUKE_SONG_NEXT","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|FileName")
Same as above, but just info about next song (system is set to value one if it added by the system).

Juke_Command("JUKE_SONG_FINISH","")
Current song has been finished.

JukeCommand("JUKE_SONG_RESTART", "")
this is sent when a song have been restarted, regaardless it have been played the finished or selected by user.

Juke_Command("JUKE_SONG_SKIP","")
Current song has been skipped.

Juke_Command("JUKE_SONG_PAUSE","")
Current song has been paused.

Juke_Command("JUKE_SONG_RESUME","")
Current song has been resumed from pause state.

Juke_Command("JUKE_SONG_PLAYMODE", "AnyMode")
A which play mode is it in? It can example been "Radio", "Random", "No songs in queue", total numbers of song or something text of value about the playmode. That info should just display in the Plugin Display. Not to been parsed in any way.

Please Note:
a UTF8 string might been sent if unicode is set to TRUE.



Juke_Command("JUKE_SONG_FASTFWD_START","")
Current song has started being fast forwarded.

Juke_Command("JUKE_SONG_FASTFWD_FINISH","")
Current song has finished being fast forwarded

Juke_Command("JUKE_SONG_FASTREV_START","")
Current song has started being fast reversed

Juke_Command("JUKE_SONG_FASTREV_FINISH","")
Current song has finished being fast reversed

Juke_Command("JUKE_SONG_PLAY_POSITION",curPosSecs|totalDuration)
The number of seconds into the current song. This command is also still invoked under FASTREV or FASTFWD commands.

DIGIT COMMANDS:

Juke_Command("JUKE_ENTER_ALBUM_VALUE", "VALUE")
Send the value string on the marked album, when the have entered a album number or letter.

Juke_Command("JUKE_ENTER_TRACK_VALUE", "VALUE")
Send the value string on the marked track or singles, when the have entered a album number or letter.

A Track number and or letter have been selected. Send the whole value, user seen on screen and not one digit at one time.

VOLUME COMMANDS:

Juke_Command("JUKE_VOLUME_CHANGE", "system|curVolumeLevel|minVolumeLevel|maxVolumeLevel")
A new value volume have been changed or set....

If system is changed the volume (etc the radio feature or such), the last argument is set to one.

Juke_Command("JUKE_VOLUME_MUTE", "TRUE or FALSE")
Set Mute Status to TRUE or FALSE.

FEATURE COMMANDS:

All FEATURES COMMANDS that was in the beta versions is removed. You as Jukebox author can define any feature as  PLUGIN_EVENTS, and can been any feature suitable to your Jukebox software.

SDK for these commands:

http://forum.arcadecontrols.com/index.php?topic=75378.0

[loadman]

So this thread is just for Function comments then?      

Sorry, my crazy sense of Humor (or lack of)

It would be good to have a fuxtion that updated the time remaining on a song. Not all jukebox have to support it (if performace issues arrise) .

That would be nice on a external LCD display supported by the PLug-in.

JukePlayRemain(remain$) ;

[unclet]

How about some functions for these:

- Skip song (ie: skip currently playing song to go to the next song (if one exists))
- Mute On/Off
- Flipping through pages of album covers (pageLeft, pageRight)
- Fast forward active (ie: searching through video/audio forward quickly)
- Fast reverse active (ie: searching through video/audio backward quickly)
- Party Lock activated/deactivated
- Attract mode activated/deactivated
- Move song from one queue position (X) a new queue position (Y)
- Removed song from queue from position (X)
- Clear queue contents
- Enter digit 0,1,2,3,4,5,6,7,8,9
- Delete the last entered digit

Also, I would think "JukeSecsRemain()" would be better than "JukePlayRemain()"

PS:  Thanks for renaming SongStart to SongBegin   

[Barry Barcrest]

IHMO It Shouldn't send how many seconds remain. It should send the current play position and the track duration so the plugin writter can display amount of time remaining or played and the total time or not they will have all that information to hand.

I don't have the option to add everything to the queue so i wouldn't want that in the standard set of plugins because i wouldn't support it, not sure about uncleT's but i think the standard set should only contain things that would be used in all software, then if you want to expand on that for specific plugins for your software that's fine.

Some functions i thing might be useful.

- Pass the playing song path, Expected return (Album, Artist, Title Tag values)
- Pass the now playing cover art path (Some plugins might want to display that)
- Is the song user selected or random? (Plugins can behave differently depending)

I have support for LED Signs in my juke however it would be cool if we get the plugins to work to replace those with a plugin. For this we would probably need...

- Pass a stirng to display (Be this on an LED sign or graphically somehow on a vis type plugin)

Hopefully that gives some ideas.

[loadman]

- Skip song (ie: skip currently playing song to go to the next song (if one exists))
- Mute On/Off
- Flipping through pages of album covers (pageLeft, pageRight)
- Fast forward active (ie: searching through video/audio forward quickly)
- Fast reverse active (ie: searching through video/audio backward quickly)
- Party Lock activated/deactivated
- Attract mode activated/deactivated
- Move song from one queue position (X) a new queue position (Y)
- Removed song from queue from position (X)
- Clear queue contents
- Enter digit 0,1,2,3,4,5,6,7,8,9
- Delete the last entered digit

Question:  Are you talking about letting the Plug-In Know that the operator is making these selections on the Jukebox software or having the ability to have the Plug-in remotely control the Jukebox. 

If it's the latter then it's a whole new can of worms. Wouldn't you need to use something like windows messaging like MaLa does. That way the JukeBox software is 'listening' for commands.

IHMO It Shouldn't send how many seconds remain. It should send the current play position and the track duration so the plugin writter can display amount of time remaining or played and the total time or not they will have all that information to hand.

Sure. Whatever works 

[unclet]

loadman
Yep..... just letting the plugin know everything the software user is doing.   I dont like worms   

Barcrest
I do not understand why this standard set of plugin routines need to be supported by all jukebox software?   If your software does not support a routine, then this should be documented appropriately so plugin authors know this before they start coding.   

I would believe a chart in the Jukebox Wiki could list all of the jukebox plugin routines (being gathered here) and then have an indication as to which jukebox software supports which routines.

Maybe I am missing something .... but I know already I am not going to support some of these routines anyhow but I think it is nice to list them all.

[Barry Barcrest]

If we are adding routines that will not be supported we might as well be making our own plugins this is why we need to agree on a set standard that we would all impliment so the plugin fits that standard and would work with all the software. If you only support some of the functions and i support a different set and multijuke has yet another set it makes this project pretty much usless as there is no real cross compatability. That is why i thought we had this thred to agree a sort of standard.

[Space Fractal]

I have updated the list with ideas form your what I thinking.

Missing something?

About the playercontrols, all software have deficent controls, but I think I found a way to doing that. Look on the list what I added.

[loadman]

I have updated the list with ideas form your what I thinking.

Missing something?

About the playercontrols, all software have deficent controls, but I think I found a way to doing that. Look on the list what I added.

The list you updted at the top of this thread is looking good. It would good to finalise this soon.

[Space Fractal]

I again changed the list, and this list is still might not been finalized. Need more input from authors.

I have removed JukePlay functions because the plugin is allready know info about the song. It is checked by JukeSelected functions before adding a song.

Any changes on the queue should use QueueClear() and resubmit all songs again (Single Add2Queue entry unless).

Did that since it was no need to tell the plugin twice !!

[loadman]

I again changed the list, and this list is still might not been finalized. Need more input from authors.

Suggestion:  Can you remove the 'code quotes' from the list.

It's frikken hard to read (for me anyway).  Can you use colors and/or bold to highlight the different functions?

[unclet]

Should we add my suggestions or not?  If not, then no problem it will save me some time not to have to support them, but I think some plugins might find some of these handy.

- Skip song (ie: skip currently playing song to go to the next song (if one exists))
- Mute On/Off
- Flipping through pages of album covers (pageLeft, pageRight)
- Fast forward active (ie: searching through video/audio forward quickly)
- Fast reverse active (ie: searching through video/audio backward quickly)
- Party Lock activated/deactivated
- Attract mode activated/deactivated
- Move song from one queue position (X) a new queue position (Y)
- Removed song from queue from position (X)
- Clear queue contents
- Enter digit 0,1,2,3,4,5,6,7,8,9
- Delete the last entered digit

EDIT:
Actually I see you added the "Clear Queue" one .... but I do not see any other ones.

[loadman]

Should we add my suggestions or not?  If not, then no problem it will save me some time not to have to support them, but I think some plugins might find some of these handy.

- Skip song (ie: skip currently playing song to go to the next song (if one exists))
- Mute On/Off
- Flipping through pages of album covers (pageLeft, pageRight)
- Fast forward active (ie: searching through video/audio forward quickly)
- Fast reverse active (ie: searching through video/audio backward quickly)
- Party Lock activated/deactivated
- Attract mode activated/deactivated
- Move song from one queue position (X) a new queue position (Y)
- Removed song from queue from position (X)
- Clear queue contents
- Enter digit 0,1,2,3,4,5,6,7,8,9
- Delete the last entered digit

EDIT:
Actually I see you added the "Clear Queue" one .... but I do not see any other ones.

Wow I just noiced that too and was about to edit my previous post to ask about UncleT's suggestions..   

[Space Fractal]

I again changed the list, and this list is still might not been finalized. Need more input from authors.

Suggestion:  Can you remove the 'code quotes' from the list.

It's frikken hard to read (for me anyway).  Can you use colors and/or bold to highlight the different functions?

Done

Should we add my suggestions or not?  If not, then no problem it will save me some time not to have to support them, but I think some plugins might find some of these handy.

- Skip song (ie: skip currently playing song to go to the next song (if one exists))
- Mute On/Off
- Flipping through pages of album covers (pageLeft, pageRight)
- Fast forward active (ie: searching through video/audio forward quickly)
- Fast reverse active (ie: searching through video/audio backward quickly)
- Party Lock activated/deactivated
- Attract mode activated/deactivated
- Move song from one queue position (X) a new queue position (Y)
- Removed song from queue from position (X)
- Clear queue contents
- Enter digit 0,1,2,3,4,5,6,7,8,9
- Delete the last entered digit

EDIT:
Actually I see you added the "Clear Queue" one .... but I do not see any other ones.

COMMAND EVENTS (before keyevent) is now just changed for commands set for remote controls. This is the most universal I can do, since all software have defficent commands.


About the queue:
Clear the queue and resubmit all songs again if you changed something speciel in your queue.

[loadman]

Cool Layout

JukeGetPluginInfo(Title$[256], Album$[256], Title$[256], UTF8)

Is this a mistake?  Should it not be something like:

JukeGetPluginInfo(Name$[256], Author$[256], Version$[256], UTF8)

[Space Fractal]

Cool Layout

JukeGetPluginInfo(Title$[256], Album$[256], Title$[256], UTF8)

Is this a mistake?  Should it not be something like:

JukeGetPluginInfo(Name$[256], Aithor$[256], Version$[256], UTF8)

ops. Corrected.

One command changed again, but just added a new argument (Add2Queue).

[unclet]

If we are adding routines that will not be supported we might as well be making our own plugins this is why we need to agree on a set standard that we would all implement so the plugin fits that standard and would work with all the software.  There are other routines as well .....

 

I do not plan on implementing everything in Space Fractal's list anyway so this is why I did not understand why adding other routines would be a big deal.   My software does not support credits or tags, does not have it's own screensaver and also uses my own developed database system for storing and retrieving information.   As a result, those routines related to all of this stuff will not be supported by my software. 

Lets just say all of our jukebox software supports everything in Space Fractal's list.  I would expect eventually someone is going to ask me to add a plugin routine which is specific to my software only.    If they release this plugin, then it will not work with any other jukebox software anyway.    My point is ..... eventually all of the plugins which are going to be made probably will not be able to be used with other jukebox software evenbtually.   Perhaps right at the beginning they will be standard enough to be used with any jukebox software, but I bet as they become more sophisticated over a short time then they will become jukebox specific anyways.

As a result, I thought the point of Space Fractal's list was to simply come up with a standard set of routine names which any jukebox software could use since the name and interface would be standardized.    Having a website (like you proposed) would be helpful is it included a spreadsheet listing each plugin standardized routine name and parameters along with which jukebox software supports it.  It could then be up to the plugin author to make sure their plugin can be used with multiple jukebox software or not.

If this is not the intent of Space Fractal's effort, then I do not think my software can support all of what is listed.



Space Fractal

I would prefer not to have to write a Command Event file ....... I understand what you are trying to do, but I would rather have individual routines for each plugin function such as:

JukeAppMute(on/off)
JukeQueueSongRemoved(queueLocation)
JukeQueueSongUserDelete(queueLocation)
JukeQueueSongMoved(oldlocation, newlocation)
JukeQueueSongAdded(name, artist, album, queueLocation)
JukeAppPartyLock(on/off)
JukeAppAttractMode(on/off)
JukeAppPageFlip(left/right)
etc... etc... etc...

This seems a lot easier to maintain and much more clear to me.

[loadman]

the intent of Space Fractal's effort, then I do not think my software can support all of what is listed.

I agree in part. The idea of having a standard 'in my eyes' is so that a plug-in was to make life easier for the plug-in writer. Sure inevitably the standard will be broken, but if the standard is similar at least, porting it will be trivial.

I don't think that Jukebox software writer should be forced to support all functions. But the one they do support should conform to the standard. I think as smart plug-in authors we can use the functions supported the best we can.

So keep the list I say 

[Barry Barcrest]

I just thought it would be good to only functions we all agreed we would support. I only say this because if a plugin is released to support this standard then it should work in all software that says it supports this standard.

If we are not going to do this then we don't need a name for any type of standard or even a standard list of functions.

I'm torn because i agree with uncleT in that i don't want some of the functions above to be used in my juke and i have stuff that spacefractal and uncleT probably don't want. However i would also like any plugin made to work across the board.

I don't really know how this is going to turn out but hopefully you at least have an idea of what i am trying to say about having a standard.

[Space Fractal]

Hi unclet.

I known freebox and MultiJuke support all. but....

I think not all features need to been software, if it NOT needed by application. If credits is not needed, it no need to have a plug in using that. They search for other plugins for other info. Credits is acutely very Small features which might been good for a LCD plug in (which a configuration of that could disable that feature if not needed).

I also doesn't care how you read your tags or they are pulled from directory (mine example can even disabled id3 tags). Plugins is never read ed from the database file. They stored deficient. Instead you should simply sent these info from your database as strings you allready use for displayed for your user.... If Special is not used (which MultiJuke does NOT support) is not used, just send a empty string to it. It completely fine. Even In MultiJuke it might send even empty album strings.... Might be I should remove that speciel tag$?

For database naming, for your software it should been "Albums" and "Movie" if I can see correct? In Freebox it would been "Albums", "Movies" and "Karaoke", It all. It not the database filename it self, but what the user selected in your software.

Otherwise this is why I created this thread. Something I should change?

Give any idea what I should change? Should I rename screensaver to something other? Like Idle detect or such?

[unclet]

I agreed 100% it would be nice to have one plugin work with many jukebox software without having to change the pluging at all ...... but come on .... do you really think that is feasible?   Look how fast people write plugins and how fast they ask software developers to support more routines to allow them do what they want to do in their plugins.   If someone asks me to support a new routine, should I first make sure whether all other jukebox software is going to support it, before I implement it myself?   That does not make that much sense to me.

This is why coming up with a standard routine list is handy along with a list of what jukebox software supports what routines.    I think the effort to "standardize the routines" (and their parameters) which might be used by various jukebox software applications would be much more powerful.    For example, my software does not sipport coin credits at all.  But lets say I decide to put this feature into the software 6 months from now, I would not create my own plugin routine for this, but instead use the standard plugin routine defined by Space Fractal ......  this is where the value of "standardization" comes in ...... in my opinion.

Space Fractal
I know I could populate the ID3 Tag information with the proper information from my database, but I think this would be misleading to plugin authors.  They would assume that if my software supports the ID3 Tag routines, then this information is actually coming from the ID3 Tag information located in the music file itself  ..... and this would not be the case.   It would be much more clear and correct to simply state that my software does not support the ID3 Tag routines.

[Space Fractal]

JukeSelectedtags is renamed to JukeSelectedSong.

Credits features is now completed removed.

The idea about remote controlled was think ed with unclet in mind here. I just need to change bit to trying to fit all software due with deficient command sets. Something I have oversaw here?

I left screensaver by now, but again I can remove these commands and move into the command api instead (because they can add screensaver commands in the list)?

And the list the database command is removed. It was really bad here. Could go to the speciel tag instead if needed and can left empty if not used.




 

[loadman]

I think the effort the "standardize the routines" (and their parameters) which might be used by various jukebox software application is much more powerful.   

 

Can we agree on this point at least?

With a view that Jukebox authors will support as many as they reasonably can?

As a Plug-in writter I will write my code so if a particular function is not supported it will still work.

[Space Fractal]

removed screensaver functions at all !!

A plugin writer can of course make a screensaver feature in their configuration if a sceensaver is needed. So screensaver features is NOT needed at all. Removed them.

I might add these 2 completly optimal credits functions back, because I wanted to create a  statics plugin who did pay song and which songs they have paid (for MultiJuke, Freebox, and other that used credits). Why I added them.

[Barry Barcrest]

I agreed 100% it would be nice to have one plugin work with many jukebox software without having to change the pluging at all ...... but come on .... do you really think that is feasible?   Look how fast people write plugins and how fast they ask software developers to support more routines to allow them do what they want to do in their plugins.   If someone asks me to support a new routine, should I first make sure whether all other jukebox software is going to support it, before I implement it myself?   That does not make that much sense to me.

Well in an ideal world you could add it to your jukebox instantly and the plugin would be specific to your software and not be hosted as being compatible with this system because it wouldn't be due to the extended features.

However the plugin in authour could suggest a change to this feature set making it say 1.1 and then other software can add support if they wish...

I am sounding like a stuck record i know but i don't see why this thred exists if we are not going to agree on a set standard. If some software says it will open up a .RTF file i expect it to render the file properly, not do everything except display the BOLD, UNDERLINE or ITALIC settings because they are not supported. It is not then working to the .RTF standard is it.

If we are not all supporting the same set of functions then this list should be the ones we are all supporting. Then if we want to add other functions we will need to develop these seperately. I don't see why no one else thinks this is an issue. I will not post about it again and i'll sit back and see what you guys eventually hammer out.

[loadman]

OK How about a compomise?

Change the list into two groups

Compulsary Options to met the format standard (just the basics):

Then some optionals: 

[Barry Barcrest]

OK How about a compomise?

Change the list into two groups

Compulsary Options to met the format standard (just the basics):

Then some optionals: 

This will sort of work, i thought this thred was to sort out the compulsary options only.... Anything else can then be added individually with any plugin using those will being jukebox specific.

The songstart routine we have in the plugins now should really only need the path/filename passed to it. The plugin author could then read whatever tags, duration, artwork etc from the file they wanted. That way with uncle T not using tags it wouldn't matter because it would be down to the plugin to sort all that out as it would be passed the file location. EDIT: Might need to record if it is random song or user selected so maybe a 1 or 0 flag as a second varible to the pathname.

The song end doesn't need to be passed anything, just tell the plugin the song has ended.

Jukeadd2History, this isn't needed at all. Somebody could code a plugin that records all songs passed with the song start call to a history file. That would be the function of that plugin, so no need to call that as a function in the plugin. Likewise if it records if the song passed is a random song or user selected song the plugin author can record only user songs or random songs or all songs.

Thoughts?

EDIT: actually looking at it, what are we expecting these plugins to do? Most of the options listed here seem like they are pretty pointless for plugin authors to make use of. The song start and end are the real usefull ones. I don't see why plugin authors would need any of the others. Plugins to control lights or whatever would only need to know if music was playing or not. Why does it matter if a song is added to the queue or the queue is cleared? What plugin would do anything on those events?

EDIT2: Also did we find out how visual basic can read info back from the plugin? I didn't think that was working which would also make those command options pretty much useless.

[loadman]

This will sort of work, i thought this thread was to sort out the compulsory options only.... Anything else can then be added individually with any plugin using those will being jukebox specific.

Cool   I still think the optionals have a place in this thread, we may as well start with them having the same type of format to make it easier for coders

EDIT: actually looking at it, what are we expecting these plugins to do? Most of the options listed here seem like they are pretty pointless for plugin authors to make use of. The song start and end are the real usefull ones. I don't see why plugin authors would need any of the others. Plugins to control lights or whatever would only need to know if music was playing or not. Why does it matter if a song is added to the queue or the queue is cleared? What plugin would do anything on those events?

Yeah  for what I want to create, LCD and LED drivers and a random wav generator (for fun between songs) I don't need many events.  The main thing I need is song info on select/play and a way to display/calculate song remain for LCD Display. A time-out / sceensaver function would be nice but I can also trigger a Led display based on a duration from last song played. I mean you can make plug-ins smart. You don't need to be spoon fed every detail.

EDIT2: Also did we find out how visual basic can read info back from the plugin? I didn't think that was working which would also make those command options pretty much useless.

I thought JukeGetPluginInfo was tyhe only thing that needed that.? Anyway it's existance verified even if it does not pass data is better than nothing.

Yep, that don't work yet but it's no big deal.  You could use a separate Plug-in manager written in another language if you wanted to verify, Author, Version etc

[Space Fractal]

JukeCommandGet() is also the other functions that have a feed back from the plugins, if they want to make a control based plug in (like over network or such).

Add2History() is usefull if they do NOT want to add the song to plugin's song history. This can caused by song skipping or a song diddent play for other reason.

All Selected type commands is now joined to Add2Queue(). Not all song info might been added to that, so I think this is a comprises?

Also just added JukeSongSuggestion() which is a another feedback command, which can been useful for companies like MusicIP.

Brown marked commands is NOT need to been supported by the software. I guess that is a good comprimes?

[Space Fractal]

Hey, Barcrest, you have right about Add2History(), after I saw your post, so it busted.

I have just added a value to JukeSongEnd() instead.

It now up to the plugin writers how the history should been used, if they want that....

[unclet]

I think I will wait until you guys figure out everything you want and get it working and then I can have a look at it and try to implement what I can.   I am not too crazy about using one common wrapper to interface and gather information for each plugin.   If something needs to be changed, then I have no control over editting this wrapper function.  Also, I am not sure how all ofthese routines should be used correctly so I might wait until people get all of this stuff working before I jump in.

This will sort of work, I thought this thread was to sort out the compulsary options only.... Anything else can then be added individually with any plugin using those will being jukebox specific

This is exactly my point ....... if we can standardize some of these "anything else" routines which are not yet common to all software applications then when the functionaility is added to the software at a later date, then the standardized routine interface can be used instead of having new routines added individually.   

If a brand new routine is required which is not yet used by any other jukebox application then the jukebox software author can document the new routine interface in the Jukebox Wiki (for example).   Then as other jukebox software adds this functionality, then they can use this new standardized routine instead of making one which is jukebox specific

Anyway, I think I might be slowing the progress down in this thread a bit, so I will sit back and watch for awhile to see how it goes.  In the meantime I will work more on my own jukebox build ..... need to get that done now before I spend more time on this new activity.

[Space Fractal]

I think I will wait until you guys figure out everything you want and get it working and then I can have a look at it and try to implement what I can.   I am not too crazy about using one common wrapper to interface and gather information for each plugin.   If something needs to be changed, then I have no control over editting this wrapper function.  Also, I am not sure how all ofthese routines should be used correctly so I might wait until people get all of this stuff working before I jump in.

This will sort of work, I thought this thread was to sort out the compulsary options only.... Anything else can then be added individually with any plugin using those will being jukebox specific

This is exactly my point ....... if we can standardize some of these "anything else" routines which are not yet common to all software applications then when the functionaility is added to the software at a later date, then the standardized routine interface can be used instead of having new routines added individually.  

If a brand new routine is required which is not yet used by any other jukebox application then the jukebox software author can document the new routine interface in the Jukebox Wiki (for example).   Then as other jukebox software adds this functionality, then they can use this new standardized routine instead of making one which is jukebox specific

Anyway, I think I might be slowing the progress down in this thread a bit, so I will sit back and watch for awhile to see how it goes.  In the meantime I will work more on my own jukebox build ..... need to get that done now before I spend more time on this new activity.

Not all commands is even need in MultiJuke, one of them was a ideas by Barcrest. I have not planing to support Juke_SongTags() by my self, because I do not use videos. Pretty sure it would work by your software, if you a day want id3 tag support using a plugin.

And example MultiJuke and your software is different how the queue can been handled. Multijuke can insert a whole album, auto added by system, but yours can manipulate queue directly (not used by MultiJuke). Here I got the idea to use a resubmit system, that can suit its all.

These brown marked commands is not important ones to been used, but they can been very useful. Im are pretty sure any Plugin Writes make sure its would works with all software, even they now not all brown marked commands is not used by a software. Some plugins might do speciel on these commands alone, hence they would write about it (tagging example).

I guess I even got all your requests in the SDK (queue changes and remote controlling).

If you are not sure how a command should been used, let me know. I might wrote some mistakes in the first post.

Of course I can still update the wrapper with new commands, even after version 1.0 and I have even included the source code as well to been ported to other languages. That dll is completly open source....

Oterwhice, Do you have other requests?

[unclet]

I think you are doing a fine job .... it is just hard for me to spend a lot of time on this right now.   I will see how it all works when everything is designed and then add stuff in my software as well.

[headkaze]

I really don't see the point to the commands.txt file. If the Jukebox never sends the command to the plugin it will never receive it therefore there is no support it. If a Jukebox does support the command it will be sent it and the plugin can do something with it. Why does the plugin need to know which commands the jukebox supports? I like unclet's idea of having a list of standard commands and just send over the ones you use.

They could be either constant's/enums that represent numbers or just string constants. Strings would probably be easier.

Eg. (from unclets post)
JUKE_PLAY
JUKE_VOLUME_UP
JUKE_VOLUME_DOWN
JUKE_PARTY_LOCK_ON
JUKE_PARTY_LOCK_OFF
JUKE_MUTE_ON
JUKE_MUTE_OFF

Since they are just strings you can have unique commands for your juke and commands that are supported by most jukes.

[Space Fractal]

I removed the commands.txt and create a function instead that does the same. I update the SDK to have some mean with these commands.

I would want to create a remote plugin with full support of all commands constain in a software. Some commands might have a on/off commands (Juke Party example).

In MultiJuke I example have 4 action commands that does defficent things, that would been good for commanddisable and commandenable events for Ledwiz control.

In DWJukebox example in the singles view, that last buttons light could been disabled off if the list of songs is scrolled to the bottom (or disable lights on other letters if I pressed D button example).....

[unclet]

Since they are just strings you can have unique commands for your juke and commands that are supported by most jukes.

Yes, this is my point  ..... this list could be expanded to standardize commands which are currently only used by some jukebox software.  In the future, if a particular command is integrated into some other jukebox software, then at least the command has been standardized and already included in this list ....... so the software does not need to create it's owm unique at that time.   We can all stay standardized based on the "PlugMyJuke" standards.   Just some jukebox software will support some of the commands and other jukebox software will support newer ones.

I also agree "strings" would probably be better than enum values....

[Space Fractal]

The only problem is some commands is very diffecent for the nearly same feature.

MultiJuke example I use GENRE_LOCK instead of PARTY_LOCK. Freebox if I remember correct use CAUSAL for the same feature.

I could change the commands to only use the most used commands, but many unique command would not been controlled (ALL software have unique commands, that is why they wrote they own software)....

Now the commands.txt is gone, how could the external plugin known about the command used by the software?

Should the plugin writer just tell the user, you need to init the plugin once for first time, so the plugin can get the command list (because I asume the plugin writer would save the command list as well when it quit)? Not a problem for me.

We could even use a basic default list, that can been expandedable by the jukebox software with its unique commands?

[headkaze]

The only problem is some commands is very diffecent for the nearly same feature.

MultiJuke example I use GENRE_LOCK instead of PARTY_LOCK. Freebox if I remember correct use CAUSAL for the same feature.

I could change the commands to only use the most used commands, but many unique command would not been controlled (ALL software have unique commands, that is why they wrote they own software)....

Now the commands.txt is gone, how could the external plugin known about the command used by the software?

Should the plugin writer just tell the user, you need to init the plugin once for first time, so the plugin can get the command list (because I asume the plugin writer would save the command list as well when it quit)? Not a problem for me.

We could even use a basic default list, that can been expandedable by the jukebox software with its unique commands?

The author doesn't need to know what commands are used by the software. But they should be able to read the documentation that comes with your Jukebox if they want to see which ones are supported.

Here is how it would work in the plugin

Code: [Select]

int Juke_Command(String Name, String Value)
{
switch(Name)
{
case "JUKE_PLAY":
break;
case "JUKE_VOLUME_UP":
break;
case "JUKE_VOLUME_DOWN":
break;
case "JUKE_PARTY_LOCK_ON":
break;
case "JUKE_PARTY_LOCK_OFF":
break;
case "JUKE_MUTE_ON":
break;
case "JUKE_MUTE_OFF":
break;
}

return 1;
}
If your Jukebox software doesn't send one of the commands the plugin will never receive it, so that function is not used in your Juke software. If your Juke does support the command and sends it then the plugin will process the command.

Like I said the plugin does not need to know what commands are supported. The author of the plugin only implements the commands that he/she wants to. If the software supports it then that function of the plugin works, if not it doesn't.

[Space Fractal]

The implement of the commands for the plugin should been configurated by the user, not by the plugin author. That is why they might use a executeable exe file for its plugin.

It simply up to the user of that plugin, how the commands should been used and how.

Example if I want to use a Sound Effect plugin:
I might want to play a sample when a "CoinInsert" command was sent by Jukebox Software to make a coin sound. The command list in the plugin config configuration would been a list form.

Because all commands was sent to the plugin using Juke_CommandList() (I rename to that to avoid confuction instead of Juke_CommandInit), the plugin known there is a "CoinInsert" command.

In this case the plugin writer does not really need response back to the user, but just listen to the Juke_CommandSend() for any commands sent (just changed the name to that).

I also asume the Plugin Writer use a linked link, not a array, system that hold all used commands and they known some commands can use as a switch (marked with a *).

[Space Fractal]

I just updated the SDK with the changed name and the example plugin, due for few functions changed around Juke_Command thing.

I have included *.lib files for importing dll functions easier (for those language that use them).

[unclet]

MultiJuke example I use GENRE_LOCK instead of PARTY_LOCK. Freebox if I remember correct use CAUSAL for the same feature.

Based on my recommendation you would simply add the following to the string values:

JUKE_PLAY
JUKE_VOLUME_UP
JUKE_VOLUME_DOWN
JUKE_PARTY_LOCK_ON
JUKE_PARTY_LOCK_OFF
JUKE_GENRE_LOCK_ON
JUKE_GENRE_LOCK_OFF
JUKE_CASUAL_ON
JUKE_CASUAL_OFF
JUKE_MUTE_ON
JUKE_MUTE_OFF


The author of the plugin would then group similiar strings together like the following to make it work with all jukebox software:

int Juke_Command(String cmdName, String cmdValue)
{
   switch(Name)
   {
      case "JUKE_SONG_BEGIN":
      break;

      case "JUKE_SONG_END":
      break;

      case "JUKE_PLAY":
      break;

      case "JUKE_VOLUME_UP":
      break;

      case "JUKE_VOLUME_DOWN":
      break;

      case "JUKE_PARTY_LOCK_ON":
       case "JUKE_GENRE_LOCK_ON":
       case "JUKE_CASUAL_ON":
      break;

      case "JUKE_PARTY_LOCK_OFF":
       case "JUKE_GENRE_LOCK_OFF":
       case "JUKE_CASUAL_OFF":
      break;

      case "JUKE_MUTE_ON":
      break;

      case "JUKE_MUTE_OFF":
      break;
   }

   return 1;
}

Like loadman mentioned previously, the author of the plugin should really make sure their plugin works with all jukebox software themselves.  This way the final "plugin" can be used with "any" jukebox still.


EXTRA
I also think it might be nice to inform the plugin of certain values such as "VOLUME_MIN" and "VOLUME_MAX" values.   This will allow plugin developers to know  what the range of volume can be (ie: in my software it is 0 to 100) in case they wish to make some neat LCD lighting to indicate how high the volume is.  If they never knew the min and max values they would not be able to do this.   now, there are probably other values which should be sent as well, but the VolumeMin and VolumeMax are justa couple examples.   however, all this means is that we add a couple more set values as follows:

JUKE_VOLUME_MIN
JUKE_VOLUME_MAX

These values will most likely only needed to be sent once (on bringup of the jukebox).

[Space Fractal]

I can't see why that is needed which would been very code overhead, due to a few diffecent from software to software?

It's matter to create a good configuration in theplugin to suit all commands in all software.

Look in the Sound Effect example I gave, not all use a CoinInsert command. Since your software does not have a CoinInsert command, the plugin would never listed that in thier configuration part, because they never got the command when you sent all commands used by your software using Juke_CommandList(). Hence you send a commandlist after a init().

I cant see I can do more universal?

That I trying to say, it a list of commands the jukebox software actuelly use and no more. Otherwice the user would been very confuction with unused commands in the plugin.


If a new command is developmented with a update, simply add that one to the juke_commandlist() as well. Plugin would simply automatic update its command list with the new command, because it got a new one when listed to juke_commandlist(), and the new command would been configurable by the user in its plugin config.

Due to that, no need to document new commands by a jukebox author.

Hence it expandande for future use with new commands.

_____

Volume: Done, I just added 2 extra arguments to the volume command. No need to create 2 own commands for that.

[headkaze]

JUKE_VOLUME_MIN
JUKE_VOLUME_MAX

I don't see the point of these values. Just have the range from 0 to 100. Then if the Jukebox software has a different range (Eg. 0 to 1024) then a simple calculation will convert it to the accepted range for the plugin.

Eg. int Volume = 512;

JukeVolume((Volume / 1024) * 100);

[unclet]

Space Fractal

It's matter to create a good configuration in the plugin to suit all commands in all software.

I have my doubts as to whether this will be possible since each software does not plan on using the full set of routines anyway.

Also, I still do not understand why a plugin has to create a command list of it's own. 

I plan on having my jukebox software simply call a main routine like the following when an event occurs:

Juke_Command(String cmdName, String cmdValue)

headkaze
Imagine if loadman wants to make an LCD lighting plugin which increases/decreases lights do to volume.   When the volume is at the max, then "all" lights will be on.  When the volume is at the min, then "one" light is on only.    In order to do this correctly I thought the plugin author should know what the max/min values of the volume are set to in the software.

Now if you are proposing the JukeVolume() routine only ever return a value between 0 and 100, then you do not need my new proposed values.   I was just not sure we wanted to restrict the JukeVolume() limits to be 0-100 only.   Introducing my new values allow the plugins to know the exact volume setting of the software.  Seems like a better idea in my opinion instead of rounding the volume level to be between 0 and 100.

 

[Space Fractal]

If you as Jukebox Author do not need to send a full list to the plug-in, You do not need to that. Its up to you.

The plug-in need to known which commands that is available to use, otherwise the user can not configurere what commands that would do that in the plugin configuration. Example to play a sound when the plugin got a "CoinInsert" command.

The commandList() is ONLY meant for the plugin configuration part have any use of available commands, show to user.

Any swtich commands like party_on of party_off is sendt via same string to commandlist(), so the plug is aware that command have a on/off stwich.

Because of above, Juke_Command() have only one argument, that is the command you want to sendt, you known that is on the commandlist().

Example after you have init() the plugin:
 Juke_CommandList(0, "*Mute On, Mute Off")
 Juke_CommandList(1, "Volume Up")
 Juke_CommandList(2, "Volume Down")
 Juke_CommandList(3, "Clear Queue")

I asume you write a function to do that, so you sendt the list to all used plugin at once.

In the plugin configuration, these 4 command would show to the user, what they want to due. It up to the plugin writer. Not by you.

When you so want to send a command, due this somewhere in your software needed:
 Juke_command("Volume Up")

Plugin would now find "Volume Up" in its lists, becaue you have send a commandlist() with that name after init() and would do something in the plugin seleceted by the user somewhere on its configuration. It allways the user that select, what it should do, NOT by the plugin author.

For switch commands it more for remote controlling when you want to listen to any commands, also respons from the plugin (here you might need to use the wrapper I gave in the other thread). Can also been used for other thing. But for sending it is still one string command, "Mute On", or "Mute Off".

The plugin save its list anytime and should check for any new commands.

[headkaze]

The plug-in need to known which commands that is available to use, otherwise the user can not configurere what commands that would do that in the plugin configuration. Example to play a sound when the plugin got a "CoinInsert" command.

The plugin doesn't need to know if the software has a command! It either sends the command or it doesn't.

So for example in my plugin I have the following

Code: [Select]

int Juke_Command(String Name, String Value)
{
switch(Name)
{
case "JUKE_COIN_INSERT":
PlaySound("CoinInsert.wav");
break;
}

return 1;
}
"Jukebox Software A" supports the JUKE_COIN_INSERT command and "Jukebox Software B" doesn't.

When a coin is inserted in "Jukebox Software A" it sends the command.

Code: [Select]

plugin[i].Juke_Command("JUKE_COIN_INSERT", null);
And the plugin plays the sound.

In "Jukebox Software B" there is no support for the command... So it does NOTHING. The Jukebox software never sends the command and the plugin never receives it.

There is no need for a command list. It's not necessary. Your just over complicating things.

[Space Fractal]

All Juke_Command* functions is removed !!!!

I can't agree, so its better to remove them. otherwise this debate would never end.

I through it was pretty easier for jukebox software writers to support these command, but take a some time for the plug-in writer to get the power of commandlist command for expanded use.

Otherwice it would been very confuction for jukebox authors to tell all comands they used. Suddently we all over 200 commands where under 50% would been used. That seen to hard to tried to tell about that. I wich I could see it was ONLY arvaiable commands that can been used. And here is so the main problem you would use:

The plugin would been out of date very fast when we expand the list, if you dosent update thier plugin with new commands.

That is what I throuch commandlist() could fix, so it was more controlable by Jukebox Software authors.

So, Sorry, but that it !!  I cant take about these commands any more, only if you have better idea how we can use these commands?

I simple dislike a default list, since it can been out of date very fast.

[headkaze]

All Juke_Command* functions is removed !!!!

You still need one Juke_Command(). Hey your entitled to disagree but I feel like you don't understand what I was saying. My thoughts were why add more functions when you don't need them? It will only confuse other coders. If it was necessary I would agree but they are not. One function should be enough.

You got to understand I don't even use Jukebox software so I am donating my time here to help because Loadman asked me to. Hey I understand that English is not your first language so I've repeated myself several times just to help get my point across. Sometimes it seems to take a few posts before you "get" what I mean.

[Space Fractal]

I have created few commands in the MultiJuke since version 1.00... If the plugin could not see these new commands, the user can never use these command in thier plugin to thier ledwiz device or such.

That is the main problem with a fixed list.

I do not like a fixed command list, which dosent have a future. I do like dynmaic list like the queue commands I made, wich require such a linked list anyway.

So we need doing something so we have a dynamic list with various commands... but NO fixed list, otherwice we cant expand and control it by the jukebox software.

any ideas and used arguments? I guess some plugins might need a commandlist to get it configurated by the user.

[headkaze]

I have created few commands in the MultiJuke since version 1.00... If the plugin could not see these new commands, the user can never use these command in thier plugin to thier ledwiz device or such.

That is the main problem with a fixed list.

I do not like a fixed command list, which dosent have a future. I do like dynmaic list like the queue commands I made, wich require such a linked list anyway.

So we need doing something so we have a dynamic list with various commands... but NO fixed list, otherwice we cant expand and control it by the jukebox software.

any ideas and used arguments? I guess some plugins might need a commandlist to get it configurated by the user.

The thing is there are fixed commands and non-fixed commands. Because they are strings they can be anything.

You could have JUKE_DO_WHATEVER_YOU_WANT as a command!

There would need to be a plugin.txt for each Jukebox outlining the commands the software supports. It's up to the plugin coder what commands that want to add support for. Some commands might work in some Jukes some might not.

[Space Fractal]

originally it was a commands.txt that do that purchase, I later removed. UncleT could not see the logic of it.

But should I bring it back? Commands.txt was the best idea for fixed that problem instead of commandlist().

Personly I would wrote my plugin to support ALL commands in commands.txt and let user configuration it what they do. Otherwice it might not been combatible with all software.

And on the other way, if the plugin write only need few commands, let the user tell the plugin which command it really is from the list (etc a list form)...

I might even want to call some commands with other names than others.

[Space Fractal]

I try again.

I added a value to the commandsend value. Any ON and OFF commands should not been used, just set the proper value for that.

It seen a commands.txt should been used (headkaze: instead of Plugin.txt), but I also wrote about a plugin might define a default set used, if the list is not found or not needed. I also wrote to been very clean when they write the commands.txt file.

So it up to plugin write the list would been used or not, but I recommered of course use the list.

Is that one better and cleaner? Depite of that, only 2 commands is now needed istead of 5.

[loadman]

If you as Jukebox Author do not need to send a full list to the plug-in, You do not need to that. Its up to you.

The plug-in need to known which commands that is available to use, otherwise the user can not configure what commands that would do that in the plug in configuration. Example to play a sound when the plug in got a "CoinInsert" command.

I know of a expression: KISS

Keep It Simple Stupid  (No offence) 

I'm with UncleT's/ HeakKaze thoughts on this command stuff.

I agree that 'Space Fractal' does not seem to understand the points made here. A language barrier at a guess.

The documentation with the SDK will tell you what the commands do. If you want to add more update the SDK

Keep the Plug-in Simple and let's get on with starting to build some. 

[Barry Barcrest]

I don't see why the list of things to send to the plugin is complicated. The plugin itself will do most of what it wants it only needs to know when to do it. So song start and end are good things to send across but why send across the maximum volume setting or page change? I can't possibly imagine a plugin will do anything based on that information. Like loadman says lets get some plugins working.

[Space Fractal]

Hey, I think I do not update the first post in a while now (to avoid break any commands by now).

If I should add more commands I still want feedback. Otherwise Should I finalize the current version as version 1.0?

So I do NOT touch the current list from now off, and see what it bringing.

But I might add new commands if somebody have suggestions, but I do NOT change anything with current functions.

Later this I got MultiJuke supported most of these functions as long others.

[unclet]

My thoughts regarding Max/MinVolume and PageFlipLeft/Right commands were simply to supply the plugin with what the software is doing at the particular moment.  I have no idea what a plugin would do with PageFlipLeft/Right or whether any plugin would like to know Max/MinVolume, but then I really do not care what a plugin author does .... I just wanted to supply the plugin author with as many routines as possible so their imagination can "run wild".   Basically, the very reason of me not knowing how a plugin author would ever use these commands is what makes me want to include them. 

[unclet]

For an initial release ...... this is what I would like to do with my jukebox software for plugin support:

I will expect the plugin author to implement one routine called "Juke_PluginCommand()" with "command name" and "command value" strings as interface parameters.  The "command value" obviously holds information related to the "command name".

Here are the list of routines along with the values for each below:

The "cmdValue" is simply a text string in which all data is separated by an "@" character.

int Juke_PluginCommand(String cmdName, String cmdValue)


cmdName                                            cmdValue
-------------------------------------------------------------------------------
JUKE_APPLICATION_OPENED                   n/a
JUKE_APPLICATION_CLOSED                   n/a

JUKE_PLUGIN_CONFIGURE                      n/a

JUKE_SONG_STARTED                            name@artist@album@albumNum@trackNum@totalDurationSecs@
JUKE_SONG_FINISHED                            n/a
JUKE_SONG_RESTARTED                         n/a
JUKE_SONG_SKIPPED                              n/a
JUKE_SONG_PAUSED                              n/a
JUKE_SONG_RESUMED                            n/a
JUKE_SONG_FAST_FORWARD_POS           currentPositionSecs@totalDurationSecs@
JUKE_SONG_FAST_REVERSE_POS              currentPositionSecs@totalDurationSecs@
JUKE_SONG_PLAY_POS                           currentPositionSecs@totalDurationSecs@

JUKE_QUEUE_USER_ADD_SONG               queuePos@name@artist@album@
JUKE_QUEUE_SYSTEM_ADD_SONG            queuePos@name@artist@album@
JUKE_QUEUE_DELETE_SONG                    queuePos@
JUKE_QUEUE_MOVE_SONG                      oldQueuePos@newQueuePos@
JUKE_QUEUE_CLEARED                           n/a

JUKE_VOLUME_CHANGE                           up/down/set@volumeLevel@
JUKE_VOLUME_MUTE_STATUS                  on/off@
JUKE_VOLUME_RANGE                             minVolumeLevel@maxVolumeLevel@

JUKE_ENTER_ALBUM_NUM_DIGIT              digit(0-9)@
JUKE_ENTER_TRACK_NUM_DIGIT              digit(0-9)@

JUKE_ATTRACT_MODE                            onActive/onNotActive/off@
JUKE_PARTY_LOCK                                 on/off@

I would like to add a plugin page to my software.  On this page I would have a button which can be clicked to display the plugin routines I support along with an explanation for each.

I was also thinking of adding a "Configure" button which could be clicked when a plugin has been selected from the list to allow the plugin author to configure their own plugin.   Loadman mentioned this might be nice to have during the testing phase of the plugin.  If this would be nice to have, then one more plugin routine would need to be created by the plugin author (ie: JukeConfigure() routine). 

[loadman]

I was also thinking of adding a "Configure" button which could be clicked when a plugin has been selected from the list to allow the plugin author to configure their own plugin.   Loadman mentioned this might be nice to have during the testing phase of the plugin.  If this would be nice to have, then one more plugin routine would need to be created by the plugin author (ie: JukeConfigure() routine). 

That idea is growing on me (to use in MaLa too is Swindus will do it).  Instead of having to load a seperate executable to configure Plug-ins it would also be cool to do this via the host software (triggering it) 

[Space Fractal]

It pretty a nice idea to use one command, but there is now various commands to fit all you need. You can do this all functions with various functions, so they are all covered in the SDK:

Code: [Select]

JUKE_APPLICATION_OPENED
Juke_Initialize()

JUKE_APPLICATION_CLOSED
Juke_Shutdown(0)

JUKE_SONG_STARTED
Juke_SongBegin()
; do not need to send song info again, since the plugin allready know it using add2queue().

JUKE_SONG_FINISHED
Juke_SongEnd(0)
; EDIT, just corrected a error.

JUKE_SONG_RESTARTED
Juke_SongBegin()
; The plugin did not delete the song from its queue, because Juke_SongEnd(0) was not used.
; can also use the same if you use some thing as song loop and something elsewice.

JUKE_SONG_SKIPPED
Juke_SongEnd(1)
; When a song skipped, the song is also ended. Let the plugin know with setting value to 1.

JUKE_SONG_PAUSED
Juke_SongStatus("PAUSE")
; Plugin can also detect that when listen to Juke_SongPlayed(secs), because seconds diddent count.

JUKE_SONG_RESUMED
 Juke_SongStatus("PLAY")

JUKE_SONG_FAST_FORWARD_POS
 Juke_SongStatus("FAST RESERVE")
 Juke_CommandSend("FAST_RESERVE") ; if it can been used as a keypress command.

JUKE_SONG_PLAY_POS
;no need, the plugin can detect it while listing to Juke_SongPlayed(secs), since the secs change.

JUKE_QUEUE_USER_ADD_SONG
Juke_Add2Queue(File$, totalDurationSecs, 0, CoverArt$="", "+tracknr+" "+name, artist, album, "", "")
; tracknr is not supported, but use it as part of the title name. A plugin might check about it.

JUKE_QUEUE_SYSTEM_ADD_SONG
Juke_Add2Queue(File$, totalDurationSecs, 1, CoverArt$="", "+tracknr+" "+name, artist, album, "", "")
; tracknr is not supported, but use it as part of the title name. A plugin might check about it.


JUKE_QUEUE_DELETE_SONG
Juke_QueueClear(1)
; then resubmit all songs agom you have in your queue using Juke_Add2Queue()

JUKE_QUEUE_MOVE_SONG
Juke_QueueClear(1)
; then resubmit all songs you have in your queue using Juke_Add2Queue()

JUKE_QUEUE_CLEARED
Juke_QueueClear(0)


JUKE_VOLUME_CHANGE
Juke_Volume(volumelevel, minVolumeLevel, maxVolumeLevel)

JUKE_VOLUME_MUTE_STATUS
Juke_CommandSend("MUTE", 0); on
Juke_CommandSend("MUTE", 1); off

JUKE_VOLUME_RANGE
Juke_Volume(volumelevel, minVolumeLevel, maxVolumeLevel)

JUKE_ENTER_ALBUM_NUM_DIGIT
Juke_CommandSend(digit, 0) <- just a a string digit, You might need to use LCDString if you want full LCD control using this function.

JUKE_ENTER_TRACK_NUM_DIGIT
Juke_CommandSend(digit, 0) <- just a a string digit, You might need to use LCDString if you want full LCD control using this function.

in plugindir/Commands.txt you should set these for above example:

Code: [Select]

FAST_RESERVE,0
MUTE, 0
0, 0
1, 0
2, 0
3, 0
4, 0
5, 0
6, 0
7, 0
8, 0
9, 0

About the config:

The main problem is I wont have my software locked while a plugin is on configuration. This because BlitzMax dosent support threads.

Instead the exe file can use the same name as the dll itself, so they can been called from the application. I add such a function in next version on my SDK when I went home. plugin authors dosnet need to do anything, just make sure the config exe is the same as dll name itself.

Adding this function soon to my wrapper to invoke a exe file to its config.

[Barry Barcrest]

So what are the commands we need to support? Do we have a final list now... I assume for the config we just call something like juke_config in the dll and it displays it's config screen?

[Space Fractal]

The current list is now locked, but I can still add new commands.

I diddent add a Juke_Config(), because it might lock the whole software, if some software use OpenGL or DirectX as graphics or such that. But I recommered lugin writes to use the same exe file names as dll itself, so they can been invoked from the software it self that way.

EDIT: Updated the SDK how the plugin writers should place exe file, so they can been found by jukebox software. Hope this method is ok, Barcrest?

[unclet]

in plugindir/Commands.txt you should set these for above example:

I am just not that crazy about using a commands.txt file at all ......

[Space Fractal]

It just to make sure the plugin known the command when the user want to configuere it when config is invoked. I'm pretty sure many plugin writers would take advance of the commands.txt in thier config screens...

Otherwice it would up to the plugin writer to control which default command sets that would been used, and hope it exists in JB software.....

[Barry Barcrest]

If there is no config that can be called from the DLL it seems a bit pointless to me. When you call the config why would it lock the software? It will just display it's config screen on a windows forum wouldn't it. The jukesofware needs to nothing other than pass the call to display the config.

I also don't like the command.txt idea it's all too messy, just like the config being a seperate exe. To be honest i think all i will add support for is song start and end, attract mode start and end and config. I don't see ANY need for anything else as that will allow most things to be handled for plugin authors unless they specifically ask for anything. I think the song start i will just pass the filename across. The plugin authors can then calculate track legnth and read the tag info should they want to.

If that isn't the way you guys are going thats fine you don't have to go with my method. Asi have sadi before i watch what happens here but that is all i see myself implimenting.

[Space Fractal]

about commands.txt:

EDITED THIS TEXT AWAY, wich can been more confuction, I really sorry.

Here is the list that would constain in my commands.txt (which is not even pretty big) which can been remotly tracked by a plugin (status numbers like MOVE_UP, 0 is not really needed):

Code: [Select]

MOVE_UP
MOVE_DOWN
MOVE_LEFT
MOVE_RIGHT
PAGE_UP
PAGE_DOWN
LETTER_UP
LETTER_DOWN

ACTION_BUTTON_1
ACTION_BUTTON_2
ACTION_BUTTON_3
ACTION_BUTTON_4

LOOP
HOME
PAUSE_PLAY
STOP
SKIP
QUIT

LIBRARY_1
LIBRARY_2
LIBRARY_3
LIBRARY_4

COIN_INSERT
COIN_PAID

SCREEN_SAVER_BLANK
SCREEN_SAVER_NORMAL

OK
PARENT
CLEAR
DELETE
0
1
2
3
4
5
6
7
8
9

which commands do other use?

I have planning to create a Network Virtual Remote Controller as plugin to been working with all software and with full command list. Hence I need the full commmand list. You known I might write a plugin or two. Hmm? status ain the command lines is not needed, hence I remove them. Now just a command list would suit my plugin I have in a planning.

Otherwice only ACTION_BUTTON commands need some value feedback to the plugin suit a ledwiz plugin.


attract mode start can been used as a command (ATRRACT_MODE).


I dont think the plugin writers would want to read tags from 10 defficent of file formats, since that is is just a double work, if it just for use with LCD output. A Jukebox Software normally allready have tagged them, and sending song info is also MUCH faster than reading the tags again (and not all software actuelly use tagging).

I only added the tag reponse command to suit your idea, if you want to move all tagging to a plugin (can also been good for UncleT as well, if a tag plugin was wrote, so he can add tag support). The tag plugin is only for database init, not in normal use.

If you need to resumbit a large queue due to PlayNow and PlayNext, it would take quite a while for the plugin reading tags again.....

[Space Fractal]

if a plugin authors ask for more spefics commands, let me known. We can allways create a v1.1 of the command list.

Btw do any use the coin commands (can also been detected as a juke command)?

If nobody need this, I grant to remove them..... Then I dont add that in MultiJuke.


Juke_config() is now finnaly added with a WindowID argument (that can been set to 0). I so need to if I can make a workaround, so the dosent break the OpenGL output, but that is now mine problem to fix. I asume it not a problem in VB6 with a seperate configs....

[unclet]

1) I decided there is no need for a new JukeConfigure() routine to handle a plugin configuration request.   Instead I just added a new command called "JUKE_PLUGIN_CONFIGURE", which has no values associated with it.

2) I changed all "@" separator characters to ">" characters since a "@" character is a valid filename character and this would interfere with the parsing of course .... thanks SpaceFractal!

3) I also added ">" characters to the end of all my command values so parsing each value will be easier since each supplied value will now have a trailing ">" character.

** Keep in mind if some jukebox software does not have all command value information then they do not need to be supplied with the command, but the command value format should remain constant (ie: the same number of ">" separator characters should always be used)

Example1 (album number "1135" and track number "002" is known when song starts):

Juke_PluginCommand("JUKE_SONG_STARTED", "Dirty Pool>Stevie Ray Vaughn>Texas Flood>1135>002>Rock>200>

Example2 (album number "1135" and track number "002" is NOT known when song starts):

Juke_PluginCommand("JUKE_SONG_STARTED", "Dirty Pool>Stevie Ray Vaughn>Texas Flood>>>Rock>200>

Basically, as long as the correct number of ">" separator characters are used then the plugin can parse the text the same exact way and then determine which data has been provided

4) I added "Party Lock" and "Attract Mode" commands


See my updated commands/values list below:

int Juke_PluginCommand(String cmdName, String cmdValue)


cmdName                                            cmdValue
-------------------------------------------------------------------------------
JUKE_APPLICATION_OPENED                   n/a
JUKE_APPLICATION_CLOSED                   n/a

JUKE_PLUGIN_CONFIGURE                      n/a

JUKE_SONG_STARTED                            name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_SONG_FINISHED                            n/a
JUKE_SONG_RESTARTED                         n/a
JUKE_SONG_SKIPPED                              n/a
JUKE_SONG_PAUSED                              n/a
JUKE_SONG_RESUMED                            n/a
JUKE_SONG_FAST_FWD_STARTED            currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_FWD_FINISHED           currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_REV_STARTED             currentPositionSecs>totalDurationSecs>
JUKE_SONG_FAST_REV_FINISHED            currentPositionSecs>totalDurationSecs>
JUKE_SONG_PLAY_POSITION                  currentPositionSecs>totalDurationSecs>

JUKE_QUEUE_USER_ADD_SONG               queuePos>name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_QUEUE_SYSTEM_ADD_SONG            queuePos>name>artist>album>albumNum>trackNum>genre>totalDurationSecs>
JUKE_QUEUE_DELETE_SONG                    queuePos>
JUKE_QUEUE_MOVE_SONG                      oldQueuePos>newQueuePos>
JUKE_QUEUE_CLEARED                           n/a

JUKE_VOLUME_CHANGE                           up/down/set>volumeLevel>
JUKE_VOLUME_MUTE_STATUS                  on/off>
JUKE_VOLUME_RANGE                             minVolumeLevel>maxVolumeLevel>

JUKE_ENTER_ALBUM_NUM_DIGIT              digit(0-9)>
JUKE_ENTER_TRACK_NUM_DIGIT              digit(0-9)>

JUKE_ATTRACT_MODE                            onActive/onNotActive/off>
JUKE_PARTY_LOCK                                 on/off>

In my mind, the "standardization" which should occur is coming up with command name/value strings which all jukebox software should adhere to "if" they wish to implement the command at all.

For example, Barcrest prefers to only implement the song start, song finish, configure and attract mode commands only.   No problem at all .... however, if he agreed to use my approach then he would at least use the "standardized" command names/values:

JUKE_PLUGIN_CONFIGURE                      n/a
JUKE_SONG_STARTED                            name>artist>album>albumNum>trackNum>totalDurationSecs>
JUKE_SONG_FINISHED                            n/a
JUKE_ATTRACT_MODE                            onActive/onNotActive/off>

Again, I would not expect anyone to implement every command name/value, but it would be nice to use one from a standard defining list if you were going to use one ..... instead of coming up with a different one on your own.

[Space Fractal]

you going to create you own standard? Or is is just a internal parser before sent to the Jukebox functions?

If it the last one, remember to backslash any titles or such that contain @, or your parse would break.

I think you can use that parser as internal, but plugin writers can not use any of them, since it would been very compliced for the pluginwriter to support that. The problem is they never known wich command that is used by a JB software....

[unclet]

I like to keep it very simple and like my approach best so I might stick with it.  There is one routine (ie: Juke_PluginCommand() routine) which takes two parameters (command name and command value) and that is it.   It is very easy to add new command names/values, it is easy to expand existing command names/values and it is easy to understand and implement. 

I like "easy" since I do not plan on spending a lot of time on this.  I would like to use something that any plugin author can understand and implement easily thus not having a need for me to constantly explain how to use certain commands and such.  Basically, I would like to implement this plugin stuff and then have people be able to figure out how to use it on their own.

As for what a plugin author would create ..... I really have no idea and really do not care, but I would like to provide them with as many events as possible to let their imagination run wild.  If they would like to recreate their own personal software display instead of looking at my jukebox display screen .... then that is fine with me ..... no problem.   With the commands I supply they should be able to replicate the song queue as well as the currently playing song information along with certain song controls (play, skip, mute, etc...).

I will not be supplying commands for "everything" my software can do since I think that would be overkill, but things I think might be incorporated into a plugin I will provide events.


Good point about "@" character being able to be the text ...... I changed the separator character to ">" instead .... thanks.

[Space Fractal]

sorry to edit my last post (did you read that, if that, forgot it).

The only problem is painfully for the plugin writer to known all commands used, since they never known which command is used, and then can come very fast out of date.

Hence I used real functions with no parser for the plugin. That is much easier for Plugin Writer to use.

Easy for Jukebox Author, but really hard for plugin writers, or did I misforstood something...

______


Plugins is NOT intended to create a new software based on a existing software with same functions...

They are just small feedback things.

[Space Fractal]

This projects seen to been dead since we now have diffecent standards?

I seen UncleT have moved into his own system, so a standard can not been created.

I really hope you write a wrapper as well to sync to the main SDK listed in the first post.

Ny now I wont comment any longer before I hear others what now.

[unclet]

Seems pretty easy to me if I was a plugin writer. 

Create the Juke_PluginCommand() routine (see below).  When the routine is called, then determine which command name is provided, parse the value string appropriately (only if required) and then perform your plugin function.

int Juke_PluginCommand(String cmdName, String cmdValue)
{
   switch(cmdName)
   {
      case "JUKE_APPLICATION_OPENED":
         //execute plugin code
      break;

      case "JUKE_APPLICATION_CLOSED":
         //execute plugin code
      break;

      case "JUKE_PLUGIN_CONFIGURE":
         //execute plugin code
      break;

      case "JUKE_SONG_STARTED":
         //parse 6 values from cmdValue string

         //execute plugin code
      break;

      case "JUKE_SONG_FINISHED":
         //execute plugin code
      break;

      case "JUKE_SONG_RESTARTED":
         //execute plugin code
      break;

      case "JUKE_SONG_SKIPPED":
         //execute plugin code
      break;

      case "JUKE_SONG_PAUSED":
         //execute plugin code
      break;

      case "JUKE_SONG_RESUMED":
         //execute plugin code
      break;

      case "JUKE_SONG_FAST_FWD_STARTED":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_SONG_FAST_FWD_FINISHED":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_SONG_FAST_REV_STARTED":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_SONG_FAST_REV_FINISHED":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_SONG_PLAY_POSITION":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_QUEUE_USER_ADD_SONG":
         //parse 7 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_QUEUE_SYSTEM_ADD_SONG":
         //parse 7 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_QUEUE_DELETE_SONG":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;

      case "JUKE_QUEUE_MOVE_SONG":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_QUEUE_CLEARED":
      break;

      case "JUKE_VOLUME_CHANGE":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_VOLUME_MUTE_STATUS":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;

      case "JUKE_VOLUME_RANGE":
         //parse 2 values from cmdValue string
         //execute plugin code
      break;

      case "JUKE_ENTER_ALBUM_NUM_DIGIT":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;

      case "JUKE_ENTER_TRACK_NUM_DIGIT":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;

      case "JUKE_ATTRACT_MODE":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;

      case "JUKE_PARTY_LOCK":
         //parse 1 value from cmdValue string
         //execute plugin code
      break;
   }

   return 1;
}

Why do you think these commands will be obsolete and that the plugin author will be constantly trying to keep up with newer versions of these commands? 

I understand some new commands might be created/added and even some existing commands might be updated to have more "command value" text associated with them in the future,  but that should not cause that many problems.

In fact, this is what I am going to do.  All my "command names" are going to have a "version" number associated with them (see my next post).

[unclet]

There is a possibility a "command name" might be updated to include additional "command value" text with it in the future an that plugins which have been released might not have been updated to reflect this change.   As a result, a version number could be added to each command string.   Once a particular command name version has been implemented in the software then it should never be removed or changed.  If the command is updated in the future to add additional data then a new command name (with increased version) would be created and implemented in the code.  This way, both versions of the command will constantly be supported by the software.   

For example
Lets say the current JUKE_SONG_START command did not have "totalDuration" value but it was added in the future.  This would result in 2 versions of the command:

JUKE_SONG_STARTED_1.0                      name>artist>album>albumNum>trackNum>genre>
JUKE_SONG_STARTED_1.1                      name>artist>album>albumNum>trackNum>genre>totalDuration>

Note1: I do not see this happening a lot, so maintaining multiple versions of the same command in the software should not a real problem.   Just means two calls are made to the "Juke_PluginCommand()" routine in a row instead of only one.

Note2: I really do not need to add versions to each defined command as long as the plugin only parses the correct number of text values from the "command value" string by only parsing each value up to the next trailing ">" separator character only.   Basically, any additional values which have been added to the end of the command value text string in the future should simply be ignored and cause no real problem.

Now, should I consider all plugins to parse corrcetly, or should I actually use the version numbering commands shown below?  Hmmm .....

int Juke_PluginCommand(String cmdName, String cmdValue)


cmdName                                            cmdValue
-------------------------------------------------------------------------------
JUKE_APPLICATION_OPENED_1.0             n/a
JUKE_APPLICATION_CLOSED_1.0             n/a

JUKE_PLUGIN_CONFIGURE_1.0                n/a

JUKE_SONG_STARTED_1.0                       name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_SONG_FINISHED_1.0                      n/a
JUKE_SONG_RESTARTED_1.0                   n/a
JUKE_SONG_SKIPPED_1.0                        n/a
JUKE_SONG_PAUSED_1.0                        n/a
JUKE_SONG_RESUMED_1.0                      n/a
JUKE_SONG_FASTFWD_STARTED_1.0       currentPositionSecs>totalDuration>
JUKE_SONG_FASTFWD_FINISHED_1.0      currentPositionSecs>totalDuration>
JUKE_SONG_FASTREV_STARTED_1.0        currentPositionSecs>totalDuration>
JUKE_SONG_FASTREV_FINISHED_1.0       currentPositionSecs>totalDuration>
JUKE_SONG_PLAY_POSITION_1.0            currentPositionSecs>totalDuration>

JUKE_QUEUE_USER_ADD_SONG_1.0        queuePos>name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_QUEUE_SYSTEM_ADD_SONG_1.0     queuePos>name>artist>album>albumNum>trackNum>genre>totalDuration>
JUKE_QUEUE_DELETE_SONG_1.0              queuePos>
JUKE_QUEUE_MOVE_SONG_1.0                oldQueuePos>newQueuePos>
JUKE_QUEUE_CLEARED_1.0                     n/a

JUKE_VOLUME_CHANGE_1.0                     up/down/set>volumeLevel>
JUKE_VOLUME_MUTE_STATUS_1.0            on/off>
JUKE_VOLUME_RANGE_1.0                       minVolumeLevel>maxVolumeLevel>

JUKE_ENTER_ALBUM_NUM_DIGIT_1.0        digit(0-9)>
JUKE_ENTER_TRACK_NUM_DIGIT_1.0        digit(0-9)>

JUKE_ATTRACT_MODE_1.0                      onActive/onNotActive/off>
JUKE_PARTY_LOCK_1.0                           on/off>

[Space Fractal]

The only problem can a plugin writers want to known which commands that would been used in ALL software?

Example I have not a ATTRACT mode but I have a SCREENSAVER, but would the plugin writer ever known about it (example if they are fan of a other application)?

Otherwice, I have just contacted LoadMan and HeadKaze what we do now, since none of us can agree a standard, It just because they before have wrote plugins (MALA example) and have lots of knownable about it.

____

seen your edited text:
Let see what LoadMan mean about it, and see what he thinks as a commen plugin writer (I also wanted to write a few). I through I finalized SDK from the very first post (as I changed over the time)....

[unclet]

The only problem can a plugin writers want to known which commands that would been used in ALL software?

On my "plugin" page, the user can click a button to display all plugin commands my software supports along with an explanation of each.   Now, as I mentioned before, in a more centrally located place (ie: Jukebox Wiki, PlugMyJuke website, etc..) ALL of the plugin commands should be listed and for each command, a description should be provided along with which jukebox software supports it.

Example I have not a ATTRACT mode but I have a SCREENSAVER, but would the plugin writer ever known about it (example if they are fan of a other application)?

The word "attract" is used to simply indicate that the jukebox has some sort of way to try to "attract" a user to the jukebox machine when no songs are playing (ie: page flipping automatically, having sounds heard, lights flash, etc...)   It does not mean your software actually has an option called "AttractMode" in it.    (Same thing relates to "PartyMode" .... does not mean a jukebox has an option called "PartyMode" in it ..... it just means the jukebox software offers a way of locking party guests out of your configuration screens or from doing other stuff you do not want beer drinking hackers to try to do   )

Based on my format, your software would still use the "JUKE_ATTRACT_MODE" command.  The documented description of the "JUKE_ATTRACT_MODE" command would simply inform the plugin author that this command relates to "MultiJuke's screensaver function", "UncleT's Jukebox page flipping attract mode function",  etc...., etc....

Basically, the plugin author will understand what each command does based on their reading of the each command description which should definitely occur before they start coding their plugin.

[Space Fractal]

BTW I think I ask saint to lock this thread I have created to the hell.

I dedicated to pull off. No more points to debate this anymore .

Thanks very much for the debate.

We start from the beginnig with a completly new format.

[loadman]

BTW I think I ask saint to lock this thread I have created to the hell.
I dedicated to pull off. No more points to debate this anymore .
Thanks very much for the debate.
We start from the beginnig with a completly new format.

You don't have to agree, That's fine. 

But don't get upset about it. 

[headkaze]

Based on my format, your software would still use the "JUKE_ATTRACT_MODE" command.  The documented description of the "JUKE_ATTRACT_MODE" command would simply inform the plugin author that this command relates to "MultiJuke's screensaver function", "UncleT's Jukebox page flipping attract mode function",  etc...., etc....

Basically, the plugin author will understand what each command does based on their reading of the each command description which should definitely occur before they start coding their plugin.

This is what I was saying all along too (and was starting to repeat myself over and over). It's simple and it works in any scenario. Any Jukebox programmer can add or remove the commands they want, and they can share common commands. If people can't agree on something as simple as this it's best to create your own plugin systems.

It's a shame but hey these things happen  

[loadman]

Based on my format, your software would still use the "JUKE_ATTRACT_MODE" command.  The documented description of the "JUKE_ATTRACT_MODE" command would simply inform the plugin author that this command relates to "MultiJuke's screensaver function", "UncleT's Jukebox page flipping attract mode function",  etc...., etc....

Basically, the plugin author will understand what each command does based on their reading of the each command description which should definitely occur before they start coding their plugin.

This is what I was saying all along too (and was starting to repeat myself over and over). It's simple and it works in any scenario. Any Jukebox programmer can add or remove the commands they want, and they can share common commands. If people can't agree on something as simple as this it's best to create your own plugin systems.

It's a shame but hey these things happen  

I gotta go to work now :-(     

[Space Fractal]

sorry about it, but I still prefer start from beginning with a new thread started by you.

we other can then see we can agree or disagree.

Also sorry to UncleT as well.

I think we scrash both SDK and trying to make a comprimest in a new thread using my and Uncle't ideas.

Let plugin writes think first and let us jukebox writes came after. Use both of ideas by mine and UncleT.

I was just scare about all these new commands that never would been used, if a plug worked best for one contain software.

BTW we could make few functions. One for sending commands and one for sending a command list as well or something like that.

EDIT: Since this came out of controls where many us was upset (sorry again), I created a new thread with no listed command and my vision). I dont want have more posts into this thread.

PLEASE LOCK THIS THREAD

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

[unclet]

In my code, the Shutdown() routine was being called twice by mistake.  I fix it and the crash went away, but I believe you new changes should be done anyway.   Thanks.

[headkaze]

loadman: You are very close. I added a few extra bits and pieces so it's basically identical to the C++ dll now. Here is the latest plugin with both C++ and Delphi plugin examples.

Code: [Select]

library JukePlugin;

uses
  Dialogs,
  SysUtils,
  Classes;

{$R *.res}

var
PLUGIN_NAME : PChar = 'LCD Display';
PLUGIN_AUTHOR : PChar = 'Loadman';
PLUGIN_VERSION : PChar = 'Beta A';
PLUGIN_DESCRIPTION : PChar = 'This is a plugin';

Buffer: array[0..8192] of Char;

function Juke_Initialize(Value: Integer):Integer; stdcall;
begin
  // Showmessage('DLL has recieved Juke_Shutdown message');
  Result := 1
end;

function Juke_Shutdown(Value: Integer):Integer; stdcall;
begin
  // Showmessage('DLL has recieved Juke_Shutdown message');
  Result := 1
end;

function Juke_GetPluginInfo(Value:integer):PChar; stdcall;
begin
  Result := PChar(PLUGIN_NAME + '|' + PLUGIN_AUTHOR + '|' + PLUGIN_VERSION + '|' + PLUGIN_DESCRIPTION);
end;

function Juke_Command(Name:PChar; Value:PChar):PChar; stdcall;
begin
  StrCopy(Buffer, Value);
  Result := Buffer
end;

exports
  Juke_GetPluginInfo,
  Juke_Initialize,
  Juke_Shutdown,
  Juke_Command;

begin
end.

[unclet]

headkaze
That works ....thanks.   

I came back to tell you the good news and noticed you posted yet another version of the JukePlugin .......     I guess I will upgrade again

[headkaze]

headkaze
That works ....thanks.   

I came back to tell you the good news and noticed you posted yet another version of the JukePlugin .......     I guess I will upgrade again

hehe yeah sorry that should be about it for a while I just wanted to add the corrected Delphi example for loadman. Now he's ready to code his plugin

Space Fractal should post a Power Basic plugin example using the new plugin system, then someone should write up some docs and include a list of the common commands and then your just about ready to release the JPS SDK v1.0.

[unclet]

I still think the command name and value formats need to be agreed on.

Hey, I really can not stand the "|" character since it is hard to read next to characters like "I", "L" and "1" so how about we use the ">" instead as a separator character like I previously recommended? 

Unless the "|" character is some kind of standard.....

[headkaze]

I still think the command name and value formats need to be agreed on.

Hey, I really can not stand the "|" character since it is hard to read next to characters like "I", "L" and "1" so how about we use the ">" instead as a separator character like I previously recommended? 

Unless the "|" character is some kind of standard.....

Geez your picky aren't you unclet? 

Pipe is used alot in cases like this (splitting string values). I would keep it like that

loadman: Just so you know in the Plug_Command() function to return parameters back to the Jukebox you would do this..

Code: [Select]

StrCopy(Buffer, "Value1|Value2|Value3|Value4");
Result := Buffer

That will return Value1, Value2, Value3 and Value 4.

Actually to be on the safe side you probably should change the following also

Code: [Select]

function Juke_GetPluginInfo(Value:integer):PChar; stdcall;
begin
  StrCopy(Buffer, PChar(PLUGIN_NAME + '|' + PLUGIN_AUTHOR + '|' + PLUGIN_VERSION + '|' + PLUGIN_DESCRIPTION));
  Result := Buffer
end;
That is just a cleaner way of doing it.

[loadman]

loadman: You are very close. I added a few extra bits and pieces so it's basically identical to the C++ dll now. Here is the latest plugin with both C++ and Delphi plugin examples.

Mate, It seemed to work but I will do it your way as you know better coding practice 

headkaze
That works ....thanks.   

I came back to tell you the good news and noticed you posted yet another version of the JukePlugin .......     I guess I will upgrade again

I just wanted to add the corrected Delphi example for loadman. Now he's ready to code his plugin

 

ALL:

A big thanks to everyone for hanging in there.   

It got a bit tense and frustrating for a while. 

We seem to be past that and very close to JPS SDK v1.0.   

[unclet]

Here is my proposal for the Command name/value strings:

Note1: The commandName string is first (with a description) and the commandValue string format is underneath

Note2: I decided having separate commands for each function is a lot easier since it allows for one big case statement for processing.   Also too much combining tends to seem like we are craming everything together.  Also, also, I can more easily see what exact command I am sending throughout my code.

Note3: Each commandValue string has a "|" separator character as well as a trailing "|".  The trailing "|" character is required so the plugin can parse the correct number of text strings up to this trailing "|" character only.  As a result, if we expand a commandValue string for a particular command in the future then this will not affect the current released plugins at all since they will simply ignore the extra text we added to the commandValue string.

Note4: I do not believe the plugin needs to know what commands are supported by specific jukebox software.  Based on the generic commands listed, I believe the plugin can decide what they want to implement or not. 



CONFIGURE COMMAND
---------------------------------------------------------------------------
JUKE_PLUGIN_CONFIGURE
null


APPLICATION COMMANDS
---------------------------------------------------------------------------
JUKE_APP_OPENED
null

JUKE_APP_CLOSED
null



CURRENT PLAYING SONG COMMANDS
---------------------------------------------------------------------------
JUKE_SONG_START (new song has started playing)
name|artist|album|albumNum|trackNum|genre|totalDuration|

JUKE_SONG_FINISH (current song has finished)
null

JUKE_SONG_RESTART (current song has been restarted)
null

JUKE_SONG_SKIP (current song has been skipped)
null

JUKE_SONG_PAUSE (current song has been paused)
null

JUKE_SONG_RESUME (current song has been resumed from pause state)
null

JUKE_SONG_FASTFWD_START (current song has started being fast forwarded)
null

JUKE_SONG_FASTFWD_FINISH (current song has finished being fast forwarded)
null

JUKE_SONG_FASTREV_START (current song has started being fast reversed)
null

JUKE_SONG_FASTREV_FINISH (current song has finished being fast reversed)
null

JUKE_SONG_PLAY_POSITION (the number of seconds into the current song)
curPosSecs|totalDuration|



QUEUE COMMANDS
---------------------------------------------------------------------------
JUKE_QUEUE_ADD_SONG (song added to queue by user or system)
system|queuePosNum|name|artist|album|albumNum|trackNum|genre|totalDuration|

JUKE_QUEUE_REMOVE_SONG (song removed from queue by user or system)
system|queuePosNum|

JUKE_QUEUE_MOVE_SONG (song has been moved in the queue by user or system)
system|oldQueuePosNum|newQueuePosNum|

JUKE_QUEUE_CLEARED (the song queue has been cleared by user or system)
system|

JUKE_QUEUE_CHANGED (the song "queue.txt" file has changed)
null




VOLUME COMMANDS
---------------------------------------------------------------------------
JUKE_VOLUME_CHANGE (volume has been changed by user or system)
system|up/down|curVolumeLevel|minVolumeLevel|maxVolumeLevel|

JUKE_VOLUME_MUTE (volume mute has been turned on/off)
on/off|



ENTER DIGIT COMMANDS
---------------------------------------------------------------------------
JUKE_ENTER_ALBUM_NUM_DIGIT (album number digit has been entered)
digit(0-9)|

JUKE_ENTER_TRACK_NUM_DIGIT (track number digit has been entered)
digit(0-9)|



FEATURE COMMANDS
---------------------------------------------------------------------------
JUKE_FEATURE_ATTRACT_MODE (attract mode feature is enabled/disabled)
active/notActive|

JUKE_FEATURE_PARTY_LOCK (party lock feature is enabled/disabled)
enabled/disabled|



NAVIGATION COMMANDS
---------------------------------------------------------------------------
JUKE_NAVIGATE_QUEUE (navigating song queue is occurring)
up/down/left/right|

JUKE_NAVIGATE_ALBUM_TRACK_LIST (navigating album track list is occurring)
up/down/left/right|

JUKE_NAVIGATE_ALBUM_COVER_PAGE (going to next album cover page)
up/down/left/right|

JUKE_NAVIGATE_ALBUM_COVER_SELECT (selecting an album cover on current page)
null

JUKE_NAVIGATE_PLAYLIST (navigating playlists are occurring)
up/down/left/right|

JUKE_NAVIGATE_PLAYLIST_TRACK_LIST (navigating playlist tracks are occurring)
up/down/left/right|

[Space Fractal]

Hehe, I use Pure Basic to creating dlls, not Power Basic. Pure Basic is a powerfull api.

We could define a basic standard command sets we know all software have, but still been available to use commandsend argument to send extra unique commands trouch Juke_Config(), like these action buttons?

I think I doesent want to explain what these action buttons does, if I have full controls over that used using comandSend(), but I could use the above to doing that.

I create a full plug-in example using these commands later, today or tomorrow (using the sound example).

I looking about Queue.txt later, but by now get the other things work first !!


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

JUKE_SONG_START does not need any argument about songinfo.. allready got it using queue.txt or such that?

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.


 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?

ENTER DIGIT COMMANDS:
 only used in MultiJuke in Jukebox GUI. I think it should been removed and use them as a extra unique commands?


FEATURE:
 JUKE_FEATURE_PARTY_LOCK is not standard of all software. again, can use as sending to commandlist$ as extra commands to the plugin?


JUKE_QUEUE_CHANGED can also been used as a command as seen..

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?

[unclet]

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

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.

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

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

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.

JUKE_SONG_START does not need any argument about songinfo.. allready got it using queue.txt or such that?

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?

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.

If you are going to use the "queue.txt" file all the time then I agree, but I can not do this (see above).

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?

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

ENTER DIGIT COMMANDS:
 only used in MultiJuke in Jukebox GUI. I think it should been removed and use them as a extra unique commands?

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.

FEATURE:
 JUKE_FEATURE_PARTY_LOCK is not standard of all software. again, can use as sending to commandlist$ as extra commands to the plugin?

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.

JUKE_QUEUE_CHANGED can also been used as a command as seen..

Not sure what this means....

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?

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

Mate, It seemed to work but I will do it your way as you know better coding practice 

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.

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.

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.

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.

Okay it would work like this, set up a Timer with an interval of say 200 milliseconds.

In the Juke software...

Code: [Select]

Timer_Elapsed()
{
   Plugin_Command("JUKE_TIMER", null);
}
In the plugin

Code: [Select]

string Juke_Command(string Name, string Value)
{
    switch(Name)
   {
      case "JUKE_TIMER":
         if(bSkipCurrentSong == true)
         {
            bSkipCurrentSong = false;
            return "JUKE_SKIP_SONG";
         }
   }
}
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]

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

I knew that 

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.

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?

[headkaze]

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?

It's nothing to do with the size of the string the problem is were returning a PChar (char pointer) to a local variable. That local variable is just that, local to the function and once the Jukebox software returns from the function call you can't be guaranteed the memory where that PChar was pointing to will still be available. Having that global buffer and copying strings into it then returning a PChar to the buffer is no problem because we know it will be around for the life of the plugin.

[Space Fractal]

only standard define set should been defined, that cover all software.

otherwise we have many unused commands, that might only to been used in one single software. That is not a global standard. A  singles based Jukebox software have other set of commands to control response (LETTER and NUMBERS). Should we cover them too?

The main problem is NOT the queue and playing based commands, but its ONLY with CONTROLS based commands, that allways is defficent by various software.

CONTROLS is the main reason for various software out here, so of course they are all diffecent. So we can't cover them all here.

I can also accept SCREENSAVER example can named something other and such that thing. they are not CONTROLS.


So I think these 3 is needed for CONTROL based plugins (to feed a sample plugin) before config:

JUKE_CONTROL_CREATE|ACTION_BUTTON_1


to use them:

JUKE_CONTROL_SEND|ACTION_BUTTON_1|ON) <- can been ON or OFF (LedWiz).

and

JUKE_CONTROL_GET <- If a user pressed a key on a remote control.


And then it would cover all controls used (also ONLY controls based commands, think as user with a remote control) and I would been fine.


The sdk is changed to only use these 4 functions, headkaze gave. Later I list the defined commands (that is not controls based). I out now, and update the list when I went home.

[unclet]

only standard define set should been defined, that cover all software.

I do not agree.   We should be able to define a "generic" standard for something even if only one jukebox software requires it.   Think about it..... standards are usually created before anyone uses the SDK at all.  Lets take the Visual Basic SDK ..... when they were creating the SDK, then defined many routines before anyone used them at all.   Perhaps no one would use the routines once released as well, but at least they defined a generic set of routines in the SDK.   

I am not saying we should define a command which we know no one is currently using .... that would be a waste of time, but if only one jukebox software requires something then yes, I believe we should define a standard for it.

otherwise we have many unused commands, that might only to been used in one single software. That is not a global standard.

That is true, many unused commands might exist but the software will only send those commands which it supports so it should not matter how many extra commands are defined in the standard at all.   

Also, I do think a "global standard" can exist without "all" software using "all" commands.  It makes no sense to me that you think all software needs to use all commands before you consider it a global standard.   Again, take the Visual Basic SDK example I gave above ..... this "global standard" exists and not all Visual Basic software projects use "all" the commands defined it there ... right?

A  singles based Jukebox software have other set of commands to control response (LETTER and NUMBERS). Should we cover them too?

If one of our jukebox software application uses this then yes, I think we should spend time defining a generic standard for it.  This way whenever a new jukebox developer comes along and wants to support plugins they can use our standards which we defined now.   

Again, if we worked for a company which was in charge of defining a complete standard for a jukebox SDK then we would be trying to standardized everything a jukebox software could "possibly" do ...... but since we are just a few people trying to introduce plugins to our software right now, lets just define standards for the commands which are used by at least one of our software applications only.   Defining stuff which is not used by any of our software at this point would be a waste of time right now.

The main problem is NOT the queue and playing based commands, but its ONLY with CONTROLS based commands, that allways is defficent by various software.

CONTROLS is the main reason for various software out here, so of course they are all diffecent. So we can't cover them all here.

Well we should be able to add more cmdName and cmdValue strings to cover what you need but you are not really ever telling us exactly what your control button do so we can not help you out here.   I keep asking what your ACTION button stuff really mean but you have not let me know that yet.so I really can not help you yet.

Now, possibly we can define some cmdName strings like the following for your softeare to use:

JUKE_ACTION_BUTTON_1
JUKE_ACTION_BUTTON_2
JUKE_ACTION_BUTTON_3
JUKE_ACTION_BUTTON_4

I can also accept SCREENSAVER example can named something other and such that thing. they are not CONTROLS.

Not real sure you need to group certain commands as "controls" or not.   Just define the appropriate set of cmdName/cmdValue strings for what you need and then send the command to the plugin when the event occurs.

So I think these 3 is needed for CONTROL based plugins (to feed a sample plugin) before config:

JUKE_CONTROL_CREATE|ACTION_BUTTON_1


to use them:

JUKE_CONTROL_SEND|ACTION_BUTTON_1|ON) <- can been ON or OFF (LedWiz).

and

JUKE_CONTROL_GET <- If a user pressed a key on a remote control.


And then it would cover all controls used (also ONLY controls based commands, think as user with a remote control) and I would been fine.

I have no idea what you are trying to do here ... sorry.   

[Space Fractal]

See the changed SDK.

I have now changed the SDK to nearly have your system now, I think is very good.

I have just changed few commands, removed few uneeded arguemtns, and added some other commands as well.

queue.txt is also removed and replaced with some PLAYLIST commands. Hope you like it. There is also some changes about the song info here too.


The major problem about controls using your and mine vision is replaced with KEY EVENT, which i explain what it does:

The whole main problem about various commands we talk very much about is been changed to just use KEY_EVENT, which I guess is a good workaround and a comprimes.

I can see on your UncleT Jukebox homepage, there is overer 70 key mappings provided in your software. It them that have been the the whole point in my Plugin Vision, and it only them, I might have interesed using these KEY_EVENT to been used for some plugins, like sound, ledwiz and others uses.

MultiJuke is a button based jukebox software, where KEY_EVENT would been very strong for the PlugIn. Of course I would let a plugin to use all KEY_EVENTS I have in my software (all buttons) to been controlled. Here KEY_EVENT is a major use.

This is includning Action buttons I have in my software:  They are no other than a user KEY_EVENT, also a user keypress to invoke some command in my Jukebox.....

So I think KEY_EVENT is the right word to use?

Because of that, I removed all navigations commands you have, I removed from the SDK. But use the power of KEY_EVENT commands for these navigation commands (like I would due in MultiJuke).

[unclet]

headkaze .... please answer this for me

There is no need for a trailing "|" at the end of the paramter list

Here is my concern .... let me know if this is a real concern or not .... 

Lets say (just for an example) the current JUKE_SONG_START command is defined as follows (without a trailing "|" character):

JUKE_SONG_STARTED      name|artist|album|albumNum|trackNum|genre

The currently released plugin would parse the text cmdValue string like this:

text1=name
text2=artist
text3=album
text4=albumNum
text5=trackNum
text6=genre

Now, some time in the future the "JUKE_SONG_START" command is updated to include the "totalDuration" value:

JUKE_SONG_STARTED        name|artist|album|albumNum|trackNum|genre|totalDuration

The currently released plugin (which does not support this new change) might parse the following way:
 

text1=name
text2=artist
text3=album
text4=albumNum
text5=trackNum
text6=genre|totalDuration  <-- problem

It would be bad if the plugin determines the 6th text to be "genre|totalDuration" together.

I believe if we have a trailing "|" character at the end of every cmdValue text string, then
the plugin could simply parse the first 6 text strings (text1->text6) correctly everytime by
only parsing up to each successive trailing "|" character only.  This means the plugin would only be parsing out the first 6 text string values only, by looking for 6 "|" separator characters only.  If extra text exists beyond the 6th "|" separator character then this text will simply be ignored by the currently released plugin.

This makes updating the cmdValue text for a particular command much easier and would not affect existing plugins which have been released. 

What do you think? 

[Space Fractal]

In Pure Basic I just detect a null pointer as a | too, or you can add a | sign before parsing the string?

I have accepted UncleT version, but I changed few commands to, and added KEY_EVENT commands (the major problem between I and UncleT), so please look in the SDK, before writing a plugin and I wait for the UncleT comment on about these change.

[unclet]

Juke_Command("JUKE_KEY_EVENT_CREATE","COMMAND_NAME")
This command is required before JUKE_PLUGIN_CONFIGURE is invoked. This make sure a plugin can "listen" to a KEY_EVENT command from the Jukebox Software and example effect a sound effect to a KEY_EVENT.

A Jukebox Software can create any KEY_EVENT commands that can been controlled by the user (also like a keybinding).

Only KEY_EVENT commands (keybindning) is needed for the plugin to known, so they can used for various things like LedWiz, Sound, Remote controlling and other things.

Nice solution !      

Please rename "COMMAND_NAME" to be "KEY_EVENT_NAME" in the documentation though

So just so I understand ..... before the plugin gets configured you can send as many of these "JUKE_KEY_EVENT_CREATE" commands as you want to inform the plugin about all the different types of key events your software supports.  Then the plugin can allow mappings to these events to occur during it's configuration.  Then when the event occurs in your jukebox software, then your software can send the plugin this specific key event by using the normal "Juke_Command()" routine?

For example
Your software allows coin insert to occur, so you would inform the plugin of this event with:

Juke_Command("JUKE_KEY_EVENT_CREATE","JUKE_KEY_EVENT_COIN_INSERT")

then when the user inserts a coin in your machine then you would send the plugin this:

Juke_Command("JUKE_KEY_EVENT_COIN_INSERT", "")

If this is true, then I guess none of the key events will have cmdValue strings associated with them ...... correct?  Basically all key event commands sent to the plugin will have the second parameter be ""

Juke_Command("JUKE_APP_HOST","SOFTWARE NAME", "UNICODE")
The Jukebox software name.

Ths "Juke_Commands()" routine is defined to have two interface parameters and you are using three parameters instead.  I suggest defining the following two commands to solve this problem:

JUKE_APP_HOST
JUKE_APP_HOST_UNICODE

PLAYLIST COMMANDS:

either resumbt all songs again at once again using or just change the number of current song if the software is PLAYLIST based, using the JUKE_PLAYLIST_CURRENTSONG command.

Juke_Command("JUKE_PLAYLIST","place|auto|title|artist|album|trackNum|genre|totalDuration")

When a user have manipulated the playlist, or a new song is started, the jukebox software would resumbit all songs again. If A new songs is added to the playlist without manipulation, the software might just add that song using JUKE_PLAYLIST with the last PLACE number.

Info about arguments:

• Auto means if it was added by the "USER" or by "SYSTEM".
• Albumnumber or such should been part of the album name, like "01 Album".
• Some songinfo "tags" might been empty if not used.
• Some songs might not have a TotalDuration if it is unknown.

For Jukebox Authors: If the song contain a | char (I never seen that), remove that before send the string.

Juke_Command("JUKE_PLAYLIST_CLEAR", "")

Clear the PLAYLIST or QUEUE.

Juke_Command("JUKE_PLAYLIST_CURRENTSONG", NUMBER)
Which song number is curretly in playing from the PLAYLIST?

Queue based jukebox software might not use this command, due to resumbitting. So not all software might use this command, so the default value to this command is 1.

FILE=Juke_Command("JUKE_PLAYLIST_GET", "")

Get a playlist file from a plugin. This command can been used when the queue is empty or last song is played finish from the PlayList.

I think you are confused what my software considers to be a "playlist".   

My software has the ability to let users define their own "playlists" (ex: "Dad's Favorites", "Holiday Music", "Party Songs", etc....)   Once defining a playlist name the user can then populate the playlist with album song tracks.  Then when the user wants to hear music from a certain playlist, they can select the playlist they want, then select a song from the playlist to play (or simply select all songs in the playlist to play).  Once a song is selected, then the song goes into the song queue until it is ready to be played for real.

My playlist files have nothing to do with a song queue at all.  They are simply a group of songs in a list which can then be selected to be played.

I think you are trying to use the term "playlist" to implement queues along with queue manipulation.  If this is true, then we should put back the "JUKE_QUEUE_xxxx" commands.  I changed them to use your "system/user" indicator bit (see below) (I also updated my post with these as well).

JUKE_QUEUE_ADD_SONG (song added to queue by user or system)
system|queuePosNum|name|artist|album|albumNum|trackNum|genre|totalDuration|

JUKE_QUEUE_REMOVE_SONG (song removed from queue by user or system)
system|queuePosNum|

JUKE_QUEUE_MOVE_SONG (song has been moved in the queue by user or system)
system|oldQueuePosNum|newQueuePosNum|

JUKE_QUEUE_CLEARED (the song queue has been cleared by user or system)
system|

JUKE_QUEUE_CHANGED (the song "queue.txt" file has changed)
null


I would use the "queue.txt" file when "multiple" changes have occurred in the song queue at once and will inform the plugin the "queue.txt" file has been changed by sending the "JUKE_QUEUE_CHANGED" command.   

When individual song queue entries are added, removed, moved "one at a time" then i will just use the "JUKE_QUEUE_ADD_SONG", "JUKE_QUEUE_REMOVE_SONG" and "JUKE_QUEUE_MOVE_SONG" commands only.

Juke_Command("JUKE_SONG_PAUSE","")
New song is just started.

Juke_Command("JUKE_SONG_START","")
Current song has been paused.

The description of these are assigned to the wrong command.   Also, please list these commands next to "JUKE_SONG_FINISHED" since I originally could not find them and thought you deleting them .

Also, I would like to put back the following cmdValue string for the "JUKE_SONG_START" commands:

name|artist|album|albumNum|trackNum|genre|totalDuration

I realize you have a "JUKE_SELECTED_MARKED" command defined which has similiar cmdValue string text, but this command seems like it is only going to be sent when the user highlights a song from a list (but does not choose to play it).   Basically, it tells the plugin which song is currently being "looked at" by the user only.   When a song is selected to be played, then I would assume you would be expecting the jukebox software to send the "JUKE_SELECTED_MARKED" command followed by a "JUKE_SONG_STARTED" command.   This is how you would expect the song information for the current song (title,artist, album, etc ...) to be supplied to the plugin.

However, what happens when a song is selected and it gets put on the queue.  When that song finally plays (ie: removed from the queue) then how do you tell the plugin what song has started now?   There would be no "JUKE_SELECTED_MARKED" command sent in this case since the user did not mark the song then select it to be played, but rather the song came off of the queue automatically.

Juke_Command("JUKE_SONG_FASTFWD_START","")
Current song has started being fast forwarded.
(curPosSecs and totalDuration not needed due to JUKE_SONG_PLAY_POSITION and JUKE_PLAYLIST)

Juke_Command("JUKE_SONG_FASTFWD_FINISH","")
Current song has finished being fast forwarded
(curPosSecs and totalDuration not needed due to JUKE_SONG_PLAY_POSITION and JUKE_PLAYLIST)

Juke_Command("JUKE_SONG_FASTREV_START","")
Current song has started being fast reversed
(curPosSecs and totalDuration not needed due to JUKE_SONG_PLAY_POSITION and JUKE_PLAYLIST)

Juke_Command("JUKE_SONG_FASTREV_FINISH","")
Current song has finished being fast reversed
(curPosSecs and totalDuration not needed due to JUKE_SONG_PLAY_POSITION and JUKE_PLAYLIST)

I agree the "curPosSecs" and "totalDuration" values are not needed in these commands.  I will simply inform the plugin that FastForward/Reverse has started and then periodically send a "JUKE_SONG_PLAY_POSITION" command to indicate the current location.  I do not want to send the "JUKE_SONG_PLAY_POSITION" command for every "second" in time which is being fast forwarded/reversed ... that would be way too many commands being sent to quickly.  I will send the "JUKE_SONG_PLAY_POSITION" command at perhaps every 10 second interval while the song is being fast forwarded/reversed instead.  When the user is finished then I will simply inform the plugin that FastForward/Reverse has finished and then send a "JUKE_SONG_PLAY_POSITION" command again to indicate the current position.

** The only part of your statement I do not understand is what is highlighted in RED below:

"(curPosSecs and totalDuration not needed due to JUKE_SONG_PLAY_POSITION and JUKE_PLAYLIST)"

Juke_Command("JUKE_VOLUME_SET", "curVolumeLevel|minVolumeLevel|maxVolumeLevel|system")
A new value volume have been set.

If system is set the volume, the last argument would set to one.

Will you please put the "system" indicator as the first text string value please?

"system|curVolumeLevel|minVolumeLevel|maxVolumeLevel")

I updated my queue commands to be this way to so now they will all be formatted the same way.

Juke_Command("JUKE_SELECTED_ALBUM_NUMBER", "NUMBER")
A Album number digit has been entered

Juke_Command("JUKE_SELECTED_TRACK_NUMBER", "NUMBER")
A Track number digit has been entered

My album numbers can contain up to 5 digits and my song track numbers can contain up to 3 digits.    Every time one "digit" is entered for an album number or track number, then one of these commands will be sent to indicate which "digit" was entered.   

As a result, please rename these commands to be:

JUKE_ENTERED_ALBUM_DIGIT
JUKE_ENTERED_TRACK_DIGIT

Juke_Command("JUKE_SELECTED_SINGLES_NUMBER", "VALUE")
A Single have been selected. It can been both letters and number, like C2.

I would assume the term "selected singles" refers to the user selecting a song track to play (by first entering a letter followed by a number), so I would suggest introducing one new command:

JUKE_ENTERED_TRACK_LETTER

No need to introduce the "JUKE_SELECTED_SINGLES_NUMBER" command at all.

Juke_Command("JUKE_SELECTED_MARKED", "title|artist|album|trackNum|genre|totalDuration")
The user marked song, that is now currectly marked on the screen. TotalDuration might not been used here by a jukebox software.

You can use this command to indicate which song has been currently highlighted by the user, but I do not think this means you can remove the "name|artist|album|albumNum|trackNum|genre|totalDuration" information from the "JUKE_SONG_START" command

Juke_Command("JUKE_KEY_EVENT_SEND", Status)
Status can been value 1 for on and value 0 for off.

No idea what this does .... please explain

EVENT=Juke_Command("JUKE_KEY_EVENT_GET")
A KEY_EVENT is retrieved by the plugin and invoke that command (like a remote controller).

No idea what this does .... please explain.  There are no parameters defined for this command so what does the plugin do with it?

Juke_Command("JUKE_FEATURE_ATTRACT_MODE", TRUE|FALSE)
Attract mode feature is enabled (TRUE) or disabled (FALSE)

Attract modes are not always ON by default.  My software allows the user to enable this or disable this function.

As a result, there should be three values for this command:

onActive (attract mode has been activated by the user and is currently running)
onNotActive (attract mode has been activated by the user and is NOT currently running)
off  (attract mode has NOT been activated by the user)

[headkaze]

headkaze

There is no need for a trailing "|" at the end of the paramter list

Here is my concern .... let me know if this is a real concern or not .... 

Lets say (just for an example) the current JUKE_SONG_START command is defined as follows (without a trailing "|" character):

JUKE_SONG_STARTED      name|artist|album|albumNum|trackNum|genre

The currently released plugin would parse the text cmdValue string like this:

text1=name
text2=artist
text3=album
text4=albumNum
text5=trackNum
text6=genre

Now, some time in the future the "JUKE_SONG_START" command is updated to include the "totalDuration" value:

JUKE_SONG_STARTED        name|artist|album|albumNum|trackNum|genre|totalDuration

The currently released plugin (which does not support this new change) might parse the following way:
 

text1=name
text2=artist
text3=album
text4=albumNum
text5=trackNum
text6=genre|totalDuration  <-- problem

It would be bad if the plugin determines the 6th text to be "genre|totalDuration" together.

I believe if we have a trailing "|" character at the end of every cmdValue text string, then
the plugin could simply parse the first 6 text strings (text1->text6) correctly everytime by
only parsing up to each successive trailing "|" character only.  This means the plugin would only be parsing out the first 6 text string values only, by looking for 6 "|" separator characters only.  If extra text exists beyond the 6th "|" separator character then this text will simply be ignored by the currently released plugin.

This makes updating the cmdValue text for a particular command much easier I would say.

Your logic really blows me away on this one.

This would never happen...

text1=name
text2=artist
text3=album
text4=albumNum
text5=trackNum
text6=genre|totalDuration  <-- problem

Split will split up all the elements in a string using a delimiter (in this case the pipe or "|" symbol). So text6 will always just be "genre" and that is no matter how many more parameters you add.

Say you have

name|artist|album|albumNum|trackNum|genre

And then later decided to add another parameter

name|artist|album|albumNum|trackNum|genre|totalDuration

It's all about the number of elements returned by Split!

If we Split the first string the UBound() will be one less than the UBound() of the second string.

Therefore if we have the number of elements returned we know if the array contains totalDuration or not right?

So why do you need an extra "|" at the end? All this does is mean the number of elements counted by UBound() will be one more. It doesn't make any sense to me why you think a trailing "|" is needed.

Now let me demonstrate by using code

Code: [Select]

Dim Args() As String

Args = Split("name|artist|album|albumNum|trackNum|genre", "|")
   
If (UBound(Args) + 1 = 6) Then
MsgBox "First string doesn't contain totalDuration"
End If

Args = Split("name|artist|album|albumNum|trackNum|genre|totalDuration", "|")

If (UBound(Args) + 1 = 7) Then
MsgBox "Second string DOES contain totalDuration"
End If
Make sense now?

[unclet]

Make sense now?

   Yes, I fully understand that if a plugin was written in VB and uses "Split()" then it would work fine all the time ...... however, since we can not guarantee what the plugin author is coded in (or perhaps the knowledge base of the plugin author) then I was more wondering whether a trailing "|" character would be better for those cases.

For example, what if a plugin author uses a software language which does not have a "Split()" command and has to parse the cmdValue text string one character at a time from left to right.    They might only be expecting 6 text strings to exist so when they encounter the 5th "|" separator character then they might consider the "rest of the string" to be the 6th (final) text string which would be bad since extra text is stuck at the end now.

Just to let you know, this is not really a big deal to me at all, but I was just trying to save some grief if commands are ever expanded.   Might never happen so no big deal .... but thought I would throw it out there to discuss.  I do not know what the plugin authors are going to code with so not sure whether they have "Split()" commands to use to avoid this problem.  If they all can parse using a Split() command then there is no problem at all I agree.

At least hopefully you can see my point .....

[headkaze]

Make sense now?

   Yes, I fully understand that if a plugin was written in VB and uses "Split()" then it would work fine all the time ...... however, since we can not guarantee what the plugin author is coded in (or perhaps the knowledge base of the plugin author) then I was more wondering whether a trailing "|" character would be better for those cases.

For example, what if a plugin author uses a software language which does not have a "Split()" command and has to parse the cmdValue text string one character at a time from left to right.    They might only be expecting 6 text strings to exist so when they encounter the 5th "|" separator character then they might consider the "rest of the string" to be the 6th (final) text string which would be bad since extra text is stuck at the end now.

Just to let you know, this is not really a big deal to me at all, but I was just trying to save some grief if commands are ever expanded.   Might never happen so no big deal .... but thought I would throw it out there to discuss.  I do not know what the plugin authors are going to code with so not sure whether they have "Split()" commands to use to avoid this problem.  If they all can parse using a Split() command then there is no problem at all I agree.

At least hopefully you can see my point .....

I see your point, but we can't assume the plugin coder is that stupid. AFAIK All high level languages have a Split type string function anyway. Even standard C has strtok() for example.

http://en.wikipedia.org/wiki/String_functions_(programming)#split

[unclet]

Sounds good to me then ...... 

[Space Fractal]

KEY_EVENT:

correct. KEY_EVENT_COIN_INSERT is also just a another event too.

Few commands might been in disabled status, because example ACTION_BUTTON_2 and above is not allways used and can been disabled. Hence I could send it a OFF argument to example a LedWiz device.

Hence I might need to send a Juke_Command("ACTION_BUTTON_3",OFF) and Juke_Command("ACTION_BUTTON_3",ON).

But for all other commands, A empty "" would been sendt.



SELECTED ALBUM:

Juke_Command("JUKE_MARKED_ALBUM", "NUMBER")
Juke_Command("JUKE_MARKED_TRACK", "NUMBER")

I have changed the command into marked album. The value can been anything, both letters and value. The user can configurere the plugin anyway, how it should been used.

When they begin to enter a new digit or letters, just send the command again with the new value. Something like this:

1
12
125

On this way, a plugin better can understand how many digits and or letters the user actuelly have inserted. What about if they deleted a digit again, just send the new value again with a digit fewer, like 12.

So JUKE_ENTERED_ALBUM_DIGIT and JUKE_ENTERED_TRACK_DIGIT is both KEY_EVENTS. So KEY_EVENTS like JUKE_DIGIT_0 and so on is a better idea?


PLAYLIST:

I should rename to CURRENT_PLAYLIST?

Freebox have PlayNow and PlayNext command. MultiJuke have only PlayNext and can auto submit a album to been played finished.

I Dislike to have a command to every type of manipulation. Instead is much simply to just resubmit songs again at once after that arcour!!

For your software, that is Queue Based, your have NO use of JUKE_CURRENT_PLAYLIST_CURRENTSONG, as I have no use for that command in MultiJuke. So skip that command. I just think the command can been used with software that using PLAYLIST instead of QUEUE based.

So, Simply resubmit the current queue list to CURRENT_PLAYLIST when some Queue Event have been invoked so the first song is allways os that is song in playing.


Juke_Command("JUKE_FEATURE_ATTRACT_MODE", TRUE|FALSE)

just send this command in your init rutine to your Jukebox Software to statement if its true of False.if its off, it false... 

Personly as plugIn Writer I dosen't care how it was invoked. They can detect it other way (example checking if a song is playing using song playing commands), if they want to know that.


Juke_Command("JUKE_SELECTED_MARKED", "title|artist|album|trackNum|genre|totalDuration").

They can get it with checking the CURRENT_PLAYLIST commands.....


Rest is explanied and corrected in the SDK. They was some minor errors from my side.

EDIT: More errors and few commands change, so they hopefully better understand.


About the | char.

I have no problems with | at all!! In Pure basic I might just add a anoter | if there was no Split command. This make sure it find the last |.

[Barry Barcrest]

WOW Guys you have really made some advances since i last looked. I assume once you make the SDK availble i will be able to see what functions are possible for the jukebox plugins to use. I will hold off adding the latest code until i know what i can expect to be in the plugins and i will just bolt it all in at the same time.

Glad everyone got it sorted you have all put a lot of hard work into this. Me i've just been a pain LOL 

[Space Fractal]

Should we say a deadline to Sunday 20 Januar to make sure all got the time to support these commands, and then send a new to Saint to been displayed on the frontpage to due a simulation release with plugin support?

That Even it mostly was Me and UncleT that defined the standard with help and input from LoadMan (that started that all) and HeadKaze? But I still say thanks for your input, Barcrest.

This standard is for all software, and it of course also for Freebox. Fell free to add it of course.

Glad to release the SDK soon, even it was a really hard work and used alots of time monitor this forum.

It just few issues left and until UncleT and I understand the all issues. But it small issues now, the major problems is now gone.

[headkaze]

Should we say a deadline to Sunday 20 Januar to make sure all got the time to support these commands, and then send a new to Saint to been displayed on the frontpage to due a simulation release with plugin support?

That Even it mostly was Me and UncleT that defined the standard with help and input from LoadMan (that started that all) and HeadKaze? But I still say thanks for your input, Barcrest.

This standard is for all software, and it of course also for Freebox. Fell free to add it of course.

Glad to release the SDK soon, even it was a really hard work and used alots of time monitor this forum.

It just few issues left and until UncleT and I understand the all issues. But it small issues now, the major problems is now gone.

What is this SDK you keep speaking of? I thought JukePlugin.zip was the SDK 

And there is still no PureBasic example in there, so how you say you defined the standard is beyond me.

[loadman]

WOW Guys you have really made some advances since i last looked. I assume once you make the SDK availble i will be able to see what functions are possible for the jukebox plugins to use. I will hold off adding the latest code until i know what i can expect to be in the plugins and i will just bolt it all in at the same time.

Glad everyone got it sorted you have all put a lot of hard work into this. Me i've just been a pain LOL 

Welcome back   

For the SDK do you need an example of the host or plug-in in another language?

[loadman]

What is this SDK you keep speaking of? I thought JukePlugin.zip was the SDK 

I think he meant 'host' the SDK (I could be wrong)?
Thanks again HeadKaze for your work on that. I have been also learning some good programming tips (in general) along the way. Over all this has been a good experience for me.   

And there is still no PureBasic example in there, so how you say you defined the standard is beyond me.

Yes if you could make one that would be good please Space Fractal

[Space Fractal]

The very first post of course I have changed over the past.

I waiting to create Pure Basic example when the "SDK" is finished with all defined commands.

The SDK is NOT the wrapper I wrote in the other thread, that is now completly "out of date" (hence removed).

the SDK is the FIRST post only where all defined commands is there. I have changed the orignal post over the time, because I think the post is the easier to find the commands used, because this thread is pretty big now (I never throuch it should been so big).

The most commands is now by UncleT and I changed some and added few others.

It is now heavy changed to only use 2 functions, the rest is just string commands and have a argument to been parsed by the plugins. In this way it easy to add commands to a v1.1 later time.

I do pretty sure I should use my time to add plugin Support to MultiJuke first, and then writing a real Pure Basic plugin example how the parser can work with source. I do update the "wrapper" soon to use with these 2 commands used + some helper functions for those that want it.

I also of course want examples by other language, C++ and/or Visual Basic 6 of course. I can put them in a file in the first post to checking out.

I did not say I defined the SDK (sorry if I wrote that), most should go to UncleT now for his ideas and I finally accepted. Of course big credits should got to all of you in this thread: headkaze, LoadMan and also Barcrest.

[loadman]

OK I think the issue here is what a SDK is?

I define a Software Development Kit to be a combination of two things.

1) A document telling how to use it and all the commands/functions.

* I Imagine that this will be heavily based on your first post Space?

2) Basic software examples and tools in as many languages as possible.

* HeadKaze has already (kindly) provided most of this (it may need updating) with a VB6 host and C++ and Delphi Plug-in examples. This will need Pure Basic example from Space Fractal as he has changed the examples he first posted.  More languages would be nice too

Are we all on the same page here ? 

[Edit] for the record. HeadKaze's next post came a microsecond after mine   

As for credits. I would suggest that we just have a list a name of the people involved. No need to measure the input of each person or waht there role is. Who cares? 


 

[headkaze]

The very first post of course I have changed over the past.

I waiting to create Pure Basic example when the "SDK" is finished with all defined commands.

The SDK is NOT the wrapper I wrote in the other thread, that is now completly "out of date" (hence removed).

the SDK is the FIRST post only where all defined commands is there. I have changed the orignal post over the time, because I think the post is the easier to find the commands used, because this thread is pretty big now (I never throuch it should been so big).

The most commands is now by UncleT and I changed some and added few others.

It is now heavy changed to only use 2 functions, the rest is just string commands and have a argument to been parsed by the plugins. In this way it easy to add commands to a v1.1 later time.

I do pretty sure I should use my time to add plugin Support to MultiJuke first, and then writing a real Pure Basic example how the parser can work with source.

I also of course want examples by other language, C++ and/or Visual Basic 6 of course. I can put them in a file in the first post to checking out.

I did not say I defined the SDK (sorry if I said that), most should go to UncleT now for his ideas and I finally accepted. Of course big credits should got to all of you in this thread: headkaze, LoadMan and also Barcrest.

All an SDK (Software Development Kit) is two things; source code and documentation. So when your referring to the SDK you must be referring the command list which is part of the documentation. Okay I get it now!

EDIT: Loadman beat me to it! 

[Space Fractal]

Sorry if I misused SDK. Dont take the serious for a typo and misuse. Please. Let us do this finish instead instead using time with this. I should of course wrote "The API document" instead. You know you might should guessed what I really would  wrote  . It does turn into a SDK sooner or later anyway.

[loadman]

Sorry if I misused SDK. Dont take the serious for a typo. I should of course wrote "The API document" instead. You know you might should guessed what I really would  wrote  .

Cool. Just making sure we ALL had the same understanding of what it is (two elements to a SDK) 

And yes I'm half asleep so making many typos.. 

[unclet]

SELECTED ALBUM:

Juke_Command("JUKE_MARKED_ALBUM", "NUMBER")
Juke_Command("JUKE_MARKED_TRACK", "NUMBER")

I have changed the command into marked album. The value can been anything, both letters and value. The user can configurere the plugin anyway, how it should been used.

When they begin to enter a new digit or letters, just send the command again with the new value. Something like this:

1
12
125

On this way, a plugin better can understand how many digits and or letters the user actuelly have inserted. What about if they deleted a digit again, just send the new value again with a digit fewer, like 12.

This is a good idea but I really dislike the "JUKE_MARKED_ALBUM" and "JUKE_MARKED_TRACK" commands names.   Entering digits one by one has nothing to do with "marking" album numbers or "marking" track numbers.

Lets keep your idea, but change the command names to "JUKE_ENTER_ALBUM_VALUE" and "JUKE_ENTER_TRACK_VALUE"

So JUKE_ENTERED_ALBUM_DIGIT and JUKE_ENTERED_TRACK_DIGIT is both KEY_EVENTS. So KEY_EVENTS like JUKE_DIGIT_0 and so on is a better idea?

Yes, we can send each individual entered digit and letter as a unique key event (if desired). So when the user enter's an album number (1234), then this is the sequence of events which are sent (if you support the key events of course) ....

JUKE_KEY_EVENT_DIGIT_1
JUKE_ENTER_ALBUM_VALUE 1
JUKE_KEY_EVENT_DIGIT_2
JUKE_ENTER_ALBUM_VALUE 12
JUKE_KEY_EVENT_DIGIT_3
JUKE_ENTER_ALBUM_VALUE 123
JUKE_KEY_EVENT_DIGIT_4
JUKE_ENTER_ALBUM_VALUE 1234

Do you agree?


***  I recommend we make a standard that all key event commands start with the "JUKE_KEY_EVENT_xxxxxx" text.   This way I can see exactly what is going on in my code and realize these commands are for the plugin.

PLAYLIST:

I should rename to CURRENT_PLAYLIST?

This statement by itself has no meaning to me.  Could you possibly explain yourself a bit more.   

Freebox have PlayNow and PlayNext command. MultiJuke have only PlayNext and can auto submit a album to been played finished.

You tell me that FreeBox has "PlayNow" and "PlayNext" but I have no idea in the world what those features mean so I have no idea what you are trying to tell me.

I dislike to have a command to every type of manipulation. Instead is much simply to just resubmit songs again at once after that arcour!!

Well I need to have queue commands to inform the plugin how the queue is managed.

I have a song queue which can hold 1000 songs.  If one song is removed, I do not plan on informing the plugin about 999 other songs by resubmitting each individual song one at a time.  I would simply inform the plugin which queue position was removed and it will be up to the plugin to realize all other songs below this removal position gets moved up one position.   

Same thing will occur when the user selects a song to play and it is inserted into the song queue at "random" (this is a feature which can be used).   When this occurs I would simply tell the plugin about the one song that was inserted and the position at which is was inserted in to the queue.

Now, for multiple song queue changes which occur at the same time (ex: adding 25 song tracks to the song queue at one time at random) then I would populate the "queue.txt" file to inform the plugin about the complete new queue contents.  This would be easier than sending 25 "JUKE_QUEUE_ADD_SONG" commands to the plugin I think.

For your software, that is Queue Based, your have NO use of JUKE_CURRENT_PLAYLIST_CURRENTSONG, as I have no use for that command in MultiJuke. So skip that command. I just think the command can been used with software that using PLAYLIST instead of QUEUE based.

So, Simply resubmit the current queue list to CURRENT_PLAYLIST when some Queue Event have been invoked so the first song is allways os that is song in playing.

I do not know the difference between a jukebox which is PLAYLIST based and a jukebox which is QUEUE based?  What is the difference?  Actually what is your definition of "PLAYLIST" and how "exactly" does your jukebox use it?

My jukebox allows the user to create personal "playlist" lists and my software also maintains a song "queue".  So my software used BOTH playlist and queue functions.

Here are my definitions of playlist and queues.  You will notice they are NOT related to each other at all.

QUEUE:  This is a song queue in which songs the user has selected for playing are stored until they can be played.

PLAYLIST: A list of songs from multiple albums and artists which the user can group together into one list (ex: Dads Favorites, Holiday Songs, etc...).   The songs listed in a "playlist" can then be selected to be played.

I need some way of informing the plugin about how my soing QUEUE changes and I can NOT simply resubmit the complete song queue to the plugin everytime there is one change which occurs.  As a result I still believe having the following commands are required:

JUKE_QUEUE_ADD_SONG (song added to queue by user or system)
system|queuePosNum|name|artist|album|albumNum|trackNum|genre|totalDuration|

JUKE_QUEUE_REMOVE_SONG (song removed from queue by user or system)
system|queuePosNum|

JUKE_QUEUE_MOVE_SONG (song has been moved in the queue by user or system)
system|oldQueuePosNum|newQueuePosNum|

JUKE_QUEUE_CLEARED (the song queue has been cleared by user or system)
system|

JUKE_QUEUE_CHANGED (the song "queue.txt" file has changed)
null

These are 5 additional commands .... not that many.

Note: Navigating through the PLAYLIST lists can be done using KEY_EVENTS I believe.

Juke_Command("JUKE_FEATURE_ATTRACT_MODE", TRUE|FALSE)

just send this command in your init rutine to your Jukebox Software to statement if its true of False.if its off, it false... 

Personly as plugIn Writer I dosen't care how it was invoked. They can detect it other way (example checking if a song is playing using song playing commands), if they want to know that.

I can not represent the state of the Attract Mode feature with just two values (on/off) only.   

I indicated in my previous post that I think there should be three values for the "JUKE_FEATURE_ATTRACT_MODE" command and gave explanations of each value:

onActive     (attract mode has been activated by the user and is currently running)
onNotActive (attract mode has been activated by the user and is NOT currently running)
off         (attract mode has NOT been activated by the user)

Having the Attract Mode feature ON does not tell the plugin whether the Attract Mode feature is actually ACTIVE or NOT.  I can turn on the Attract Mode feature but it might not be active yet since the user is still interacting with the jukebox software.

It seems like you are trying to get all interfaces to use a standard set of values like ON/OFF/ENABLE/DISABLE.    This is not needed since each command is unique so the "JUKE_FEATURE_ATTRACT_MODE" command can have OnActive/OnNotActive/Off values and eveything will work fine.   As long as the plugin knows what values are related to each command then the plugin will know what to look for when the command is received.

Juke_Command("JUKE_SELECTED_MARKED", "title|artist|album|trackNum|genre|totalDuration").

They can get it with checking the CURRENT_PLAYLIST commands.....

I absolutely have no idea what you are saying here at all.   I have no idea what a "CURRNET_PLAYLIST" command does and I have never seen the "JUKE_SELECTED_MARKED" command.   

I do know that I dislike the term "MARKED" though ....

Anyway, please explain what you are talking about. 

About the | char.

I have no problems with | at all!! In Pure basic I might just add a anoter | if there was no Split command. This make sure it find the last |.

This was my whole point ..... if there is no Split() command available (or the plugin author does not use it for some reason) then parsing might be a problem.   If you have no problem with it, then I would simply add a trailing "|" character to the end of each cmdValue string.  It is easy to do and it might save us some grief.

[headkaze]

About the | char.

I have no problems with | at all!! In Pure basic I might just add a anoter | if there was no Split command. This make sure it find the last |.

This was my whole point ..... if there is no Split() command available (or the plugin author does not use it for some reason) then parsing might be a problem.   If you have no problem with it, then I would simply add a trailing "|" character to the end of each cmdValue string.  It is easy to do and it might save us some grief.

Two seconds on Google later...

Code: [Select]

Procedure.l SplitArray(array.s(1), text.s, separator.s = ",") ; String to Array
 
  Protected index.l, size.l = CountString(text, separator)
 
  ReDim array.s(size)
 
  For index = 0 To size
    array(index) = StringField(text, index + 1, separator)
  Next
 
  ProcedureReturn size
EndProcedure
http://www.purebasic.fr/english/viewtopic.php?t=21495

[unclet]

Two seconds on Google later...

      

Since you can not asssume a plugin author knows how to use Google, I think in the SDK documentation we dedicate the last trailing "|" to headkaze 

[headkaze]

Two seconds on Google later...

      

Since you can not asssume a plugin author knows how to use Google, I think in the SDK documentation we dedicate the last trailing "|" to headkaze 

People who can't deal with a trailing "|" should not be writing software! 

Call it the Headkaze "Tail Case"! 

Or put this in the Jukebox code (sorry for the C#)...

Code: [Select]

if(Value.Substring(Value.Length - 1) == "|")
{
   MessageBox.Show("You bloody moron! You have a trailing '|' character. Headkaze HATES that. Program exiting...");
   Application.Exit();
}
 

[loadman]

if(Value.Substring(Value.Length - 1) == "|")
{
   MessageBox.Show("You bloody moron! You have a trailing '|' character. Headkaze HATES that. Program exiting...");
   Application.Exit();
}

 

 

You guys can 'Pipe' off.   

I would then have it trigger my Plug-in to make a Fart noise   

he he  I needed that Laugh!

 0x2b|~0x2b|   

[Space Fractal]

Please, Let us all doing the documention work finished instead of these type of posts..


Unclet:

JUKE_KEY_EVENT, you can call whatever you like, if it easy to code that way. The Plugin should just use that KEY_EVENT name as it got. But you right here.

I referenced a PLAYLIST as typical use in a media player (like Winamp and Windows Media Player).... They never delete the played song from the queue, they just jump into the next song played.

Due to that I just renamed to SONGLIST instead. I now pretty use the commands you gave (but removed QueueChanged, that is completly uneed), but I just added a argument to JUKE_QUEUE_ADD_SONG to feed the PlayNext (Add the song to queue to been played after the current song) and PlayNow (Play directly)...

JUKE_QUEUE_CHANGED is not actuelly needed anymore. Just remove the current song from its queue.

I just change JUKE_FEATURE_ATTRACT_MODE to fit you need, but I so need to add a SCREEN_SAVER command as well, since it act a bit diffecene. Some Plugins might then use the some code, but I dosent care here.

JUKE_SELECTED_MARKED is removed completly.

[SGT]

Please, Let us all doing the documention work finished instead of these type of posts..

Space Fractal, are you a robot?  Relax, its called humor. 

[unclet]

Thank you for explaining what a Playlist is ...... I never played around with WinAmp or Windows Media Player that way ........ it makes more sense to me now.   

JUKE_QUEUE_CHANGED is not actually needed anymore. Just remove the current song from its queue.

The reason why I wanted a command like this was to inform the plugin that a "queue.txt" file has been changed.   The "queue.txt" file was going to list all of the song queue contents for the plugin.  Now, normally I would use ADD_SONG, MOVE_SONG, REMOVE_SONG commands most of the time, however, when many songs are added to the queue very quickly (ex: adding 50 songs into the queue at one time) then instead of sending 50 separate "ADD_SONG" commands to the plugin, I would simply add all 50 songs, save the queue list into a "queue.txt" file and then send "one" "JUKE_QUEUE_CHANGED" command to the plugin only.   Sending "one"command is much better then sending "50" commands.

This is the 4th time I am giving this example to justify why I think the "JUKE_QUEUE_CHANGED" command is required.   Now that you know my software is capable of adding many many songs to the queue at once, then you might now understand why I need a command like "JUKE_QUEUE_CHANGE".   If you still do not believe I need a "JUKE_QUEUE_CHANGE" command then please tell me exactly how I should inform the plugin I added 50 songs to the queue at one time.

Of course we can call this command "JUKE_SONGLIST_CHANGED" instead of "JUKE_QUEUE_CHANGED"

Juke_Command("JUKE_SONGLIST_CLEAR", "")
Clear the SONGLIST.

Juke_Command("JUKE_SONGLIST_CLEAR", "System")
The song queue has been cleared by user or system.

You have both of these commands defined and they are meant to do the same thing.    Please remove Juke_Command("JUKE_SONGLIST_CLEAR", "") it is not required.

Juke_Command("JUKE_SONGLIST_ADD_SONG",
"system|position|queuePosNum|title|artist|album|trackNum|genre|totalDuration")
Add a song into that position in the queue.

1) Why do you define both "position" and "queuePosNum" values as part of the string?  You probably only need the "position" value.

2) Please put back the "albumNum" value since my software handles these values as two separate values.  Also, it is not nice to put two values (album and albumNumber) into one "album" text string.

system|position|queuePosNum|title|artist|album|albumNum|trackNum|genre|totalDuration

3) For all "JUKE_SONGLIST_xxx"  commands, please rename "queuePosNum" to be just "position"

• Albumnumber or such should been part of the album name, like "01 Album".

Please remove this statement since the "albumNum" value should be listed as a separate value and not as part of the "album" string value.

• Some songs might not have a TotalDuration if it is unknown.

Just to be clear here  .....  if "any" of these values are unknown then they simply do not need to be provided, however, all of the required "|" characters must always be provided.

Juke_Command("JUKE_SONG_PAUSE","")
New song is just started.

Juke_Command("JUKE_SONG_START","")
Current song has been paused.

I mentioned this in my last comments...... the descriptions you have for these two commands are not describing the correct command ...... (see RED above). 

Also please move the "JUKE_SONG_START" command before the "JUKE_SONG_FINISHED" command in your list. 

Juke_Command("JUKE_VOLUME_MUTE", "TRUE|FALSE")

I understand this command take "one" value .... either TRUE or FALSE, but how you currently have it defined it looks like two values since you are using the "|" separator character.

Please replace "TRUE|FALSE" with "value" like this:

Juke_Command("JUKE_VOLUME_MUTE", value)

..... and in the description of the command you can simply explain "value" can be either "TRUE" or "FALSE".

**  You do this with some of the other commands as well ..... please check them all and make sure you define them correctly.

[loadman]

note: Visual Basic 6 can get returned strings using a little dll I made. Look to the bottom of the first thread.

Is this applicable anymore?


[Later]

Ohh I see what you meant I think, A Static Library rather than DLL 

[headkaze]

note: Visual Basic 6 can get returned strings using a little dll I made. Look to the bottom of the first thread.

Is this applicable anymore?


[Later]

Ohh I see what you meant I think, A Static Library rather than DLL 

No the PeekMemory.dll is not necessary as I figured out how to return strings to VB6 using API functions... That code he pasted in the first post is from the code I use in the current SDK (JukePlugin.zip). Don't know why it's there in the first thread as PeekMemory.dll has never been needed 

Space Fractal: You can remove PeekMemory.zip and that source code as we don't need it nor use it.

The PtrToVBString() function was the key to getting a string...

Code: [Select]

sPluginInfo = PtrToVBString(CallFuncPtr(pDC, pGetPluginInfo, vbNull))

[loadman]

Not sure if this helps, but attached is the MaLa SDK doc...

Is this the sort of format we will use here?

[Space Fractal]

All document errors you saw is fixed.

I have removed queue.txt because this file is NOT needed any more due to the much much faster JUKE_SONGLIST_ADD_SONG commmand.

Submitting  50 songs at once to JUKE_SONGLIST_ADD_SONG is much much faster than using queue.txt (since there is no hd access), and I guess the plug-in easily can handle 50 songs without any issues.

To suit your need, I have added a another argument to JUKE_SONGLIST_ADD_SONG, that tell the plug-in, you want to add a another song under a for next loop....

JUKE_SONGLIST_ADD_SONG  to been using SongNr and AlbumNr near the last argument to make more sence (before more argument). Values should been the same as them you gave using DIGIT COMMANDS.

HeadKaze:
Please give me the VB6 code again to the string without PeekMemory, and I change the first post about (and remove PeekMemory file).

[unclet]

Submitting  50 songs at once to JUKE_SONGLIST_ADD_SONG is much much faster than using queue.txt (since there is no hd access), and I guess the plug-in easily can handle 50 songs without any issues.

To suit your need, I have added a another argument to JUKE_SONGLIST_ADD_SONG, that tell the plug-in, you want to add a another song under a for next loop....

Sounds good to me   


Now, just a couple more comments:

Juke_Command("JUKE_APP_UNICODE","FALSE|TRUE")
Does the Jukebox support Unicode or not? Then the UTF8 formatted strings can been used.

Please change to "TRUE or FALSE"

Juke_Command("JUKE_SONGLIST_CLEAR", "")
Juke_Command("JUKE_SONGLIST_CLEAR", "System")

You have defined "JUKE_SONGLIST_CLEAR" command twice.   Please check your list.  They are not defined next to each other in your list but they are BOTH defined.    Please keep the second definition of the command with the "system" parameter.

Juke_Command("JUKE_SONGLIST_MOVE_SONG", "System|position|newPosition")
Song has been moved in the queue by user or system.

Please rename parameters  to the following:
Juke_Command("JUKE_SONGLIST_MOVE_SONG", "System|oldPosition|newPosition")

Juke_Command("JUKE_FEATURE_ATTRACT_MODE", onActive or NotActive or Off)

onActive (attract mode has been activated by the user and is currently running)
onNotActive (attract mode has been activated by the user and is NOT currently running) off (attract mode has NOT been activated by the user)

Please rename parameters to the following:

Juke_Command("JUKE_FEATURE_ATTRACT_MODE", onActive or onNotActive or Off)

[Space Fractal]

Done  . More errors?


A last thing around Split command in Pure Basic:
There is no indbuilt split to array command in Pure Basic, but its exist a another command, that do the same, just without array:
Result$ = StringField(String$, Index, Delimiter$)

So no problems for me on that point. So no need to use that function HeadKaze posted. The major problem was with returned strings using VB6. Here I think I need the code to been posted in the first post.

[unclet]

All done for me!      

Although, once the coding starts and we really start playing with some of the plugin Beta applications then we might fine we need to tweak some SDK stuff before we officially officially release the SDK for good.   

Space Fractal
Thanks for your all your work!

[Space Fractal]

We can allways make a v1.1, if we see a missing command or two.

These commandlist for v1.0b is now finally done. 

Hope all goes well  .


Hey, you dident notice a JUKE_KEY_EVENT_SEND "bug"... There was no KEY_EVENT sendt, but fixed in the document.


1. Should we have a child board about plugins and have a sticky tread about it?

2. Should I ask moderator (Saint) to remove these threads to hell?
 - new vision(s) on a new SDK (no listed commands)
 - Plugins: A Little wrapper dll for dynamic loading of Plugins (out of date)
 - Any maybe the dummy the thread about 2 plugin standards?


For the middle one,  I could simply use the example wrapper into the firstr thread it self, so we dosent have unneeded threads about it (unless we have a child board)?


Done a sound plugin, and hopefully it works. The sound plug can been found in that thread, I used the old document API.

[unclet]

I would just see how many people start writing plugins and then it we need a child board make one.   

Although one could argue that there are not "tons" of people other then us few who ask questions in the current "Audio/MP3/Jukebox" forum anyway, so it is feasible that people simpy ask plugin question in the existing forum.

I am just glad to be done deisgning the SDK.   I can start coding some of this soon, but I really need to get back to my jukebox build a bit first.  I spent a lot of my time on this SDK, must to other stuff for a while.

[loadman]

I started a Wiki Page.  IT's a bit of a mess at the moment. I will look at it tonight


http://wiki.arcadecontrols.com/wiki/Jukebox_Plug-Ins

Obviously we can us this to tell users what a Juke-Box Plug-In is.  But in the short term possibly we could use it to fine tune the SDK.?

What do you think?

[unclet]

I would think a Wiki page we be nice so all jukebox software authors and plugin authors can edit it to inform people what commands they support, like within a BIG grid.

[unclet]

headkaze
Will you supplying a new updated JukePlugIn class module for use in VB6?   

Space Fractal

Juke_Command("JUKE_FEATURE_RANDOM_MODE", TRUE or FALSE)
Radio or Random mode is enabled(TRUE) or disabled(FALSE)

We you please explain what the "JUKE_FEATURE_RANDOM_MODE" command does?  I missed this one during the review and I want to understand what it does because I am going to ask you to rename it to something which is more meaninful.

Does it mean that the jukebox does not have any songs which were entered by the user  to play so it will randomly pick a song to play itself?  If so, then isn't this covered by the "JUKE_SONGLIST_ADD_SONG" command .... you just indicate the "system" selected the song automatically .. correct?

Please explain what this command does.

Juke_Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_NAME")
This command is required before JUKE_PLUGIN_CONFIGURE is invoked. This make sure a plugin can "listen" to a KEY_EVENT command from the Jukebox Software and example effect a sound effect to a KEY_EVENT.

A Jukebox Software can create any KEY_EVENT commands that can been controlled by the user (also like a keybinding).

Only KEY_EVENT commands (keybindning) is needed for the plugin to known, so they can used for various things like LedWiz, Sound, Remote controlling and other things.

Also, this command should be listed under the "KEY EVENTS" section you have defined with the other KEY_EVENT_SEND and KEY_EVENT_GET commands.

[Barry Barcrest]

Ok i created a little test app to see if i can list all the plugins so i have this code..

Code: [Select]

    Dim RetVal As Long, x
    Form1.File1.path = App.path + "\plugins\"
    For x = 0 To Form1.File1.ListCount
        RetVal = plugin.Initialize(Me.hDC, App.path + "\plugins\" + Form1.File1.List(x))
        temp = plugin.Name & "," & plugin.Author & "," & plugin.Version & "," & plugin.Description
        Form1.List3.AddItem temp
        RetVal = plugin.Shutdown
    Next

That loops through a file list box that has the mask set to *.jps and returns the descriptions to a list box.

Then i click an entry in the list box and call this for the config button.

Code: [Select]

    Dim RetVal As Long
    RetVal = plugin.Initialize(Me.hDC, App.path + "\plugins\" + File1.List(List3.ListIndex))
    Dim RetVal2() As String
    RetVal2 = plugin.Command("JUKE_PLUGIN_CONFIGURE", "WINDOW_HWND")
    RetVal = plugin.Shutdown

I am pretty sure i am doing something wrong here, can anyone point me in the right direction?

[unclet]

For each JPS file you should call Initialize and then after confirm whether the plugin is valid.   If it is valid then read the plugin information.   You should NOT be calling "Shutdown" until your jukebox app is closed (Form_Unload() routine).  If you call Shutdown before then (like you are doing) then you lose the connection with the plugin.

For x = 0 to ListCount

        JukePluginArray(x).Initialize Me.hDC, curPluginFilePath
       
        'Plugin could NOT be initialized, skip to next plugin
        If (JukePluginArray(x).IsPlugin = False) Then
            GoTo nextplugin:
        End If

        pluginDescText = JukePluginArray(x).Name & "  " & JukePluginArray(x).Author & "  " & _
                                 JukePluginArray(x).Version & "  " &  JukePluginArray(x).Description

nextplugin:

Next

When the listbox is populated and the user highlights a plugin and then clicks on the "Configure" button, then you do something like this:

pluginRetStr = JukePluginArray(selectedIndex).Command("JUKE_PLUGIN_CONFIGURE", vbNullString)

Now, I also added the ability for the user to enable/disable plugins via the GUI interface rather than making them have to remove the JPS file from the /plugins/ directory, but whether to do this is completely up to you.

[unclet]

Juke_Command("JUKE_SONGLIST_ADD_SONG",
"system|postition|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|more")
Add a song into that position in the queue.

This command is sent when a song is added to a queue

Juke_Command("JUKE_SONG_START","")
New song is just started.

This command is sent when a song starts.   I believe this command needs to have the same cmdValue string as the "JUKE_SONGLIST_ADD_SONG" command above.


PROBLEM:
If the plugin is keeping track of the queue contents then it accepts the "JUKE_SONGLIST_ADD_SONG" command and will receive the song information.  So when it eventually receives a "JUKE_SONG_START" command the plugin will know what song has started so there is no need for the song information in the "JUKE_SONG_START" command.

However, if the plugin does not process the "JUKE_SONGLIST_ADD_SONG" command (ie: does not maintain the queue contents) then there is no way to get the song information to the plugin.  As a result, the "JUKE_SONG_START" command must be updated to include the following cmdValue string:

"system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr"

Basically a plugin which does not maintain the queue contents but would always like to at least know the current playing song has no idea what the song information is unless we make this change.

[Barry Barcrest]

Thanks for the pointers uncleT, i also agree with you on the song start as i don't think i will passing queue information across to the plugin but i would like to pass the song start information.

[unclet]

Just so I am clear ...... you should only be calling ShutDown in your main Form_Unload() routine

    'free all plugins
    SendPluginCommand(JUKE_APP_CLOSED, vbNullString)

    For i = 1 To numOfPlugins
        JukePluginArray(i).Shutdown
    Next i
    numOfPlugins = 0

What does "UNICODE" mean?   Should my software send the "JUKE_APP_UNICODE" command when it starts? 

[headkaze]

Here is the latest SDK with updated source and readme.txt

I removed the JUKE_APP_OPENED and JUKE_APP_CLOSED commands as they are the same as Juke_Initialize and Juke_Shutdown.

I removed the JUKE_PLUGIN_CONFIGURE command and instead added a Juke_Configure(hWnd) function instead.

The example plugin will pop up a window when you call Juke_Configure() to demonstrate how a configuration window will work in your software.

The VB6 Host code has been updated to read a directory of plugins in a folder called "Plugins". It shows how you Initialize and Shutdown all the plugins and how to call a command.

All the commands have been added to VB6 Host code and are very easy to use and wrapped in simple class methods.

UncleT: I don't need to include a Timer example for the JUKE_KEY_EVENT_GET command do I? I think it's pretty straight forward if you know how to place a timer on your form and set the Interval to 200. Then start it when you want to get the key event from the plugin. Just place the JukePlugin.KeyEventGet() in the Timer_Elapsed event to check if it's recieved input.

Space Fractal: You can remove the PeekMemory.dll and VB6 code from the first post as it is not necessary. All the code for VB6 is included in the SDK. Also can you update the first post with the updated readme.txt included in the SDK archive.

And here it is the first JPS SDK v1.0b! ...

[Space Fractal]

Unicode is something needed to support OTHER than english (like Russia and many other EU languages), hence 8 bit ASCII it not good enouch. They so NEED to been 16 bit strings (64KB chars) instead using by the plugin. To been combatile with ASCII, I choiced to use UTF8 strings when doing that. Many ID3tags and ogg is also unicoded.

If you example try to send a song with Russia alphabet to a JUKE_SONGLIST_ADD_SONG, it would otherwice just display wrong LATIN chars (I did have a lots of trouble to get this working correct in MultiJuke).

UTF8 is a ASCII encode system, that use a 8 bit system to send throuch.


I assume JUKE_SONGLIST_ADD_SONG is ALLWAYS to been processed by plugin when they using any SONG playing commands (to been sync with the queue) if they need the queue. When they got a SONG_FINISH command, you might simply remove the song from the queue using REMOVE command. I guess that command is not actuelly needed, but leave it as it are !!

JUKE_FEATURE_RANDOM_MODE is removed (yes you was correct), and added a new system value instead.


HeadKaze:
Juke_Initialize() was renamed to use JUKE_APP_OPENED command in the document, but how do get the JUKE_APP_CLOSED to been the same as Juke_configurere? Please explain.

This is the previous SHUTDOWN command and NOT the configurere command.

You also need to update your SDK around your test plugin, due Juke_Initialize(int Value) and Juke_Shutdown(int Value) is not used in the Document API. Instead You should call them used the explained JUKE_APP_OPENED and JUKE_APP_CLOSED to call these functions.



HeadKaze, I doing that soon  , dont worry if I forgot it now. I do that when I see your SDK and when I went home. BTW can you sent that file into the thread where I have the wrapper aso?

[loadman]

And here it is the first JPS SDK v1.0b! ...

 

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up?

[Barry Barcrest]

Excellent i will be playing with this over the weekend. Hopefully we will start to see some plugins become availble.

[loadman]

Excellent i will be playing with this over the weekend. Hopefully we will start to see some plugins become availble.

We need Two to Tango,  but I'm practicing until some Jukebox will dance with my Plug-in

[headkaze]

Juke_Initialize() was renamed to use JUKE_APP_OPENED command in the document, but how do get the JUKE_APP_CLOSED to been the same as Juke_configurere? Please explain.

This is the previous SHUTDOWN command and NOT the configurere command.

You need to update your SDK to include these commands before I release it to my first post. There are only TWO functions used at all (that actuelly could been just one command, but leave it as it are). There is no longer a direct Juke_Init() command, so rest of them is just commands.

The JUKE_APP_CLOSED was the same as Juke_Configure was a TYPO. I meant Juke_Shutdown and I edited my post to fix that.

I don't like having Juke_Initialize/Juke_Shutdown/Juke_Configure as commands so they will stay as functions. You need to update your source to match mine

[headkaze]

And here it is the first JPS SDK v1.0b! ...

 

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up? 

No it doesn't! That was a typo in the MessageBox function

Here is updated source..

[Barry Barcrest]

So i need to get a new source? I'll wait then...

[Space Fractal]

It seen, UncleT, we need these 3 functions to call things? I dosent have problems with that, so I udpate the document soon to include these 3 functions and I update my plugin soon.

[headkaze]

It seen, UncleT, we need these 3 functions to call things? I dosent have problems with that, so I udpate the document soon to include these 3 functions and I update my plugin soon.

There is no real difference except I think it's important to separate the basic plugin functions from the Jukebox commands. When UncleT see's the source code he will realise there is nothing to worry about as everything is wrapped inside a class anyway. And I think the way I changed it will be better for plugin coders.

So i need to get a new source? I'll wait then...

It's two posts up. Maybe I should start a new thread? It's getting a little annoying having to post source every little update or change.

[Space Fractal]

PLEASE start the new thread.

I might create a general dll to you to include  . that SDK project is now your.

I let my own wrapper dll die (dont post anything into that). I think your SDK is fine, headKaze.

[loadman]

And here it is the first JPS SDK v1.0b! ...

 

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up? 

No it doesn't! That was a typo in the MessageBox function

Here is updated source..

Sorry Mate      

[Barry Barcrest]

It's two posts up. Maybe I should start a new thread? It's getting a little annoying having to post source every little update or change.

Cheers buddy.

[Space Fractal]

Hey, it look last time I updated the Copy&Paste suddently go crazy. I have moved some elements up and down and fixed the messy text.

I looking on HeadKaze SDK and see I can get the Sound Plugin to work with that. That is on the other thread....

[unclet]

headkaze

UncleT: I don't need to include a Timer example for the JUKE_KEY_EVENT_GET command do I? I think it's pretty straight forward if you know how to place a timer on your form and set the Interval to 200. Then start it when you want to get the key event from the plugin. Just place the JukePlugin.KeyEventGet() in the Timer_Elapsed event to check if it's recieved input.

No need to include an Timer example in your code  I understand how it should work.

Actually I wish you take out all examples from your code and just let it function correctly now.   I have not seen your new plugin DLL supplied here yet so perhaps you are alreadt doing this .....


Space Fractal
Keep in mind, when a song from the queue is ready to play, I remove it from the queue and then play it.  Basically, the song does not remain in the song queue when it is playing.  Songs in the queue are songs which are "waiting" to be played.  Once the song is over (ie: done playing) I will send a SONG_FINISH command.     So the SONG_FINISH command is required as well .... do NOT remove it please.

Please DO NOT remove commands from the SDK.   I am trying to code stuff and really do not want commands changing or disappearing until we all agree on the changes.

Not sure if you commented on the "JUKE_SONG_START" command, but please add the information I requested to that command .... it is needed.  I am sure of it.  My jukebox does not function how you think it does ... so please leave the existing commands alone and simply update the "JUKE_SONG_START" command for me.     For those software who do not want to supply the information for JUKE_SONG_START you do not have to ..... no big deal. 

[Space Fractal]

I just want to seperate songlist and player functions completly.

I should let you known the FIRST song from the SONGLIST would allways been the currectly played song for a queue based jukebox (even yours is toally empty). That is why i changed QUEUE to SONGLIST.

How a Plugin Writers would use that SONGLIST, I dosen't care that.....

A Plugin Writer can actuelly easyly detect how many songs that is actuelly is in a QUEUE system like yours: "TotalSongs-1", due the first song is currectly playing. That is what I doing in MultiJuke.



Some commands was removed and added 2, because I think HeadKaze is correct about init, config and shutdown SHOULD been seperated from the parser for easier codning. I also want seperate these too.

They have nothing due to the commands itself.

[unclet]

headkaze

Where did your "first JPS SDK v1.0b!: code go?  I do not see the file and I do not see a new thread started by you which has the code.....


Space Fractal
Please try to provide answers to my comments in the same order as they are dislpayed below so I can easily figure out what your comments are related to.    When you supply comments you do not use the "Quote boxes" so it is very hard sometimes to figure out what you are commenting on exactly.

"JUKE_FEATURE_RANDOM_MODE" command

I would recommend renaming this command to "JUKE_FEATURE_IDLE_SYSTEM_PLAY_MODE" (which means, when the system is idle, then a song will play automatically).

I have a feature like this, but it does not always play a "random" song when this occurs.  The user can select songs from the Top10,25,50,100 lists to play and has the "option" of playing them in order or at random.   As a result, this commands name should not have the word "random" in it since my feature is not always play the songs "randomly"

I would also recommend the parameters be "ON" or "OFF" instead of "TRUE" or "FALSE"

Juke_Command("JUKE_SONGLIST_REMOVE_SONG", "System|position")
Song removed from the queue by user or system or a song is played finished (using queuePosNum=1 as value)

What does "(using queuePosNum=1 as value)" mean?
(Note: There is not "queuePosNum" parameter in the interface ... it is called "position".)

Are you indicating that the "position" value text always be set to "1".  If this is the case, then you are wrong.  The "JUKE_SONGLIST_REMOVE_SONG" command will indicate when a song has been removed from the song queue.  A user of my software can remove any song (from "any" position) from the song queue whenever they want.

For example: When the user removes song located at queue position 45, then the following command will be sent:

JukeCommand("JUKE_SONGLIST_REMOVE_SONG", "0|45")  -- remove song from position 45

So please remove your "(using queuePosNum=1 as value)" statement please since it does not make sense for my software.

I should let you know the FIRST song from the SONGLIST would always be the currently playing song for a queue based jukebox

This is not how my jukebox works and I am not going to try to make my software work like this.   

The first song in my song queue represents the "next" song which will be played.   I am "not" going to use the "JUKE_SONGLIST_ADD_SONG" command to indicate the currently playing song since this is not what it was designed to represent.

I will send the "JUKE_SONG_START" command whenever a new song starts.

Here are the definitions of the commands:

"JUKE_SONGLIST_ADD_SONG" = Add a song into the queue
"JUKE_SONGLIST_REMOVE_SONG" =  Remove a song from the queue
"JUKE_SONG_START" = a new song has started to play


Jukebox software which is PLAYLIST based and DOES NOT remove songs from the song list but instead cycles through all the songs, can still call the "JUKE_SONG_START" when a new song is started.   Jukebox software which is NOT PLAYLIST based (ie: mine) and DOES remove songs from the song list can still call the "JUKE_SONG_START" when a new song is started.  Basically, the "JUKE_SONG_START" command is NOT related to queue functions at all.

In my software, when a song is currently playing and the user selects a new song, then this new song gets placed in the song queue.  When ever a song gets placed into the song queue I send a "JUKE_SONGLIST_ADD_SONG" command with all of the song information (ie: value string information) to the plugin.

When the currently playing song ends, then these are the sequence of commands I will send to the plugin:

JukeCommand("JUKE_SONG_FINISH", null)  <-- current playing song has finished
JukeCommand("JUKE_SONGLIST_REMOVE_SONG", "1|1")  <-- Remove next song from queue position 1
JukeCommand("JUKE_SONG_START", null) <-- next song starts

IMPORTANT: If the plugin does not maintain the song queue (does not support the "JUKE_SONGLIST_ADD_SONG" command at all) then there is no way the plugni will get the currently playing song information at all.  This is why the "JUKE_SONG_START" command must have song information in it  I would imagine a lot of plugin are not going to take the time to maintain the complete song queue so this is really needed.  I would think most plugin might only be interested in the currently playing song only.

Please update the "JUKE_SONG_START" command to have the cmdValue string as follows:

"system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr"

SpaceFractal .... please read and let me know if you agree:

Just thought I would mention this point......

I know your software is "PLAYLIST" based, so I would imagine when a playlist of songs are loaded and your software is simply cycling through e