The NEW Build Your Own Arcade Controls

Main => Audio/Jukebox/MP3 Forum => Topic started by: Space Fractal on January 03, 2008, 05:57:10 pm

Title: Plugins: Document API for JukePlugSys
Post by: Space Fractal on January 03, 2008, 05:57:10 pm
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:





!! 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:




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.


Examples:





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:


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
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 03, 2008, 06:33:10 pm
So this thread is just for Function comments then?   ;D   :laugh2:

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$) ;
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: unclet on January 03, 2008, 07:23:56 pm
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   :applaud:


Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Barry Barcrest on January 03, 2008, 07:41:27 pm
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 03, 2008, 08:09:06 pm
- 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  ;)
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: unclet on January 03, 2008, 08:24:28 pm
loadman
Yep..... just letting the plugin know everything the software user is doing.   I dont like worms   :P

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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Barry Barcrest on January 03, 2008, 10:59:04 pm
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 12:36:23 am
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.

Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 06:06:05 pm
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 06:43:54 pm
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 !!
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 06:55:48 pm
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?
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: unclet on January 04, 2008, 07:08:33 pm
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.

Quote
- 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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 07:11:42 pm
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.

Quote
- 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..   ???
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 07:31:09 pm
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.

Quote
- 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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 07:45:31 pm
Cool Layout

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


Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 07:48:50 pm
Cool Layout

Quote
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).
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: unclet on January 04, 2008, 08:52:10 pm
Quote
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.


Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 09:02:57 pm
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  ;)

Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Barry Barcrest on January 04, 2008, 09:08:05 pm
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 09:15:39 pm
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?





Title: Re: debating about functions needed by Jukebox Plugins......
Post by: unclet on January 04, 2008, 09:17:18 pm
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 09:25:23 pm
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.




 
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 04, 2008, 09:34:54 pm
I think the effort the "standardize the routines" (and their parameters) which might be used by various jukebox software application is much more powerful.   

 :applaud:

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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 04, 2008, 09:43:30 pm
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.




Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Barry Barcrest on January 05, 2008, 01:49:25 am
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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 05, 2008, 03:06:19 am
OK How about a compomise?

Change the list into two groups

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

Then some optionals:  :dunno
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Barry Barcrest on January 05, 2008, 03:48:13 am
OK How about a compomise?

Change the list into two groups

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

Then some optionals:  :dunno

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.
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: loadman on January 05, 2008, 04:36:29 am
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 ;D  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

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

Quote
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
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 05, 2008, 06:50:42 am
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?
Title: Re: debating about functions needed by Jukebox Plugins......
Post by: Space Fractal on January 05, 2008, 07:58:34 am
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....
Title: Re: plugins: debating about functions needed by Jukebox Plugins
Post by: unclet on January 05, 2008, 08:23:22 pm
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.

Quote
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.
Title: Re: plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 05, 2008, 08:57:05 pm
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.

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



Title: Re: plugins: debating about functions needed by Jukebox Plugins
Post by: unclet on January 05, 2008, 10:03:16 pm
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.
Title: Re: plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 06:41:42 am
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.
Title: Re: plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 07:01:48 am
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).....
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: unclet on January 06, 2008, 07:23:30 am
Quote
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....
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 07:38:25 am
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?

Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 08:05:55 am
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 08:20:18 am
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 *).
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 08:43:17 am
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).






Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: unclet on January 06, 2008, 09:06:04 am
Quote
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:

Quote
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).
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 09:23:51 am
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.

Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 10:00:14 am
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);
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: unclet on January 06, 2008, 11:06:39 am
Space Fractal

Quote
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:

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

 :dunno
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 11:46:16 am
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 02:24:35 pm
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 03:14:20 pm
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.


Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 03:28:56 pm
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 03:36:44 pm

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.



Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: headkaze on January 06, 2008, 03:39:49 pm

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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 03:45:49 pm
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.


Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 04:43:50 pm
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: loadman on January 06, 2008, 05:06:06 pm
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.  :cheers:
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Barry Barcrest on January 06, 2008, 05:12:35 pm
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.
Title: Re: Plugins: debating about functions needed by Jukebox Plugins
Post by: Space Fractal on January 06, 2008, 05:25:15 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 06, 2008, 07:30:35 pm
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.  :)
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 06, 2008, 09:54:44 pm
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.


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

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: loadman on January 06, 2008, 10:38:04 pm
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)  ;D
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 02:49:59 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Barry Barcrest on January 07, 2008, 06:01:12 am
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?
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 06:19:01 am
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?
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 07:10:42 am
Quote
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 ......
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 07:22:09 am
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.....

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Barry Barcrest on January 07, 2008, 08:42:46 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 12:11:03 pm
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.....


Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 12:12:28 pm
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....
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 02:16:17 pm
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):
Quote
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):
Quote
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:

Quote
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:


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


Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 02:37:37 pm
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....





Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 02:50:48 pm
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.

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 02:57:04 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 03:06:38 pm
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.

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 03:20:50 pm
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.


Quote
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).
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 03:22:10 pm
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:
Quote
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 .....

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

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 03:32:06 pm
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)....
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: unclet on January 07, 2008, 04:35:35 pm
Quote
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.

Quote
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   :P)

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.


Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 04:51:11 pm
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.

Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: loadman on January 07, 2008, 05:12:00 pm
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.  ;D
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: headkaze on January 07, 2008, 05:15:39 pm
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  :dunno
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: loadman on January 07, 2008, 05:18:17 pm
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  :dunno


I gotta go to work now :-(     
Title: Re: Plugins: A Function List using by Jukebox Plugins
Post by: Space Fractal on January 07, 2008, 05:19:56 pm
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


Title: Re: Plugins: A Function List using by Jukebox Plugins (dropped)
Post by: unclet on January 07, 2008, 08:42:01 pm
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 ......
Title: Re: Plugins: A Function List using by Jukebox Plugins (dropped)
Post by: Space Fractal on January 07, 2008, 11:58:05 pm
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?

 
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: loadman on January 08, 2008, 04:10:34 am
 :soapbox:

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.  :P

But it would be a SUPER BONUS if Space Fractual (using his obvious Enthusiasm, ideas and energy  ;D ) 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   :P

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   :cheers: 

The next time I post here will be to announce to release of my first JukeBox Plug-in  :applaud:
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Barry Barcrest on January 08, 2008, 05:17:28 am
 :censored:

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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 07:05:13 am
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.



Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 07:11:54 am
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?


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 07:38:32 am
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.


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 09:46:30 am
I think I have an easy solution for getting strings back to the jukebox software ..... but lets not talk about sending data "back" to the jukebox software yet ...... lets just resolve sending data to the plugin first.   I will tell you my idea later.  I consider these items to be two separate things so lets just discuss one at a time for now.
 

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


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

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

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

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


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

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

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



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

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.



Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 10:24:57 am
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).


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Barry Barcrest on January 08, 2008, 10:45:53 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 11:02:40 am
Quote
If the command is not stored (saved), how would it know the command next time you start your jukebox Software up, and the user have already configuration the plug?

I think the problem is that I do not understand what "configuring a plugin" really means.

Based on your comment above, it seems when a plugin is configured (ie: probably only once when the plugin is first loaded) you want the plugin to remember the command set for some reason and if the jukebox software is restarted then you believe the plugin might be "out-of-date", however, I still do not understand why. 

If you will please explain exactly what a plugin would do when the "Juke_Configure()" routine is called, then I might be able to understand all of this better.

Quote
As with Jukebox software do not need to know how they have saved the config settings after a juke_config(). I don't care here. They simple save the settings they need to do.

I do not understand this statement at all.    Perhaps you are just indicating that it is up to the plugin to save the data it needs during it's configuration?  If this is correct, then please see my above comment which asks you to explain exactly what "configuring a plugin" means.

Quote
The plugin is of course not need to listen to a command using a loop.  They would get it sooner or later when you send it using Juke_CommandSend()...
Good ... the plugin is not looping looking for a command.  We agree we can simply call one main routine in the plugin to supply the plugin with the current command.  Good!

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

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 ?
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 11:11:19 am
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.


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 11:45:11 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 12:06:29 pm
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)?
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 12:49:38 pm
My software has already been updated with a Plugin Page which looks almost exactly what headkaze's "Plugin Manager" look like.

The user selects a plugin from the list and clicks the "Configure" button.   This will cause the jukebox software to call the "Juke_Configure()" routine for that particular plugin.   The code inside the "Juke_Configure()" routine (written by the plugin author) would be in charge of opening up a plugin specific configuration application window (exactly like Headkaze's example shows).    The user of the jukebox software can now configure the plugin exactly how they would like it to be configured.   When all configuration has been completed and the plugin configuration application window is closed I would expect the plugin to store all the configuration settings to some file which the plugin maintains itself.

Note: When the jukebox software starts up, there is no reason to automatically call a plugin configuration routine at all ie: no need to call "Juke_Configure()" at all during startup).  The user can simply go into the plugin manager page and click the configure button for the plugin they want to configure.  The user can actually configure the plugin many times over and over if they forgot stuff or want to change settings.   There is no need to limit the "Juke_Configure()" routine of a plugin to only be called one time.

Now, with this description of how a plugin should be configured stated above, I do not see a need for any plugin to "store" any command sent from the jukebox.
 

This is how I would expect the procesing of a "coin insert" event to occur:

1) User starts the jukebox software up

2) User goes to the plugin manager page (within the jukebox software) and sees their plugin listed, highlights their plugin and clicks the "Configure" button to bring up the plugin configuration window.

3) In the plugin configuration application window, there is a section where the user can select which sound they want to hear when a "COIN_INSERT" command is received.  The user simply chooses a sound and then saves the configuration, then closes the configuration window which will take them back to the jukebox plugin manager page once again.

4) While in the plugin manager page the user clicks the little checkbox next to the plugin name to enable it (ie: so it can receive command indications) and then exists the plugin manager page to return to the main jukebox application.

5) User then wants to buy a song so they put a coin in the slot of their machine which makes the jukebox software send a Juke_PluginCommand("JUKE_COIN_INSERT", cmdvalueText) to the enabled plugin application.

6) The plugin will determine the type of command is a "JUKE_COIN_INSERT" command and will then look up in it's own configuration file what exact sound should be played when a coin insert command is received and then will play the sound.



That is exactly how I see it working ...... still no need for the plugin to "remember" what command is being sent because it is sent the command directly everytime.   Now, the plugin obviously has to offer a way for a user to indicate what sound should be played when a JUKE_COIN_INSERT command is received, but that is all up to the plugin application to figure out how to do that and how to save the information for look up later.   

Based on this example above I still see no need at all for a complete list of commands to be sent from the jukebox into the plugin for storage.    The plugin author should know what exact commands can be sent from the jukebox software to the plugin by simply reading the plugin SDK documentation.  Once the plugin author knows which commands are valid to be received, then the actual plugin application can be created to offer the user settings for each of these commands which will define exactly what should happen when the command is received by the plugin.   But again, this is up to the plugin author to code the application and store all the mappings for each command ..... the jukebox software should not have to worry about any of this.  Again, no command list of any kind is required to be stored by the plugin.


** Now ..... perhaps you wanted the plugin application to be "automatically" updated somehow when new "commands" are added to the SDK and somehow have the plugin application understand that a new command exists now without the plugin author having to update their plugin application manually everytime a new command was defined in the SDK?  Is this what you were trying to do?   I personally would not know how to do something like this but it might explain why you wanted the plugin application to know about all existing commands.  Perhaps ..... this is just a guess obviously.


PS:  Thanks headkaze for providing the Plugin Manager pics   :applaud:
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 01:03:06 pm
** Now ..... perhaps you wanted the plugin application to be "automatically" updated somehow when new "commands" are added to the SDK and somehow have the plugin application understand that a new command exists now without the plugin author having to update their plugin application manually everytime a new command was defined in the SDK?  Is this what you were trying to do?   I personally would not know how to do something like this but it might explain why you wanted the plugin application to know about all existing commands.  Perhaps ..... this is just a guess obviously.

PS:  Thanks headkaze for providing the Plugin Manager pics   :applaud:

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


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 01:07:16 pm
Quote
YES !!

I think we just made some progress   :applaud:

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!  :)
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 01:12:12 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 01:14:55 pm
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 .....
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 01:25:00 pm
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?

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 01:32:08 pm
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.

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 01:42:54 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 03:16:36 pm
In your screenshot you indicate "COIN_INSERT", "MOVE_UP" and "MOVE_DOWN" and would like to assign sounds to these commands.   

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

I would need more specific commands like the following:

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

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

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


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

Here is what I propose:

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


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 03:30:27 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 04:39:47 pm
Did you got the little dll working (before we using the text file idea)? I likelig to avoid the text file, if you can.

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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 04:42:06 pm
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   :)

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 05:21:13 pm
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.



Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 05:34:32 pm
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
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 06:00:36 pm
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?
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 06:07:12 pm
Good work on finding a way to get information back to the jukebox software   :notworthy:

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.



Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 06:17:07 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 06:25:48 pm
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.






Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 06:54:09 pm
Quote
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.

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

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

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


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 07:46:40 pm
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...
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 07:58:51 pm
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.

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 08:33:08 pm
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)
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 08:54:00 pm
Quote
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?
 
Quote
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


Quote
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: loadman on January 08, 2008, 09:03:55 pm
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

 :cheers:  :applaud:  :cheers:  :applaud:  :cheers:  :applaud:  :cheers:  :applaud:  :cheers:  :applaud:

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

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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 09:09:53 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 09:22:08 pm
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

 :applaud:

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

 :cheers:
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 09:43:14 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 09:45:16 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 09:52:22 pm
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
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 10:01:11 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 10:04:38 pm
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.....
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 08, 2008, 10:11:46 pm
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?  ;D

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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: loadman on January 08, 2008, 10:16:52 pm
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  ;D

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

 :cheers:

ALL:

A big thanks to everyone for hanging in there.   :applaud:

It got a bit tense and frustrating for a while.  :'(

We seem to be past that and very close to JPS SDK v1.0.   ;D
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 10:24:42 pm
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|
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 10:45:46 pm
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?
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 10:49:20 pm
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 11:03:39 pm
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?


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

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

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


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


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

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

Quote
JUKE_QUEUE_CHANGED can also been used as a command as seen..
Not sure what this means....

Quote
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 08, 2008, 11:17:47 pm
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....
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 08, 2008, 11:29:28 pm
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.


Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 09, 2008, 12:05:54 am
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  ;D

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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: loadman on January 09, 2008, 12:26:01 am
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  :banghead:

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

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 09, 2008, 01:06:44 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 09, 2008, 02:21:18 am
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.
Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 09, 2008, 07:22:05 am
Quote
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.


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

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


Quote
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

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

Quote
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.   :dunno

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 09, 2008, 07:43:00 am
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).



Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: unclet on January 09, 2008, 11:18:23 am
headkaze .... please answer this for me

Quote
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 ....  :dunno

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

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


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

Quote
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:

Quote
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:
 
Quote
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? 

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: Space Fractal on January 09, 2008, 11:25:48 am
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: unclet on January 09, 2008, 01:33:28 pm
Quote
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 !   :applaud:  :applaud:  :applaud:

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

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


Quote
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


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


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


Quote
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)"


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


Quote
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


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


Quote
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


Quote
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


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



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

Title: Re: Plugins: A Function List using by Jukebox Plugins (unfinished)
Post by: headkaze on January 09, 2008, 02:20:28 pm

headkaze

Quote
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 ....  :dunno

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

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


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

Quote
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:

Quote
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:
 
Quote
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...

Quote
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

Quote
name|artist|album|albumNum|trackNum|genre

And then later decided to add another parameter

Quote
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?
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: unclet on January 09, 2008, 03:21:00 pm
Quote
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 .....

Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: headkaze on January 09, 2008, 04:24:11 pm
Quote
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
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: unclet on January 09, 2008, 04:29:41 pm
Sounds good to me then ......  :)
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: Space Fractal on January 09, 2008, 04:58:51 pm

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 |.
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: Barry Barcrest on January 09, 2008, 05:25:55 pm
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  :applaud:
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: Space Fractal on January 09, 2008, 05:45:36 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: headkaze on January 09, 2008, 06:43:13 pm
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  :dizzy:

And there is still no PureBasic example in there, so how you say you defined the standard is beyond me.
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: loadman on January 09, 2008, 06:55:37 pm
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  :applaud:

Welcome back  ;D 

For the SDK do you need an example of the host or plug-in in another language?
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 09, 2008, 06:59:51 pm
What is this SDK you keep speaking of? I thought JukePlugin.zip was the SDK  :dizzy:

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.   ;D

Quote
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
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 09, 2008, 07:08:04 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 09, 2008, 07:15:26 pm
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 ?  :dunno

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

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?  :cheers:


 
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: headkaze on January 09, 2008, 07:19:35 pm
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!  ;D
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 09, 2008, 07:25:11 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 09, 2008, 07:29:10 pm
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)  ;D

And yes I'm half asleep so making many typos..  :banghead:
Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: unclet on January 09, 2008, 07:33:40 pm
Quote
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"

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


Quote
PLAYLIST:

I should rename to CURRENT_PLAYLIST?
This statement by itself has no meaning to me.  Could you possibly explain yourself a bit more.   

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


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


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


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

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


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

Title: Re: Plugins: A Command List using by Jukebox Plugins (STILL NOT FINISHED)
Post by: headkaze on January 09, 2008, 08:05:11 pm
Quote
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
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: unclet on January 09, 2008, 08:15:08 pm
Quote
Two seconds on Google later...

 :laugh2:  :laugh2:  :laugh2:  :laugh2:

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  :applaud:

Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: headkaze on January 09, 2008, 08:31:57 pm
Quote
Two seconds on Google later...

 :laugh2:  :laugh2:  :laugh2:  :laugh2:

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  :applaud:

People who can't deal with a trailing "|" should not be writing software!  :hissy:

Call it the Headkaze "Tail Case"!  :laugh2:

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();
}

 ;D
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 09, 2008, 09:03:14 pm
if(Value.Substring(Value.Length - 1) == "|")
{
   MessageBox.Show("You bloody moron! You have a trailing '|' character. Headkaze HATES that. Program exiting...");
   Application.Exit();
}

 ;D

 :laugh2:

You guys can 'Pipe' off.    ;D

I would then have it trigger my Plug-in to make a Fart noise   :P

he he  I needed that Laugh!

 0x2b|~0x2b|    ;)
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 09, 2008, 09:23:31 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: SGT on January 09, 2008, 10:00:17 pm
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.  ;D
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: unclet on January 09, 2008, 11:09:46 pm
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.   :applaud:

Quote
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"

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


Quote
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"

Quote
  • 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.

Quote
  • 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.


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


Quote
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 09, 2008, 11:19:34 pm
Quote
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 
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: headkaze on January 09, 2008, 11:42:40 pm
Quote
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  :dunno

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))
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: loadman on January 10, 2008, 04:52:54 am


Not sure if this helps, but attached is the MaLa SDK doc...

Is this the sort of format we will use here?
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 10, 2008, 06:37:15 am
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).


Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: unclet on January 10, 2008, 07:17:31 am
Quote
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   :applaud:


Now, just a couple more comments:

Quote
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"


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

Quote
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")


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

Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 10, 2008, 07:22:15 am
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: unclet on January 10, 2008, 09:16:16 am
All done for me!   :applaud:   

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!
Title: Re: Plugins: A Command List using by Jukebox Plugins (FEW ISSUES LEFT)
Post by: Space Fractal on January 10, 2008, 09:49:22 am
We can allways make a v1.1, if we see a missing command or two.

These commandlist for v1.0b is now finally done.  :applaud:

Hope all goes well  :cheers:.



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.



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 05:27:23 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: loadman on January 10, 2008, 05:37:05 pm
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 (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?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 06:33:24 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 07:53:48 pm
headkaze
Will you supplying a new updated JukePlugIn class module for use in VB6?   :notworthy:

Space Fractal
Quote
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.


Quote
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: Barry Barcrest on January 10, 2008, 08:03:51 pm
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?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 08:24:44 pm
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.


Quote
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:

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

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 08:59:40 pm
Quote
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


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





Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: Barry Barcrest on January 10, 2008, 10:06:24 pm
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: unclet on January 10, 2008, 10:15:54 pm
Just so I am clear ...... you should only be calling ShutDown in your main Form_Unload() routine


Quote
    '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?  :dunno
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: headkaze on January 11, 2008, 12:07:05 am
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! ...
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: Space Fractal on January 11, 2008, 12:21:07 am
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?



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: loadman on January 11, 2008, 12:27:49 am
And here it is the first JPS SDK v1.0b! ...

 :notworthy:

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up? :dunno
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: Barry Barcrest on January 11, 2008, 12:44:38 am
Excellent i will be playing with this over the weekend. Hopefully we will start to see some plugins become availble.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: loadman on January 11, 2008, 12:51:47 am
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
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: headkaze on January 11, 2008, 12:53:17 am
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 :P
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: headkaze on January 11, 2008, 12:59:43 am
And here it is the first JPS SDK v1.0b! ...

 :notworthy:

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up?  :dunno

No it doesn't! That was a typo in the MessageBox function ;)

Here is updated source..
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: Barry Barcrest on January 11, 2008, 01:02:26 am
So i need to get a new source? I'll wait then...
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: Space Fractal on January 11, 2008, 01:05:32 am
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.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: headkaze on January 11, 2008, 01:09:33 am
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: Space Fractal on January 11, 2008, 01:15:37 am
PLEASE start the new thread.

I might create a general dll to you to include  :D. 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.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b DONE !!)
Post by: loadman on January 11, 2008, 01:20:04 am
And here it is the first JPS SDK v1.0b! ...

 :notworthy:

Minor thing. The VB Code seems to send a Juke_Shutdown on start-up?  :dunno

No it doesn't! That was a typo in the MessageBox function ;)

Here is updated source..

Sorry Mate   :-[   
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b2 DONE !!)
Post by: Barry Barcrest on January 11, 2008, 01:21:42 am
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.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: Space Fractal on January 11, 2008, 06:46:20 am
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....
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: unclet on January 11, 2008, 07:31:44 am
headkaze

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


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: Space Fractal on January 11, 2008, 07:47:13 am
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.


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: unclet on January 11, 2008, 10:17:00 am
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.


Quote
"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"


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


Quote
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"


Quote

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 each song to play it, then I would imagine your software would only ever send the following commands:

JUKE_SONG_START  <-- new song started
JUKE_SONG_FINISH  <-- new song finished

I would not expect your software to send any "JUKE_SONGLIST_xxxxx" commands at all when the songs are simply being cycled through one by one.  If this is not the case, then plugin authors are going to get pretty confused with how my software and your software  use the "JUKE_SONGLIST_xxxx" and "JUKE_SONG_xxxx" commands.

Basically, this could be a real problem in the SDK if we are using these commands differently. 

Quote
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 !!
For my software the SONG_FINISH command is sent when the currently playing song is finished playing.   The SONG_FINISH command has nothing to do with a song queue.   Again, my "currently playing song" has already been removed from the song queue, so when it finishes playing I need to send "JUKE_SONG_FINISH"
 
Please DO NOT remove the "JUKE_SONG_FINISH" command. 


Quote
Juke_Command("JUKE_APP_OPENED","")

Juke_Command("JUKE_APP_CLOSED","")

I am assuming thee commands were removed since these are now being sent internally when the Initialize and Shutdown routines are being called for the plugin?




Quote
Juke_Command("JUKE_APP_GAINFOCUS","")
When the user just switched to this software to activate the WIndow.

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

I wish you would ask before you change the SDK around by adding new commands.   ::)

Anyway, I do not plan on supporting these commands and do not know why they are required.   I have a lot of child windows which can pop up which can then lose focus (or gain focus) if the user switches to another window to do something before returning back to my Jukebox software window.   Maintaining GAINFOCUS and LOSTFOCUS commands is something I am not interested in doing.

If you really think these are necessary, please explain in detail why you need them.



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

Some Jukebox Software might add a song directly as a first song, so it play directly. Here set a value to 0.
If a positionis to big, it would just added next to the queue.

Info about arguments:

    * Auto means if it was added by the "USER", "RANDOM" or by "SYSTEM".
    * TrackNr and AlbumNr is the same values gave by DIGIT COMMANDS.
    * Some songinfo "tags" might been empty if not used.
    * Some songs might not even contain TotalDuration if it is unknown.
    * If more songs is going to submit at once, the more vaule is set to 1. The last submitted song would have a value set to 0.


I would recommend "removing" everything in RED because:

1) There are no DIGIT_COMMANDS

2) I have decided not to use the "more" value text after all, so probably no longer needed.  If you want to keep it in case you think someone might want this functionality in the future, then this is fine.  Just thought I would tell you I decided not to use it for myself.

Quote
TOTAL SONG DURATION
I was looking at my code yesterday and it is not feasible for me to provide totalDuration values in the JUKE_SONG_START or JUKE_SONGLIST_ADD_SONG commands.     The media player does not tell me this information until after the player has started processing a bit (long story).  Anyway, I really need you to add this information back into the followin command:

Juke_Command("JUKE_SONG_PLAY_POSITION", curPosSecs|totalDuration)

This really should not be a problem for any jukebox software.   If other software do not want to provide this information, then just leave it as a NULL string, however, I do need it since this will be the only way to get the song's totalDuration to the plugin.



Quote
PLEASE CONFIRM SOMETHING FOR ME

All the Juke_Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_NAME") commands which are sent to the plugin will define events used by the specific jukebox software only.  The plugin will remember these events so it can populate a listbox in it's configuration window to allow the user to map things to these commands such as "sounds".    When the key event occurs in the jukebox software, then the Juke_Command("JUKE_KEY_EVENT_SEND", "KEYEVENT") command is sent to the plugin and then plugin can then look the event up in it's list and play the "sound" file.

If this how it works, then the plugin will never know what each KEY_EVENT really does or what each KEY_EVENT value is related to within the jukebox software.   Basically, the plugin never sends these KEY_EVENT events back to the jukebox ever, since they have no idea what they mean so it would be impossible for the plugin to send them back.  Are all of these statements correct?

If all of my comments are correct, then when the plugin wants to send a command to the jukebox software (ie: pause the song, skip the song, etc....) then the plugin must be using the standard set of commands (ie:  "JUKE_SONG_PAUSE", "JUKE_SONG_SKIP", etc..).     Is this correct?

If this is correct ...... then how will the plugin inform the jukebox software that specific digits have been entered?  Will the plugin use the standard "JUKE_ENTER_ALBUM_VALUE" and "JUKE_ENTER_TRACK_VALUE" commands? 

If so, then how will the plugin know how many digits make up an album number or track number.   My jukebox software always requires 5 digits for the album number and 3 digits for the track number no matter how many albums or tracks are loaded.

For example: If only one album with one track was loaded in my software, and the user wants to request the track to be played by entering the digits manually, then the suser would need to enter the following 8 digits:

albumNum = 00001 and  trackNum = 001

Now, some software might not require the user to enter the leading zeroes so entering the same album and track number on other software might only require the following:

albumNum = 1  and trackNum = 1


My whole point is ....... :P

I think the plugin must know how many digits are required for albumNum and trackNum values if the plugin is going to send the "JUKE_ENTER_ALBUM_VALUE" and "JUKE_ENTER_TRACK_VALUE" commands back to the jukebox software.

I know this was a long explanation, but I think it was needed so people would understand what I am saying better.

I think a new command might need to be created to inform the plugin of all max/min values which it will need to know ...... something like this (we can even have the volume min/max values moved into this command):

Juke_Command("JUKE_FIXED_VALUES",
"minVolumeLevel|maxVolumeLevel|minAlbumNumDigitsRequired|maxAlbumNumDigitsRequired| minTrackNumDigitsRequired|maxTrackNumDigitsRequired")



Keep in mind some jukebox software might allow the user to enter "0003", "003", "003" or "3" to indicate an album or track since it will simply trim off the leading zeroes automatically.  My software does not do this since it is smart enough to realize that after 5 digits have been entered for the album number then the next digits being entered must be for the track number.   Anyway, this is why we need the "min" and"max" values for each albumNumDigitsRequired and trackNumDigitsRequired data.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: Space Fractal on January 11, 2008, 12:22:32 pm


In the future, I make all new commands and arguments as red when I update the sdk. I did not about  totalduration this time.

JUKE_FEATURE_RANDOM_MODE, why not JUKE_FEATURE_AUTOPLAY(mode) to been more generic?

mode$ can been any string, and then just show to the user? When it disabled, the string would just been NULL. In MultiJuke I have more Random and Radio options, both can use such a AUTOPLAY to tell about it.



I wont not want to change JUKE_SONG_START...

BUT

 I just got a idea to a new command after invoked JUKE_SONGSTART:

Numberofsongs=Juke_Command("JUKE_SONGLIST_CHECK")

The plugin would send to the Jukebox Software, that does not mainstream queue, but they want resumbit total number of songs based on that limit, and then just after use ADD_SONGS to get these required info.

This mean a plugin can use both PLAYNOW and PLAYNEXT informations without using queue (example).

I could also just add a return value with JUKE_SONGSTART, that tell number of "queue" resubmits?



Juke_Command("JUKE_APP_OPENED","")
Juke_Command("JUKE_APP_CLOSED","")


yes, they does the same thing. HeadKaze (as plugin writers wont use them, and I accepted that.



About the focus thing is ONLY meant to been the main windows, not all internal windows you might have... Like when they switched application. No use in fullscreen applications.

But should I remove them?




MultiJuke does NOT use Playlist, but a user can select any songs from a PlayList to been played in WinAmp and jump both ways and some software might start from beginning again. Hence some might use that command.




no DIGIT COMMANDS? It's JUKE_ENTER_ALBUM_VALUE and JUKE_ENTER_TRACK_VALUE.....



I correct rest, since they are errors.



Juke_Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_NAME") {saw that before removed that}

That is toally up to the user to tell the plugin, that they should do with the commands, and that they are named to been real use. That is why plugin configuration absolutty is required here.

I have wrote a test plugin to been using 2 of these command. It got all key_event trouch these commands and show them in the pulldown list. I save the list into a file, so they can reused next time.

When they some commands back, it allways one of them you created using JUKE_KEY_EVENT_CREATE before CONFIG. Can never been something other.

But again it up to the user to tell the plugin which commands that should been used.







Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: unclet on January 11, 2008, 01:17:53 pm
Quote
JUKE_FEATURE_RANDOM_MODE, why not JUKE_FEATURE_AUTOPLAY to been more generic?

Sound good to me


Quote
I wont not want to change JUKE_SONG_START.

 :banghead:   :banghead:

A one sentence response to my very long detailed description of why exactly my software needs to send this information in the "JUKE_SONG_START" command is really not a good reply.

You even failed to mention "why" you do not want the "JUKE_SONG_START" command to be updated ......... so perhaps you can provide some details as to "why" instead of simply stating "you do not want to change it" and thats it.    I spend a lot of time explaining myself so when you read what I wrote you will understand exactly what I am saying.  You do not tend to do this.   You seem like you prefer quick repsonses which means I often have to guess what you are referring to and never really have a true understanding of how your software functions at all.   It is as if I am trying to solve a very difficult puzzle ..... I have to keep asking you the same question (or present my view) in many different ways over and over in order to try to get an more detailed explanation from you.   I am spending a lot of time typing all of this stuff and I am getting a bit sick of typing so much.

I really do not think you understand when I tell you my software does NOT keep songs in the queue when they are currently playing.   As a result, when a song starts it has NOTHING to do with a QUEUE at all.   As a result, NONE of the the "JUKE_SONGLIST_xxxx" commands have anything to do with this discussion at all.   I believe there is no need to bring up "JUKE_SONGLIST_xxxxxx" commands for this discussion at all since in my software all "JUKE_SONGLIST_xxxx" commands are only related to updating songs in the QUEUE, not for the song which is currently playing.   Again, the word "SONGLIST" means "SONG QUEUE" in my software and the currently playnig song IS NOT in the queue.

I went to a "lot" of trouble a couple of times trying to explain exactly why I "need" the "JUKE_SONG_START" command updated with the song information.   I gave exact descriptions of how my software functions and examples of exactly why this update is "required" for me.  I even saw a previous post by Barcrest who agreed with me on this point immediately.  I really do not think you understand how my song "QUEUE" works, so that is why I spent a "lot" of time typing all this out for you to try to get my point across.

Your response was simply one sentence stating "I wont not want to change JUKE_SONG_START." which simply makes me believe you did not even read my "long" explanation above.   I explicitly provided all the details in my description above to explain how my software is different than yours and justified why this change is required.  Please reread my description fully and then please respond telling me more information other than "I wont not want to change JUKE_SONG_START".

If you do not want to supply the plugin with song information in the "JUKE_SONG_START" command then you do not have to, simply send NULL information for each text string, but I am going to send this information in the "JUKE_SONG_START" command to all the plugins since I "need" to.


Quote
But I just got a idea to a new command after invoked JUKE_SONGSTART:

Numberofsongs$=Juke_Command("CHECK_SONGLIST_QUEUE")

The plugin would send to the JukeboxSoftware, that does not mainstream queue, but they want resumbit total number of songs based on that limit and use ADD_SONGS just after that to get these info.

This mean a plugin can use a PLAYNOW and PLAYNEXT informations without using queue.
This is unneeded and I do not want to use anything like this.

I do not expect a plugin to have to query the jukebox software to get the song information.  My software will be supplying this information directly to the plugin when the song starts.  It makes perfect sense to me.

I am not even sure that is what you are proposing.  It is very hard to figure out what you mean.  I have no idea why the plugin would be requesting the jukebox software to "resubmit" a bunch of songs in order to get song information for one song.    :dunno


Quote
Juke_Command("JUKE_APP_OPENED","")
Juke_Command("JUKE_APP_CLOSED","")


yes, they does the same thing, and renamed to focus instead (for windowred based softtware).

I thought headkaze was indicating the "JUKE_APP_OPENED" should be replaced with calling the "Juke_Initialize()" function and the "JUKE_APP_CLOSED" command be replaced with calling the "Juke_Shudown()" function.   When I looked at your updated command list I saw they were removed (which I thought was fine), but then I noticed that "JUKE_APP_GAINFOCUS" and "JUKE_APP_LOSTFOCUS" were added but still have no idea why they are defined.  I am now very confused by your statement indicating "they do the same thing".

Now, are you saying that the "JUKE_APP_OPENED" command is the same as the "JUKE_APP_GAINFOCUS" command and the "JUKE_APP_CLOSED" command is the same as the "JUKE_APP_LOSTFOCUS" command?

If so, then I am very confused.

Just to make sure, GAINFOCUS means to me that the jukebox software window is the current working window in which the user has currently active.   LOSTFOCUS is when the indow no longer is the active window in the user's environment.   Is this correct?

Before you made this change, the "JUKE_APP_OPENED" command would be sent one time only when the jukebox started up and the "JUKE_APP_CLOSED" command would be sent one time only when the jukebox software shutdown.   

With these new commands, it seems like you want the jukebox software to send a "JUKE_APP_GAINFOCUS" everytime the jukebox window becomes the main active window in the user's environment and the "JUKE_APP_LOSTFOCUS" when the jukebox window is not the main active window in the user's environment ....is this correct?   if so, why is this important?

These commands suddenly showed up without discussing this with anyone ..... at least I id not see any discussion on this point.



Quote
MultiJuke does NOT use Playlist, but a user can select any songs from a PlayList to been played in WinAmp and jump both ways and some software might start from beginning again. Hence some might use that command.

What are you referring to here? 

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: Space Fractal on January 11, 2008, 02:14:30 pm
I got edited a post to answar the last one in the above post (sorry), hence not comment here.

I think we have 2 very different how to handle the queue (but I do have Added a Juke_Song_Info command to suit you need):

In MultiJuke, The first song in the queue is the current song. But its only the technical part i do did that. For me it was much easier to just delete the current played song when skipped or finished, and the next song is ready to play (I use a Linked List).

But to the user, it still show "NOW", "NEXT", 2 and so on.... Its that way it works In MultiJuke.

Even with the 1 song queue limit, The user still Add the song to the queue technical, because MultiJuke want to play the first song in the queue,  but the user do never notice that...



I do finally added that, but to the new command (but its the very the same), marked in red in the SDK:
"Juke_Song_Info"

It should suit your need, and have another twist to that: I also want to have Song Info for the first song in the queue. That why for the new command. If you dont need to the last one (Next Song), just skip that one.

 I also add that as new commands because I guess some might just listen to song commands without using queue or song info at all !!





maxAlbumNumDigitsRequired, etc... Could I not just add a new argument to these 2 digit commands to tell the max digit instead of a new command?

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: unclet on January 11, 2008, 03:42:51 pm
Quote
I got edited a post to answar the last one in the above post (sorry), hence not comment here.
Yes, I saw you have already responded so I then deleted it to move it to a new post I made.   Anyway, I moved my questions back into the original post now  :)


Quote
Juke_Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_NAME") {saw that before removed that}

It is totally up to the user to tell the plugin, what they should do with the commands, and what they are named to be of real use. That is why plugin configuration is absolutely required here.

I have wrote a test plugin to been using 2 of these command. It got all key_event trouch these commands and show them in the pulldown list. I save the list into a file, so they can reused next time.

When they some commands back, it allways one of them you created using JUKE_KEY_EVENT_CREATE before CONFIG. Can never been something other.

But again it up to the user to tell the plugin which commands that should been used.

Lets say the plugin application has some feature in it to control when the current playing song is to be paused (and resumed).   How would the plugin inform the jukebox software to pause (or resume) the currently playing song?

Based on what you are saying ....... the commands which the plugin can send to the jukebox software are "only" those commands created with the "JUKE_KEY_EVENT_CREATE" command when the jukebox first started.  If there were 50 commands created using the "JUKE_KEY_EVENT_CREATE" command, how would the plugin know which of these 50 commands to use to pause (or resume) a song?

You mentioned "it up to the user to tell the plugin which commands that should been used" ...... but I have no idea how this would be done unless I list all of the commands (in my own jukebox's SDK documentation) which will be created by my jukebox software using the "JUKE_KEY_EVENT_CREATE" command.   

If I need to list all of these commands in some sort of SDK documentation which is specific to my jukebox software, then I do not see the need to have the "JUKE_KEY_EVENT_CREATE" command at all since the plugin author can get the full command set from the SDK documentation and decide what to do with each command themselves.


Quote
JUST SOMETHING I WANT TO MENTION
Each plugin stores it's own configuration so everytime the jukebox software starts up from scratch there would be no reason to configure the plugin everytime, however, the "JUKE_KEY_EVENT_CREATE" commands will be sent to the plugin everytime the jukebox software starts up from scratch.   

I think this is fine, but I want to make sure you know it is possible the  "JUKE_KEY_EVENT_CREATE" commands will be sent to the plugin but a "Configure()" would not be called after the commands are sent.

Just wanted to let you know.



Quote
I think we have 2 very different how to handle the queue (but I do have Added a Juke_Song_Info command to suit you need):

In MultiJuke, The first song in the queue is the current song. But its only the technical part i do did that. For me it was much easier to just delete the current played song when skipped or finished, and the next song is ready to play (I use a Linked List).

But to the user, it still show "NOW", "NEXT", 2 and so on.... Its that way it works In MultiJuke.

Even with the 1 song queue limit, The user still Add the song to the queue technical, because MultiJuke want to play the first song in the queue,  but the user do never notice that...

Thank you for explaining how your song queue work. 

I still do not understand why you can not send a "JUKE_SONG_START" command with song information in it though.   

Why can't you add the song to the start of your linked list (position 1) and then immediately inform the plugin the song has been removed from the queue (even though it remains in your linked list), then inform the plugin the song has started.   

The following three events would be sent one after the other very quickly at the same point within your code.  You can send them all even though the song remains in your linked list.

1) JukeCommand("JUKE_SONGLIST_ADD_SONG", "1|1|etc|etc|etc|etc..")
     (inform plugin the song has been added to the queue at position 1)

2) JukeCommand("JUKE_SONGLIST_REMOVE_SONG", "1|1|etc|etc|etc|etc..")
     (inform plugin song has been removed from position 1 from the queue, even though it remains in your linked list internally)

3) JukeCommand("JUKE_SONG_START", "1|etc|etc|etc|etc...")
     (inform plugin the song has started.  This command represents the "NOW" song)

I would then recommend you define another command called "JUKE_SONG_NEXT" which can be sent as well to inform the plugin what song will be "NEXT"

For example:  JukeCommand("JUKE_SONG_NEXT", (song info))

My software has no concept of "telling" the user what song is NEXT since the user sees the complete song queue all the time, so my software would simply not send the "JUKE_SONG_NEXT" command at all, but your software would. 

So .......  the complete set of commands you would send to the plugin when a song is selected by the user and it is going to be played immediately would be:

   JUKE_SONGLIST_ADD_SONG  (added a song into your linked list at position 1)
   JUKE_SONGLIST_REMOVE_SONG (removed song from linked list from position 1)
   JUKE_SONG_START (indicate "NOW" song has started)
   JUKE_SONG_NEXT (indicate what "NEXT" song would be)

The complete set of commands you would send to the plugin when a song is selected by the user and it is going to be stored in the queue (linked list) and not played right away (since another song is currently playing) would be:

   JUKE_SONGLIST_ADD_SONG  (added a song into your linked list at a certain position)
 
The complete set of commands you would send to the plugin when the current song finishes playing and there is another song in the queue would be:

   JUKE_SONG_FINISH (indicate "NOW" song has finished)
   JUKE_SONGLIST_REMOVE_SONG  (remove "NEXT" song from queue
   JUKE_SONG_START (indicate "NOW" song has started)
   JUKE_SONG_NEXT (indicate what "NEXT" song would be)

So, using the "JUKE_SONG_START" command to represent the "NOW" song and defining the new "JUKE_SONG_NEXT" command to represent the "NEXT" song should work for you and me.    Do you agree?  If not, please explain why your software can not use this?



Quote
I do finally added that, but to the new command (but its the very the same), marked in red in the SDK:
"Juke_Song_Info"

It should suit your need, and have another twist to that: I also want to have Song Info for the first song in the queue. That why for the new command. If you dont need to the last one (Next Song), just skip that one.

 I also add that as new commands because I guess some might just listen to song commands without using queue or song info at all !!

Instead of defining the "JUKE_SONG_INFORMATION" command I would prefer to simply use the "JUKE_SONG_START" command (with song information) as the "NOW" song and use the "JUKE_SONG_NEXT" command (with song information) as the "NEXT" song.

(see my above example as to why I believe this should work for you in your software)


Quote
maxAlbumNumDigitsRequired, etc... Could I not just add a new argument to these 2 digit commands to tell the max digit instead of a new command?

No because the command "JUKE_ENTER_ALBUM_VALUE" only gets sent when the user enters a digit using my software directly.   If the user enters a digit by using the plugin application (instead of my jukebox software directly) and then the plugin sends my jukebox software a command informing it which "digit" was entered, then the "JUKE_ENTER_ALBUM_VALUE" was never sent "to" the plugin ever.  As a result, the plugin would never understand how many digits can be entered for the album number at all.   

Some plugins might send digits to the jukebox software one at a time, and then the jukebox software would be able to ignore any extra digits it receives.  However, other plugins might send all the entered digits to the jukebox software at one time, so those plugins would need to know the min/max number of digits allowed to be entered in which the jukebox would consider "valid". 

This is why I believe a command like the following would be needed and could be sent to the plugin one time when the jukeboxs first is started:

Juke_Command("JUKE_FIXED_VALUES",
"minVolumeLevel|maxVolumeLevel|minAlbumNumDigitsRequired|maxAlbumNumDigitsRequired| minTrackNumDigitsRequired|maxTrackNumDigitsRequired")






Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b3 Update !!)
Post by: headkaze on January 11, 2008, 04:32:21 pm
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.....

Okay I will create a new thread for the file.


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b4 Update !!)
Post by: Space Fractal on January 11, 2008, 04:42:10 pm
KEY_EVENT (EDITED MUCH UNEEDED TEXT AWAY):

I actually found a issue with JUKE_KEY_EVENT_GET while developing to the document only. It missing KeyDown, KeyUp and KeyChar to the returned string. Some plugins might only send KeyChar yet with no keyrepeat.

I hope it make sense these KEY_EVENT should act in your PollEvent commands. I hope you used commandnames as events and not hardcoded with Key Numbers. Hence you can use these commands in main rutine.



how would the plugin know which of these 50 commands to use to pause (or resume) a song?

The user tell it that using configuration. I Think only COIN_INSERT and other speciel stuff that ever need that. So No big deal.

If you still want a default set, I recommered to use the same key evenets a MCE (Microsoft Media Center Edition) remote controller normally use. These remote controls is allready been popular, so they can been used as default set (can find the api list, but it someware on MSDN).



Plugin is only typical only need them to show to a LCD or such, but normally never sent back again (unless you sent 10 digit EVENT to the CREATE commands), hence maxTrackNumDigitsRequired and maxAlbumNumDigitsRequired is only required throuch these 2 exiting commands to get a nice show on these device.

Othewice we can add that command if a Plug-In Writer ask about it and add them to v1.1, if they also ask. Most commands in the future should been defined by them, not by us. They might ask special things.

NB: I think I starting add these commands now to my software.
Commands cant been removed (brown commands unless), only add stuff.

So to other, it safe to add these allready shown commands, even we might add a few



In MultiJuke this code is all I need to feed that CREATE command:

Code: [Select]
For Local S:TControllers = EachIn Keys
TPlugins.Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_"+Upper$(s.sAction$))
Next

When sending and get events I plan to do directly after when the user pressed that key (PollEvent). So is might it pretty easy for me to use Key_Event without hardcodning....






____

HeadKaze: Please create a new thread, due to this long thread. I cant get the sound plugin I created to work with the host api. Mightbe you have few commands wrong? I do got it working throuvh the new wrapper I created to BlitzMax. I hope you can get it to work.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b5 Update !!)
Post by: unclet on January 11, 2008, 08:45:57 pm
Quote
Juke_Command("JUKE_SONG_START","system|NOW or NEXT|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
New song is just started.

Juke_Command("JUKE_SONG_NEXT","system|NOW or NEXT|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
Same as above, but just info about next song (1 song in queue).

Thank you for adding the song information in the JUKE_SONG_START and adding the JUKE_SONG_NEXT command.    :applaud:

Does this mean your jukebox can send the commands in the order I recommended?  I want to make sure we are both using the "JUKE_SONGLIST_xxxx" and "JUKE_SONG_xxxx" commands in the same way now.  Would you agree that we are using them in the same way?

A couple of things:

1) Why does the "JUKE_SONG_START" command have a "NOW" and "NEXT" indication.   I assumed the "JUKE_SONG_START" always represented the "NOW" song.  Why would the "JUKE_SONG_START" command ever be sent with a "NEXT" indication?

2) Why does the "JUKE_SONG_NEXT" command have a "NOW" and "NEXT" indication.   I assumed the "JUKE_SONG_NEXT" always represented the "NEXT" song.  Why would the "JUKE_SONG_NEXT" command ever be sent with a "NOW" indication?


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b5 Update !!)
Post by: Space Fractal on January 11, 2008, 08:57:08 pm
I haven't have any problems around JUKE_SONG_START, JUKE_SONG_NEXT. I just submit the first 2 songs, I have in my technical queue. First song is the currently play and second song is the first song in queue.

But I do recommered you to use Juke_Command("JUKE_SONGLIST_CURRENTPOSITION", "1|0") to make sure song number 0 is the current played song, not number 1 (like I use in MultiJuke), so the plugin use JUKE_SONG_START to checking its info. I tell that in the document in red.


I can then use Juke_Command("JUKE_SONGLIST_CURRENTPOSITION", "1|1") for my and other PLAYLIST like systems.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b6 Update !!)
Post by: Space Fractal on January 11, 2008, 09:13:36 pm
---- opps ---- trhouch I updated the first post ---
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b7 Update !!)
Post by: unclet on January 12, 2008, 08:38:16 am
Quote
Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")
Send a KEY_EVENT string back to the Jukebox software. The string would just get the KEY_EVENT command with a KeyDown, KeyUp or KeyChar arguments. Example: MOVE_DOWN|KeyDown

The "JUKE_KEY_EVENT_GET" shows the commandValue string to be NULL ("") above.

Will you please explain what the KeyDown, KeyUp and KeyChar arguments do and how they are delivered to the plugin?  Also are these extra commands from a standard defined set or does the jukebox software make them up?

Would you need KeyLeft and KeyRight defined as well for flipping through pages of album covers perhaps?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b7 Update !!)
Post by: Space Fractal on January 12, 2008, 08:49:11 am
should only return strings.... Just act like a keyboard, so no need to send a argument... The whole point.

KeyDown = When the user pressed a KEY_EVENT (user hold the button down)
KeyUp  = When the user released a Key (user hold the button down)
KeyChar = This string sendt only one and is (user invoked the button, pretty much KeyDown)

It just like most PollEvent() event generally works in Windows when you poll a key on your keyboard... Here it just send a command back when the user polled the command in its plugin.

So KeyLeft and KeyRight: No. All commands sent back to the software just like a keyboard.

Etc Plugin would return this when user pressed and hold the button:
   "KEY_EVENT_MOVELEFT|KeyDown"
   "KEY_EVENT_MOVELEFT|KeyChar"

When user release the button:
 "KEY_EVENT_MOVELEFT|KeyUp"

Many commans in the Jukebox Software might only require a KeyChar (Player commands example).

I need KeyDown and KeyUp due to Smooth Scrolling like a platform game in Jukebox GUI and many other things....



I have coded most commands to MultiJuke. But was doing system is in Juke_Command("JUKE_SONGLIST_REMOVE_SONG", "System|position")? It have no use, so i might remove that.

* Juke_Command("JUKE_SONG_LOOP","off|once|allways") is also missing.... (I guess you have that too, due to restart command).


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b7 Update !!)
Post by: unclet on January 12, 2008, 06:52:55 pm
1) Well I still have no idea how the plugin can determine which commands are for key presses, which commands should be used just to map sounds to, which commands should be mapped LED light actions, etc .....

Do not know how the plugin to determine what commands are what purpose ....... :dunno

I am missing something obviously  :banghead:

I can define 50 events using the "KEY_EVENT_CREATE" commands.  If 20 of those commands should be used by the plugin to map sounds to and 20 of those commands are required by the plugin to map to keyboard presses and the last 10 commands are used by LED light actions, then how in the world can the plugin tell which commands are to be used for these purposes.   All the plugin get in the "KEY_EVENT_CREATE" commands is a key event string value name ... that is it.  There are no instructions telling the plugin how to use these commands


2) Some Juke_Command() cmdValue strings have the "system" text included.  I remember you wanted a "0" to indicate the "user" and a "1" to indicate the "system".  Is this still correct, because it is not listed anywhere I can see (unless I missed it).

I do see you state that value being "USER", "RANDOM" or "SYSTEM" instead.  Is it true you want the "system" text to be one of these three text strings?  If so, then I do not understand the "RANDOM" string meaning.   I would think either the "user" or "system" can enter commands ..... nothing else .... so I am confused.

... so what does "system" mean?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b7 Update !!)
Post by: Space Fractal on January 12, 2008, 07:39:03 pm
I updated to beta 8, that should suit all you need.

I added a new command, since you diddent response to v7. I guess you have SONG LOOP too, since you have a SONG_RESTART command...

____

The rest I wrote here (which is deleted) is actulley now in the document and fixed (random status was a error). Also I used KEY_STATUS instead a new argument to tell which is status and which one is keypresses.

STATUS is just enable and disable status a EVENT can get.

Also KEY_EVENT and KEY_STATUS is now required to the name at beginning.

Please Note: it dosent bother me if status marked in brown is NOT being removed.



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b7 Update !!)
Post by: unclet on January 12, 2008, 08:59:45 pm

Quote
I added a new command, since you diddent response to v7. I guess you have SONG LOOP too, since you have a SONG_RESTART command...

In my software, when a song is currently playing, the user can click the "PLAY" button and the song will start over (ie: restart) from the beginning.  This is what I am using the "SONG_RESTART" command to indicate ..... when the song has restarted.

In my software, the user can activate the "REPEAT" option.  This means when the song has finished playing then the song gets placed back at the bottom of the queue so it will eventually play again.  My software does not allow a song to repeat continueously over and over again.   Anyway, I do not think I need to use the "SONG_LOOP" command, however, if you need it then thats fine with me.


Quote
Is it true you want the "system" text to be one of these text strings?


Ok, so "RANDOM" was removed ... fine.    However, do you expect the "system" variable to be a "USER" or "SYSTEM" text string ..... or do you expect them to be a "0" or "1" string?

If you want me to use "USER" or "SYSTEM" text strings, then I would suggest you change the "system" variable name to something else.   IF you want me to use "0" or "1" text strings, then the current "system" variable name is fine.


Quote
The rest I wrote here (which is deleted) is actulley now in the document and fixed (random status was a error). Also I used KEY_STATUS instead a new argument to tell which is status and which one is keypresses.

STATUS is just enable and disable status a EVENT can get.

Also KEY_EVENT and KEY_STATUS is now required to the name at beginning.
I agree the keyEvents which were create via the "JUKE_KEY_EVENT_CREATE" commands should have standard prefixes.   However, I still do not understand exactly how a plugin should tell the jukebox software to PAUSE the current playing song.  Will you please show me the command sequence which will be sent from the jukebox software and the plugin to do this?


Quote
Please Note: it dosent bother me if status marked in brown is NOT being removed.

It is fine with me if you want to remove the "system" variable form "SONGLIST_REMOVE_SONG", "SONGLIST_MOVE_SONG", "SONGLIST_CLEAR" and "SONGLIST_CURRENTPOSITION" commands.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b8 !!)
Post by: Space Fractal on January 12, 2008, 09:25:55 pm
REPEAT: Added some text to the command, since it can been misforstod like a loop command. I have no repeat command in my software, but I might add that. Elsewice good idea, also for MultiJuke as well.

PAUSE:  The user configure the plug-in about that, same as COIN_INSERT. Plugins can also try searching using Instr() or such to trying the guess in a part of the string like PAUSE. If it can't find it, it require the user tell which command it is on the configuration screen.

KEY_EVENT: I tried to explain returned string better with JUKE_KEY_EVENT_GET, and why it dosent have a argument.

If you want, I could add a argument for polling the currecnt event and send back a 0 and 1. but that might lost some perfectment if the plugin need to parce all event commands in every loop when you doing that. But I can add that anyway, so both methods can been used?



The acttract mode should been better explain what it really does.

For the system: 0 and 1



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b8 !!)
Post by: unclet on January 12, 2008, 11:41:57 pm
Quote
REPEAT: Added some text to the command, since it can been misforstod like a loop command. I have no repeat command in my software, but I might add that. Elsewice good idea, also for MultiJuke as well.

What command did you add text to?  I do not know what you mean since I see no change when I looked in any command.


Quote
PAUSE:  The user configure the plug-in about that, same as COIN_INSERT. Plugins can also try searching using Instr() or such to trying the guess in a part of the string like PAUSE. If it can't find it, it require the user tell which command it is on the configuration screen.

Ok, I might understand ..... please confirm.   

If I send the following command to the plugin....

Juke_Command("JUKE_KEY_EVENT_CREATE", "KEY_EVENT_PAUSE_SONG")

.... then I can go into the plugin's configuration window and indicate the "KEY_EVENT_PAUSE_SONG" event should be the event the plugin sends back to the jukebox software to inform the jukebox software the song has been paused.  In order to get this event sent from the plugin I would use the "KEY_EVENT_GET" routine (which I am sending every 200ms).   Once I have the "KEY_EVENT_PAUSE_SONG" event from the plugin then I can pause the song as requested.

Is this correct?


Quote
Juke_Command("JUKE_KEY_EVENT_CREATE","KEY_EVENT_NAME or KEY_STATUS_NAME")

Juke_Command("JUKE_KEY_EVENT_SEND", "KEY_EVENT or KEY_STATUS|ENABLE or DISABLE")

Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")


Since we have KEY events and STATUS events I do not think these commands should have "KEY" in them.  I propose to renaming these three commands to the following:

Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "KEY_EVENT_(name) OR STATUS_EVENT_(name)")
create an event which can be sent by the plugin to the jukebox application

"KEY_EVENT_(name)" events refer to actual keyboard event actions the plugin can send to the jukebox software (ex: "KEY_EVENT_MOUSEDOWN")

"STATUS_EVENT_(name)" events refer to any status update the plugin can send to the jukebox software. (ex: STATUS_EVENT_PAUSE_SONG)

The plugin can look for the prefix "KEY_EVENT" or "STATUS_EVENT" to determine how to categorize these events correctly in it's configuration routine.


Juke_Command("JUKE_PLUGIN_EVENT_SEND", "KEY_EVENT_(name) OR STATUS_EVENT_(name)|ENABLE or DISABLE")
send a previously created(defined) key event or status event to the plugin


Event$=Juke_Command("JUKE_PLUGIN_EVENT_GET", "")
get a previously created(defined) key event or status event from the plugin


Quote
The attract mode should been better explain what it really does.

Juke_Command("JUKE_FEATURE_ATTRACT_MODE", "onActive/onNotActive/Off")
Instead of having a quiet/idle jukebox with no songs playing, some jukebox applications will try to attract users to the jukebox machine hoping for them to request a song to start playing.  Attract modes could include LED light displays, automatic page flipping of available artists/albums, generating sounds to lure users closer to the machine, etc...    This command will indicate the state of the attract mode feature offer by the jukebox.

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 (or does not exist)


Quote
For the system: 0 and 1
Excellent .... I will use 0 and 1 .

Also, I see you removed the "system" text from the "SONGLIST_MOVE_SONG" command, but you did NOT remove it from the "SONGLIST_REMOVE_SONG", "SONGLIST_CLEAR" and "SONGLIST_CURRENTPOSITION" commands.  I guess this means you want to keep the "system" text for those commands?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b9 !!)
Post by: loadman on January 13, 2008, 12:14:51 am
Space Fractal :

A question in simple terms:

As a plug-in creator I want to send a message to the JukeBox
1) Pause
2) Play or Un pause
2) Vol Up
3) Vol Down

Call me stupid but I just not understand what is required???

Is it Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")

Please give an example of how I would do to achieve Items 1-4.  Thank You. ;D
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b9 !!)
Post by: headkaze on January 13, 2008, 12:24:09 am
Space Fractal :

A question in simple terms:

As a plug-in creator I want to send a message to the JukeBox
1) Pause
2) Play or Un pause
2) Vol Up
3) Vol Down

Call me stupid but I just not understand what is required???

Is it Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")

Please give an example of how I would do to achieve Items 1-4.  Thank You. ;D

AFAIK

1) JUKE_SONG_PAUSE
2) JUKE_SONG_START / JUKE_SONG_RESUME
3) JUKE_VOLUME_SET
4) JUKE_VOLUME_SET
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b9 !!)
Post by: loadman on January 13, 2008, 01:51:46 am
Space Fractal :

A question in simple terms:

As a plug-in creator I want to send a message to the JukeBox
1) Pause
2) Play or Un pause
2) Vol Up
3) Vol Down

Call me stupid but I just not understand what is required???

Is it Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")

Please give an example of how I would do to achieve Items 1-4.  Thank You. ;D

AFAIK

1) JUKE_SONG_PAUSE
2) JUKE_SONG_START / JUKE_SONG_RESUME
3) JUKE_VOLUME_SET
4) JUKE_VOLUME_SET


Thanks.

The reason I directed the question at Space was I wondered if it was true that only commands which could be sent back were the ones originally defined by the Juke_Command("JUKE_KEY_EVENT_CREATE", xxxxx) command  ????  I hope Not  ???

Please advise
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b9 !!)
Post by: headkaze on January 13, 2008, 03:16:16 am
Space Fractal :

A question in simple terms:

As a plug-in creator I want to send a message to the JukeBox
1) Pause
2) Play or Un pause
2) Vol Up
3) Vol Down

Call me stupid but I just not understand what is required???

Is it Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")

Please give an example of how I would do to achieve Items 1-4.  Thank You. ;D

AFAIK

1) JUKE_SONG_PAUSE
2) JUKE_SONG_START / JUKE_SONG_RESUME
3) JUKE_VOLUME_SET
4) JUKE_VOLUME_SET


Thanks.

The reason I directed the question at Space was I wondered if it was true that only commands which could be sent back were the ones originally defined by the Juke_Command("JUKE_KEY_EVENT_CREATE", xxxxx) command  ????  I hope Not  ???

Please advise

Why would a plugin want to do things like turn up/down the volume, start, stop or pause a song? Those are the things a plugin can respond to why would it need to control that?

In any case to cover this problem the JUKE_KEY_EVENT_CREATE should IMHO be a more generic command like JUKE_PLUGIN_EVENT where you can send back any command. That way if there ever was a need to do that then the one command that is in a Timer to check for arbituary commands from the plugin can be processed.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b9 !!)
Post by: loadman on January 13, 2008, 04:21:43 am

Why would a plugin want to do things like turn up/down the volume, start, stop or pause a song? Those are the things a plugin can respond to why would it need to control that?


When the phone rings,
When you launch game on MaLa,
When the bad neighbour get home :-)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b10 !!)
Post by: Space Fractal on January 13, 2008, 05:52:33 am
LoadMan:
Just updated the document to suit your need under returned commands around VOLUME (you right). Can also been a value now for the volume event (either through VOLUME_UP, VOLUME_DOWN or similar).

UncleT:
I prefer KEY_EVENT_(name) OR STATUS_EVENT_(name) as prefix. Not using the word JUKE here, that should only used by commands strings it self.


Juke_Command("JUKE_SONG_RESTART",""):
Current song has been restarted and moved back to the queue. I forget to mark that red.

PARTY_LOOP:
This should been explained better to the document..... The same goes for GENRE_LOCK (I do that soon).

SONG LOOP:
Otherwise I have added a Repeat to the SONG_LOOP command, if the user have enabled the REPEAT function. So you should use SONG_LOOP command as well (but only for the REPEAT argument, not ONCE or ALLWAYS).

JUKE_SONGLIST_CURRENTPOSITION:
I changed the text a bit so both queue methods can been used. I hope you understand that, so both queue methods can been used.

I just updated it to v1b10 suitable for these comment I got. My Sound Plugin is updated to these change

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b10 !!)
Post by: unclet on January 13, 2008, 08:56:09 am
Quote
LoadMan:
A question in simple terms:

As a plug-in creator I want to send a message to the JukeBox
1) Pause
2) Play or Un pause
2) Vol Up
3) Vol Down

Call me stupid but I just not understand what is required???

Is it Event$=Juke_Command("JUKE_KEY_EVENT_GET", "")

Please give an example of how I would do to achieve Items 1-4.

I think I figured this out ..... here is the sequence of commands which should be required (please note the keyEvent commands have been renamed):

1) My jukebox software creates(defines) the following commands when it starts:

Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "STATUS_EVENT_SONG_PAUSE")
Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "STATUS_EVENT_SONG_RESUME")
Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "STATUS_EVENT_SONG_VOLUME_CHANGE|number")

2) My jukebox software would then keep sending the following command until I get a valid non-null string value returned (which was created using the "JUKE_PLUGIN_EVENT_CREATE" commands originally):

Event$ = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

3) The user would open your configuration plugin screen where they can associate (ie: map) certain functions to certain events.   For example, the user would map the "STATUS_EVENT_SONG_PAUSE" event to the "Pause song" function.

4) When your application decides it wants to pause the song, then your plugin would look up the "Pause soing" function to determine which event is mapped to it.  Your plugin would then return the "STATUS_EVENT_SONG_PAUSE" event string to my software by sending it as the return value of the next occuring "JUKE_PLUGIN_EVENT_GET" command request.

5) My software will then determine which STATUS_EVENT_(name) event was returned by the plugin and take appropriate action


Note: Based on the current standard, the STATUS_EVENT_(name) events can have a number value associated with them if some events need one (ex: "STATUS_EVENT_VOLUME_CHANGE|45")


Quote

Space Fractal requests.....
1) Can we rename "JUKE_VOLUME_SET" to "JUKE_VOLUME_CHANGE" please?

2) Under the "JUKE_PLUGIN_EVENT_SEND" event "examples":

a) I would explain what MOVEDOWN means by adding some more text to the event.  For example .... change "KEY_EVENT_MOVEDOWN" to "KEY_EVENT_SONGLISTBOX_MOVEDOWN"

b)  please change  "KEY_STATUS_LIGHTACTION|ENABLE" to "STATUS_EVENT_LIGHTACTION|ENABLE"


Quote
Juke_Command("JUKE_SONG_RESTART",""):
Current song has been restarted and moved back to the queue. I forget to mark that red.
The "moved back to the queue" text does not apply to my jukebox.   The currently playing song (which has already been removed from the queue so it can be played) is simply started over from the beginning so the song can start again.   It ha nothing to do with a queue for my software.   

I would recommend removing the "moved back to the queue" text.


Quote
PARTY_LOCK:
This should been explained better to the document.....
Juke_Command("JUKE_FEATURE_PARTY_LOCK", TRUE or FALSE)
Jukebox applications offer many unique configuration options and feature to allow the owner of the jukebox software to set up the application exactly how they prefer.   When party guests (ie: or customers) use the owner's jukebox, the owner would like to ensure none of their configuration options are altered by the party guests.  As a result some jukebox applications offer a "Party Lock" feature which allows the jukebox owner to password protect their configuration from changing.  This command will indicate whether the party lock feature offer by the jukebox is enabled/disabled.

Quote
The same goes for GENRE_LOCK.
Yes, you can supply a description for this one since I do not use this command

Quote
SONG LOOP:
Otherwise I have added a Repeat to the SONG_LOOP command, if the user have enabled the REPEAT function. So you should use SONG_LOOP command as well (but only for the REPEAT argument, not ONCE or ALWAYS).

Are you saying the "JUKE_SONG_LOOP" command is to indicate the "repeat" option offer by the jukebox is enabled or disabled?  If so then I would recommend renaming the "JUKE_SONG_LOOP" command to be "JUKE_SONG_REPEAT" like the following:

Juke_Command("JUKE_SONG_REPEAT","onOnce/onAlways/off")

Quote
JUKE_SONGLIST_CURRENTPOSITION:
I changed the text a bit so both queue methods can been used. I hope you understand that, so both queue methods can been used.

Well I still do not understand why I should use this command. 

When a song is selected in my software and placed in the queue, the following commands will be sent:

JUKE_SONGLIST_ADD_SONG <-- This will indicate the position in the queue

When the current song finishes and the next song is going to play, the following commands will be sent:

JUKE_SONG_FINISH
JUKE_SONGLIST_REMOVE_SONG
JUKE_SONG_START


Since my software uses a "song queue", then I use the "SONGLIST_ADD_SONG" commands to inform the plugin what position the song has been inserted into the queue.

Where do you think I should use the "SONGLIST_CURRENTPOSITION" command?





Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b10 !!)
Post by: Space Fractal on January 13, 2008, 10:42:13 am
sorry for another edit:

Volume: Why not just JUKE_VOLUME? Personly I can leave at is are, because it fine destripted as it are, even it used SET or CHANGE....


Juke_Command("JUKE_SONG_RESTART",""):
This command is no use anymore, because I just added JUKE_SONG_REPEAT as you recommered. When the song is restarted, you can simply change a new status to the REPEAT instead.

I throuch the played song is pulled back to the last in the queue? If it still does, this command is still in place on the SDK. Hence I not removed it, but it need a better explain.

JUKE_FEATURE_PARTY_LOCK:
Completly wrong named command, if you ask me and can been easy misforstood by other authors. That one should been renamed to JUKE_FEATURE_CONFIG_LOCK to make more general use.

SONGLIST_CURRENTPOSITION[0]:
This make sure First song in the SONGLIST and SONG_START dosen't show the same songinfo. You can define that in your startup.

LOG:
Do you have some command logging feature to commands sendt to a log file? Please create that feature. Might been useful for Plugin Writers.... Or create a plugin for logging commands.




I are naerly finish to add Plugin Support to MultiJuke using Beta 11 document.

I just missing one command (JUKE_PLUGIN_EVENT_GET) and get 16 bit unicode strings converted to UTF8 (I have the other way allready) for ADD_SONG, SONG_START and SONG_NEXT commands (unicode have no use on all other). I might not support all commands.

I also JUKE_FEATURE_CONFIG_LOCK instead of JUKE_FEATURE_PARTY_LOCK for the same feature. I fell CONFIG is better to use that?


Hence I might wont change the SDK so often, so I dosent need to find the changed commands again (so I leave VOLUME_SET, since I allready used as it are).

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b10 !!)
Post by: unclet on January 13, 2008, 12:43:42 pm
Quote
STATUS_EVENT_SONG_PAUSE on your startup...... Should you not rename that as KEY_EVENT_SONG_PAUSE, since it not a light action?

I do not consider "STATUS_EVENT_(name)" events to be specific to just light actions.  I do not know why you are assuming that.   The difference between "KEY_EVENT_(name)" and "STATUS_EVENT_(name)" are the following (which is exactly stated in your first post in the thread):

"KEY_EVENT_(name)" events  = refer to actual keyboard event actions the plugin can send to the jukebox software (ex: "KEY_EVENT_MOUSEDOWN")

"STATUS_EVENT_(name)" events = refer to any status update the plugin can send to the jukebox software. (ex: STATUS_EVENT_PAUSE_SONG)

The way loadman would like to use the pause event is not be pressing a pause key on the keyboard but instead when he decides to start a Mame video game (while the jukebox is running) then his application will send a PAUSE event to my jukebox to pause the song.   It has nothing to do with keyboard input at all.

If you want specific events to be used for especially for LIGHTs then I suggest you add one more event called "LIGHT_EVENT_(name)".

Now, a problem with this naming convention is if we need to define these two commands:

KEY_EVENT_PAUSE = this event is sent because the pause key on the keyboard was pressed

STATUS_EVENT_PAUSE = this event is sent because an application decided to pause the jukebox by itself, without the user pressing a pause key of any kind.

Not sure we should be defining both of these commands, but if we want to have standard prefix text for each command, then they both should be defined.

I think my problem is that I do not fully understand exactly what all your "MOVEDOWN" and "MOUSEUP" event stuff is doing.   I thought you originally wanted a way for the plugin to be able to determine which events were for sounds, which events were for llights, etc.... so the plugin could populate their drop-down combo box (or listbox) with the appropriate commands.


Why not simply define the following (with one event name standard only):

Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)")

Then the plugin can simply list ALL created events in one BIG list and the user (during plugin configuration) can simply indicate which event shoulkd be used for what purpose.  Basically, the user can assign sounds to certain events, light handling to certain events, map certain events to functions (like loadman wants), etc....

It would now also be possible to assign multiple functions to the same event.  Lets say loadman wants to send the PAUSE event to the jukebox software when someone presses a pause key in his application but he also wants to send a PAUSE event to the jukebox software when his Arcade FrontEnd starts a video game (ie: no keyboard or button press occurring).   I can define one command called "PLUGIN_EVENT_PAUSE" and in loadman's plugin configuration screen I can assign the "PLUGIN_EVENT_PAUSE" to "two" separate functions (ie: "pressing pause key" and "starting a Mame video game").

I would prefer to simply have all events created as "PLUGIN_EVENT_(name)" only.

This seems like a better approach and also a lot easier.  Again, I like the idea of the plugin ONLY being able to send commands back to the jukebox software which were previously created by the "JUKE_PLUGIN_EVENT_CREATE" command only.


Quote
You dosent need to tell status about PAUSE and RESUME, since there already is commands about it: JUKE_SONG_PAUSE and JUKE_SONG_RESUME.

I believe you have been telling me that the ONLY commands a plugin can send to the jukebox software were the ones created by "JUKE_PLUGIN_EVENT_CREATE".   Since the "JUKE_SONG_PAUSE" and "JUKE_SONG_RESUME" commands are NOT created by the "JUKE_PLUGIN_EVENT_CREATE" command then they can not be sent by the plugin. 

I kind of like this rule since it separates exactly what a plugin can send to the software.  All of the events which start with "JUKE_xxxx" are sent from the jukebox.   All other events created by the "JUKE_PLUGIN_EVENT_CREATE" commands are sent by the plugin.


Quote
Volume, you should use this on your init:
Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "STATUS_EVENT_SONG_VOLUME_CHANGE")
JUKE_VOLUME_SET(system|number|minvolume|maxvolume)

I agree ... no big deal.


Quote
That is why I used the term SET. I dosen't like the word CHANGE to the VOLUME_SET, but good as a STATUS EVENT (added to the document to use numbers as well). Now the VOLUME_SET is now normally only need once and cant see why I should rename that.

I do not know why you think "JUKE_VOLUME_SET" is only called one time.   I call it everytime the volume changes on my jukebox.  This is why I wanted the name to be called "JUKE_VOLUME_CHANGE" since is represents the event sent everytime the volume has "changed". 

The volume level does not only change as a result of the plugin telling the jukebox to change the volume level ..... the jukebox can change the volume level itself and must tell the plugin about the change.   

As a result, I still think you should change the "JUKE_VOLUME_SET" to "JUKE_VOLUME_CHANGE".


Quote
Juke_Command("JUKE_SONG_RESTART",""):
This command is no use anymore, because I just added JUKE_SONG_REPEAT as you recommered. When the song is restarted, you can simply change a new status to the REPEAT instead.
I recommended you should add a "JUKE_SONG_REPEAT" command if you wanted to be able to tell the plugin when the "repeat" feature was turned on or off in the jukebox.  When my "repeat feature" is on, then after the current playing song finishes it will be placed at the end of the song queue automatically.  This is what "repeat" means to me.  It does not mean the song has "restarted" playing again.

I never recommended removing the "JUKE_SONG_RESTART" command.  DO NOT remove the "JUKE_SONG_RESTART" command.

Here is how I am using these commands:

JUKE_SONG_RESTART = when there is a currently playing song and the user requests the song to restart from the beginning immediately.  Basically, the user will hear the song start over right away.

JUKE_SONG_REPEAT =  when the "repeat" feature is turned on, then when the current playing song finishes it will be placed at the end of the song queue automatically.  Basically, the user will hear the song play again once all other songs already in the song queue are played first.

Quote
I throuch the played song is pulled back to the last in the queue? If it still does, this command is still in place on the SDK. Hence I not removed it, but it need a better explain.
yes .... so please do not remove this command.  Please see my above explanation as to how I am going to use the "JUKE_SONG_RESTART" and "JUKE_SONG_REPEAT" commands.

Quote
JUKE_FEATURE_PARTY_LOCK:
Completly wrong named command, if you ask me and can been easy misforstood by other authors. That one should been renamed to JUKE_FEATURE_CONFIG_LOCK to make more general use.
Renaming this command to the following is fine with me .....

Juke_Command("JUKE_FEATURE_CONFIG_LOCK", "TRUE or FALSE")
All COnfiguration is locked or hidden, so the user only can select songs.

.... but the description should be changed to the following:

Juke_Command("JUKE_FEATURE_CONFIG_LOCK", "TRUE or FALSE")
The jukebox owner can set aspects of the software to be hidden/disabled from the jukebox user.  When the jukebox owner activates their configuration lock feature, then these setting become enabled, thus "locking out" the jukebox user from using certain functions.


Quote
SONGLIST_CURRENTPOSITION[0]:
This make sure First song in the SONGLIST and SONG_START dosen't show the same songinfo. You can define that in your startup.
This is exactly why I think this command is NOT needed at all.

The SONG_START command has song information in it to inform the plugin about the "NOW" song (ie: the song which is currently playing).   The "SONG_NEXT" commands has song information in it to inform the plugin about the "NEXT" song (next song from the songlist which will play).

In your software I think you would be sending a "SONG_START" for the "NOW" song (even though it is still in your queue at the first position) since it is the currently playing song.    Then you would send a "SONG_NEXT" command for the "NEXT" song to indicate the "next" song in your linked list.  As aresult, I have no idea why you are adding this "SONGLIST_CURRENTPOSITION" command. 

I have no plans on using this command since all current and next song information can be sent to the plugin using "SONG_START" and "SONG_NEXT" only.

Quote
LOG:
Do you have some command logging feature to commands sendt to a log file? Please create that feature. Might been useful for Plugin Writers.
Yes, there is a logging feature internal to my application.  I do not really use it alot since my jukebox never crashed or has problems  :P
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b11 !!)
Post by: Space Fractal on January 13, 2008, 01:22:40 pm
KeyEvent Status:

I think the plugin could sent back a KEY_EVENT, even it did that automatic by the plugin or by user Keypresses. How the Keypress is sendt back to Jukebox by the plugin dosen't care me, since the Jukebox Software never can see why the plugin want it..... It something like the AutoHotKey application, if you have hear that....

It just doing that anyway, regaardles it auto or by user.

But if you which to use both STATUS and KEYEVENT with Pause, that is of course fine. It's possible, and the plugin can send a VOLUME back with a number now using STATUS as well (as LoadMan requsted).




 :banghead:

JUKE_SONG_RESTART = when there is a currently playing song and the user requests the song to restart from the beginning immediately.  Basically, the user will hear the song start over right away.

That was the JUKE_SONG_LOOP command I removed, but the command name using RESTART is fine, but I also added onOnce and onAllways here (Restart once), and should been marked by the user, not when song end (only from ONCE to OFF). Hence I added these arguments.

For repeart, onOnce is not neeed?



SONGLIST_CURRENTPOSITION[0]:
On the winamp screenshot I marked the song at number 12 in its playlists and now playing. Hence this argument is number 12.

In your software I assume you have the first song it its winamp queue would act like SONG_NEXT (Mine would been SONG_NOW)?

If yes, SONGLIST_CURRENTPOSITION[0] just make sure the Plugin does NOT checking the SONG LIST like wimap for the SONG_START command (ETC song number 0 is the SONG_START info).

This command is only in use by the plugin if the plugin do manage the queue.

This make sure plugins can use both queue and playlist systems.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b11 !!)
Post by: unclet on January 13, 2008, 03:12:46 pm
Quote
KeyEvent Status: You are right here.
I am right about what?  Perhaps you please explain this statement a bit more?


Quote
I do added the possible to use numbers to all commands (like you would do when sending the volume as a STATUS event), like you did in the previous post.
I am getting to really dislike the fact that I do not fully understand the use the JUKE_PLUGIN_EVENT commands and I am getting tired of not getting a full example of "exactly" what should happen.  By the term example, I mean it would be nice if you simply presented a step by step description of exactly how a plugin should be updated with commands.   I am tired of writing multiple posts in this thread to discuss this topic I fully do not understand.  I am sorry, but no one has presented a true example of how all of these commands should work together.

Unless someone can provide "exactly" a step by step description of how I should use the existing defined commands, by providing a true example then I will just use the following definitions for my software and be done with it since I am spending way too much time writing text in this post.  :dunno

This is how I prefer to do this (perhaps you will use this format instead):

Define the following commands:

Juke_Command("JUKE_PLUGIN_EVENT_CREATE",
                               "PLUGIN_EVENT_(name)|ENABLE/DISABLE|NUMBER|numOfKeyEvents|keyEvent1|keyEvent2|...|keyEventX")

This command will create(define) a jukebox-specific event (which is only applicable in my jukebox software) which is allowed to be "sent from the jukebox to the plugin" OR "sent from the plugin to the jukebox".

This command will also create(define) the type of data which the "jukebox can send to the plugin" OR which the "plugin may return to the jukebox".

where:

ENABLE/DISABLE = When the "ENABLE" or "DISABLE" string values are supplied, we are telling the plugin that it can return the ENABLE or DISABLE text strings back to the jukebox software.  This way the jukebox software can enable or disable something related to the event the plugin has sent (ex: GUI setting, feature setting, etc..).

NUMBER =  When the "NUMBER" string value is upplied, we are telling the plugin that it can return an integer number value back to the jukebox software.  Thsi way the jukebox software can set a value to the number provided (ex: setting a value like volume level, etc..).

numOfKeyEvents = how many keyEvents will be supplied.  This is required in case this the CREATE command is ever expanded, then extra parameters can be appended to the end.

keyEvent = one of the following text values to describe the state of a keyboard key:

KEYDOWN
KEYUP
KEYCLICK



Juke_Command("JUKE_PLUGIN_EVENT_SEND",
                              "eventName|ENABLE/DISABLE|(number)|keyEvent")

Sends a previously defined jukebox-specific command to the plugin

where:

eventName = Event defined by "JUKE_PLUGIN_EVENT_CREATE" command ONLY

ENABLE/DISABLE = When the jukebox wants to inform the plugin to ENABLE/DISABLE something

number =  When the jukebox wants to provide a specific number to the plugin for something.

keyEvent = one of the following text values to describe the state of a keyboard key:

KEYDOWN
KEYUP
KEYCLICK


retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")
Receives a previously defined jukebox-specific command from the plugin

where:   retValStr = a String in the following format

               "PLUGIN_EVENT_(name)|ENABLE/DISABLE|number|KeyEvent"



EXAMPLES:

Allowing the plugin to change the volume level to 50:

1) Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_VOLUME|||3|KEYDOWN|KEYUP|KEYCLICK")

2) retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

where retValStr = "PLUGIN_EVENT_VOLUME||50|0"


Allowing the plugin to indicate the volume button is pressed down:

1) Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_VOLUME|||3|KEYDOWN|KEYUP|KEYCLICK")

2) retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

where retValStr = "PLUGIN_EVENT_VOLUME|||1|KEYDOWN"


Allowing the plugin to indicate the volume button is no longer pressed:

1) Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_VOLUME|||3|KEYDOWN|KEYUP|KEYCLICK")

2) retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

where retValStr = "PLUGIN_EVENT_VOLUME|||1|KEYUP"


Quote
In MultiJuke it seen, I diddent need to sendt ACTIONBUTTONS as KEY_EVENTS since it was not required, but is instead using these commands as STATUS_EVENT.
I have concluded I simply do not "fully" understand how you are using these events so I have decided to define my own set of commands which I will support (see above).   They have similiar information to the previous commands you defined, but I understand by format much better. 

Quote
JUKE_SONG_RESTART = when there is a currently playing song and the user requests the song to restart from the beginning immediately.  Basically, the user will hear the song start over right away.

That was the JUKE_SONG_LOOP command I removed, but the command name using RESTART is fine, but I also added onOnce and onAllways here (Restart once), and should been marked by the user, not when song end (only from ONCE to OFF). Hence I added these arguments.

Based on your description of the SONG_RESTART command I am not sure you understand how I use the SONG_RESTART command.

Juke_Command("JUKE_SONG_RESTART","onOnce OR onAlways OR off")
When the song is played finished, and is marked by the user, the song would restart from the beginning immediately.

I can restart a song without it finishing first and it does not have to be "marked" by the user in any way.. 

For example
On my software I have "PLAY",  "PAUSE", "FASTFWD", "FASTREV" and "SKIP" buttons. 

Lets say the user selects a song and that song starts to play.   Lets say this currently playing song is 120 seconds long.   After the song has been playing for 50 seconds only the user can click the "PLAY" button which will RESTART the same song from the beginning again.  If the user does not enter anything else, then the song will complete and finish and the next song from the queue will then be retrieved and played.

In my example, the song was restarted before the song has finished and also the user did not have to "mark" the song for any reason to indicate it should be restarted ,they simply pressed the "PLAY" key again.

Basically, I would send the following command all the time:

   Juke_Command("JUKE_SONG_RESTART","")

I do not understand why you need to inform the plugin about "onOnce, onAlways or off" values at all. 

As a result, I really do not like the following description text you use since my software does not have to wait for the song to finish before it can be restarted also the song does not have to be "marked" in order for it to restart:

   "When the song is played finished, and is marked by the user,"



Quote
For SONG_REPEAT, onOnce is not needed?
Correct, you can remove "onOnce" ....   :)


Quote
SONGLIST_CURRENTPOSITION[0]:
On the winamp screenshot I marked the song at number 12 in its playlists and now playing. Hence this argument is number 12.

In your software I assume you have the first song it its winamp queue would act like SONG_NEXT (Mine would been SONG_NOW)?

If yes, SONGLIST_CURRENTPOSITION[0] just make sure the Plugin does NOT checking the SONG LIST like wimap for the SONG_START command (ETC song number 0 is the SONG_START info).

This command is only in use by the plugin if the plugin do manage the queue.

This make sure plugins can use both queue and playlist systems.

You keep mentioning WinAmp .... which I have never used, so I simply do not understand why you need this command.  I tried to provide at least two separate examples of why I think the "SONGLIST_CURRENTPOSITION" commands is not needed but I guess you think it is still needed.  Keep it if you want, but I do not see a need for it at all so I will not be using it at all.  I am just going to use the "SONG_START" command to indicate the currently playing song and the "SONG_NEXT" command to indicate which song is going to play next.

The "SONG_START" command simply indicates the current playing song no matter if that song is currently located in a playlist, song queue or linked list  ..... it just does not matter.  It simply tells the plugin about the song "which is currently playing" ....  thats it.

The "SONG_NEXT" command simply indicates the next song which will be played no matter if that song is currently located in a playlist, song queue or linked list  ..... it just does not matter.  It simply tells the plugin about the song "which is going to play next" ....  thats it.

Anyway, keep the "SONGLIST_CURRENTPOSITION" command if you want, but I do not see a need for it at all so I will not be using it at all.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: Space Fractal on January 13, 2008, 04:12:17 pm
There are various software out here and work diffecent.

Winamp:
IT seen it hard to explain when never use a comon software like this to test out.... The command is really suited to this type of software, if they want to add plugin support where the user can jump throuch songlist back and front, even the song is not played finished.

SONGLIST_CURRENTPOSITION have No real use Jukebox software like your and mine. I only wrote that due to the little difference about your and mine queue system. That all, but let see what happens.

The only problem might accour, but I guess we should wait it happens when a real developed plugin use the SONGLIST system.... More can I not say about it. THEN we can correct some issues.



Juke_Command("JUKE_PLUGIN_EVENT_CREATE",
                               "PLUGIN_EVENT_(name)|boolean ENABLE/DISABLE|boolean NUMBER |numOfKeyEvents|keyEvent1|keyEvent2|...|keyEventX")

only require to set these boolean text to been TRUE and FALSE. Otherwice it fully accepeted, so I copy the whole text in at it are and good idea.



That can been a very much problem when we have functions that might varierer from software to software. RESTART is one of them.

A Plugin can detect when a song restarted middle from the current song without SONG_RESTART: It just checking the song position (currentSecs have been resetted).

Only real use is some output text to the user about RESTART have ben accour.... I do leave this command as original state now.


The repeat and loop is the major problem, because mine is song based, your is queue based.

Mightbe remove JUKE_SONG_REPEAT COMMAND, and the AUTOPLAY at all?

Then Instead use JUKE_SONG_MODE(mode) to cover both?

Here it can tell what it happens to this song and just show the text to the user. It can example been "Radio mode", "Random Mode", "Loop mode", "Repeat Mode" or any other mode that is suitable to the software?


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: headkaze on January 13, 2008, 05:17:54 pm
I got an idea, how about UncleT list all the commands he wants to have in the plugin system, then we match the common ones with Space Fractals list and then make one final list of commands.

I think the commands are confusing. I think the descriptions of the commands are confusing. How the hell is a plugin author supposed to understand them?

I think Space Fractal is designing the system around his Jukebox software too much. And I think things are being overcomplicated. Space Fractal is the only one who understands half of what is being written. I didn't even realise until I started reading some of UncleT's threads.

The best way to make a plugin system is to start SMALL with a few commands. Let loadman write his plugin and ADD commands that he needs as he needs them. There is no point in putting every conceivable command in there just so it supports everything. And you have to think more like a plugin author.

The SDK is becoming overcomplicated and that is DANGER! No plugin author will want to write software for an SDK they DO NOT UNDERSTAND. If UncleT doesn't understand the commands HOW WILL A PLUGIN coder?

A) Are the commands simple and easy to understand?
B) Will a plugin author likely want to use this command?
C) Don't add commands for the sake of it

Remember KISS? Keep it Simple Stupid ;)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: unclet on January 13, 2008, 05:27:16 pm
Quote
Winamp:
IT seen it hard to explain when never use a comon software like this to test out.... The command is really suited to this type of software, if they want to add plugin support where the user can jump through songlist back and front, even the song is not played finished."

Not so much in a Jukebox software like your and mine.

The only problem might accour, but I guess we should wait it happens when a real developed plugin use the SONGLIST system.... More can I not say about it. THEN we can correct some issues.

Ok, so in your software, the user can cycle through all available songs in the list while another song is playing.  So you are using the "SONGLIST_CURRENTPOSITION" command to inform the plugin what song the user has currently highlighted. 

Your songlist contains all available songs which the user can select to play if they want to ... ccrrect?

This is similiar to my page flipping and viewing of album tracks.  When a song is playing the user can still flip through the pages of album covers, select an album to see the song tracks associated with the album and then highlight a song track to see information about it.    The user does not need to select a track to play, but can look through all available songs just for fun.

Anyway, I do not plan on telling the plugin what song the user is just "looking" at so I think the "SONGLIST_CURRENTPOSITION" will not be used by my software.  At least I understand how you are using it though  :applaud:


Quote
Juke_Command("JUKE_PLUGIN_EVENT_CREATE",  "PLUGIN_EVENT_(name)|ENABLE/DISABLE|number|KeyEvent")

should been then something like

Juke_Command("JUKE_PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|TOGGLE or NUMBER")

A KeyEvent is not required need to just define a key. It just need to known its a toggle (ENABLE/DISABLE) or a number (VOLUME).

Rest is fine as it are and is accepted.

I put the "keyEvent" stuff into the CREATE command for you since I thought you wanted to know whether a key was UP or DOWN or simply CLICKED.   If you do not need that, then the keyEvent stuff can be removed since my software will not care about KEYDOWN/KEY UP stuff .....

As for the "TOGGLE" text ..... I would like to define this so there is no misunderstanding.  If the plugin ever gets out of sync with the jukebox software I would like the plugin to be able to "reset" the jukebox software back to a specific setting instead of just using toggle.   Basically, I want the plugin to be able to state they want to "ENABLE" or "DISABLE" something instead of just use toggle.

For example, lets say the plugin is using toggle to manipulate the states of features and settings in the jukebox.  Now lets say the plugin has a button to all all values to be reset back to their default values.  The plugin should be able to state exactly what state a function or setting should be in my indicating "ENABLE" or "DISABLE" explicitly instead of just have to toggle the values back and forth.

The values allowed could be "ENABLE" and "DISABLE" for now, but could be expanded to include other choices in the future as well.   

Quote
That can been a very much problem when we have functions that might varierer from software to software. RESTART is one of them.

A Plugin can detect when a song restarted middle from the current song without SONG_RESTART: It just checking the song position (currentSecs have been resetted).

No real need to force the plugin have to keep track of song position in order for it to know when a song has restarted though, so please keep the "SONG_RESTART" command.

definitions:
When something starts again before it has a chance to finish, then it has "restarted"

When something starts again after it has finished then it has "repeated"


Quote
The repeat and loop is the major problem, because mine is song based, your is queue based.

I am thinking my problem was that I was trying to use the SONG_REPEAT command to indicate the song has been added to the bottom of the queue, when really this is not important information at all.    It might be nice to know that a feature in my software has been turned on to allow songs which have finished playing to be placed on the bottom of the queue, however I can add a new commands for this.

Perhaps we can agree on using the commands this way:

JukeCommand(JUKE_SONG_RESTART, "")
this is sent when a song HAS NOT finished playing and is requested to start playing from the beginning again

JukeCommand(JUKE_SONG_REPEAT, "")
this is sent when a song HAS finished playing and the song will immediately be played again.

JukeCommand(JUKE_FEATURE_REPEAT_MODE, "TRUE or FALSE")
this is sent when the user turns on/off arepeat feature which places a song which has finished playing at the bottom of the song queue so it will eventually be played again.


Quote
Mightbe remove JUKE_SONG_REPEAT COMMAND, and the AUTOPLAY.

Please read my comments above and see if we can agree to use the JUKE_SONG_REPEAT" command the way that I describe.

I would like to keep AUTOPLAY, since this has nothing to do with repeat or restarting songs.  I described earlier the AUTOPLAY feature is a feature (when turned on) which will automatically play a song when no other songs are playing and no other songs are located in the queue to play.


Quote
Instead use JUKE_SONG_MODE(mode)?

Here it can tell what it happens to this song and just show the text to the user. It can example been "Radio mode", "Random Mode", "Loop mode", "Repeat Mode" or any mode that suitable to the software?
Since software can have many modes ... I would suggest not adding a "JUKE_SONG_MODE" command.   

If you need a new feature mode I would suggest adding a new command such as "JUKE_FEATURE_xxxxxx_MODE".

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: unclet on January 13, 2008, 05:32:25 pm
I got an idea, how about UncleT list all the commands he wants to have in the plugin system, then we match the common ones with Space Fractals list and then make one final list of commands.

I think the commands are confusing. I think the descriptions of the commands are confusing. How the hell is a plugin author supposed to understand them?

I think Space Fractal is designing the system around his Jukebox software too much. And I think things are being overcomplicated. Space Fractal is the only one who understands half of what is being written. I didn't even realise until I started reading some of UncleT's threads.

The best way to make a plugin system is to start SMALL with a few commands. Let loadman write his plugin and ADD commands that he needs as he needs them. There is no point in putting every conceivable command in there just so it supports everything. And you have to think more like a plugin author.

The SDK is becoming overcomplicated and that is DANGER! No plugin author will want to write software for an SDK they DO NOT UNDERSTAND. If UncleT doesn't understand the commands HOW WILL A PLUGIN coder?

A) Are the commands simple and easy to understand?
B) Will a plugin author likely want to use this command?
C) Don't add commands for the sake of it

Remember KISS? Keep it Simple Stupid ;)

I pretty much agree to use most of the commands defined so far, so getting rid of that list and starting over is something I do not want to do.   I am spending hours and hours writing these comments and I think we are again near the end.

I think Space Fractal has accepted my "PLUGIN_CREATE/SEND/GET" changes so I think this might help.   And I just proposed a nice way to use the REPEAT and RESTART commands.  If Space Fractal accepts this then I believe the commands are going to be pretty straightforward.

Lets hear what Space Fractal thinks about my current comments.  I am trying to think in general terms of what commands should logically be sent to the plugin.  Trying to keep stuff easy as well.

I do agree with you though ..... I was getting way to confused with all the MOVEUP and MOUSEDOWN and KeyEvent stuff SpaceFractal was trying to utilize.  In the end, I believe these commands can be used by Space Fractal and myself.  Lets wait and see. 


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: Space Fractal on January 13, 2008, 05:54:01 pm
My software use a JOYSTICK and 4 buttons, that is all it need to control my software. Rest is just shortcuts to various functions.

That is why I want have the KEY_EVENTS simply as possible. Even UncleT is a good destription, can this to been over complicered for PlugInWrites to use, just for returning a VOLUME command? All GUI settings is also NOT been used by a Plugin.

Mightbe VOLUMES should NOT been used around KEY_EVENT commands, but instead just add a new command return command VOLUME command? Volume is actuelly the only one that actuelly require a number to been sent back.

Then keep the KEY_EVENT commands as KEYBOARD and STATUS actions ONLY. Not to been using numbers.

So, I think HeadKaze is correct here. It begin to been very complised for plugin writers if I changes these. Might been it good for jukebox authors, but for plugin writes? No I think,

All I really need to remote controlling the software OUTSIDE the software itself (using website), automatic things  and also for light actions. Because of that, KEY_EVENT should not been so complicered to send and use. Just see my Sound Plugin.

If other commands require it we would hear that sooner or later. Any request should been hear from PluginWriter allways, not by us.

Due to HeadKAze comment I have NOT updated the first thread, before I head the comment.


......

The commands around REPEAT etc sound fine. Only problem is there is no text feedback for various speciel commands (my LOOP commands example). I have no "JUKE_FEATURE_REPEAT_MODE" mode (it not the same as LOOP_MODE I have).

To been more general for all software which hae diffecent repeat/looping and any other features, it could been joined into one command: JUKE_FEATURE_SONG_MODE(AnyText).

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: headkaze on January 13, 2008, 06:03:09 pm
I pretty much agree to use most of the commands defined so far, so getting rid of that list and starting over is something I do not want to do.   I am spending hours and hours writing these comments and I think we are again near the end.

I think Space Fractal has accepted my "PLUGIN_CREATE/SEND/GET" changes so I think this might help.   And I just proposed a nice way to use the REPEAT and RESTART commands.  If Space Fractal accepts this then I believe the commands are going to be pretty straightforward.

Lets hear what Space Fractal thinks about my current comments.  I am trying to think in general terms of what commands should logically be sent to the plugin.  Trying to keep stuff easy as well.

I do agree with you though ..... I was getting way to confused with all the MOVEUP and MOUSEDOWN and KeyEvent stuff SpaceFractal was trying to utilize.  In the end, I believe these commands can be used by Space Fractal and myself.  Lets wait and see. 

Okay my apologies (especially to Space Fractal), browsing over the posts it looked like there was major disagreement, but if most of the API is agree'd upon that's great. So if it's just a few of the commands left over that you need to finalize I'm happy.

I just didn't want to see the SDK go the way of the Do Do. But I still think some of the descriptions need to be re-written by someone with more experience in English, and with some practical examples of how they work. Afterall it's going to be loadman (and possibly other coders) that has to understand what they mean not you guys.

Once you two get the two way communcation commands sorted (which I think should have more than just Key events) and I will add a simple Timer to the VB6 Host as an example of how to receive commands from the plugin.

Due to HeadKAze comment I have NOT updated the first thread, before I head the comment.

Hey it's best just to get it done and finish it off, then if loadman has problems then explain it to him as he goes. Please continue, sorry I interrupted.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: Space Fractal on January 13, 2008, 06:11:08 pm
Yes it just pretty few commands left....

And yes, Im are danish, not english.

yes I guess LoadMan should go throuch the document now and feedback what it missing.

I think I change tke KEY_EVENT commands that was agreed. Please note, please wait to update SDK now before we fully agree. It really just few commands.

The only one think we are disagreement is around these repeat commands.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: loadman on January 13, 2008, 06:21:26 pm
yes I guess LoadMan should go throuch the document now and feedback what it missing.

 ;D

No Problem.

I will go through the list and with a view to
* Making gramatical/spelling corrections
* Ask Questions of commands I don't understand.
* Make a draft PDF (so you can comment on the look/ layout)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: Space Fractal on January 13, 2008, 06:28:28 pm
UncleT: Just Updated (and yes we was/still only abit disagree on few commands ONLY, not the whole document). We need to make sure we adding them correct and behaiver very much the same.

Of course, Loop And Repeat is of course just a features and all user enable/disable features or simular like that should allways go under features command.

I agree.

I do still added the looping command I have to been used by a plugin, but it of course just a another feature.

Features commands is only the list of commands that might not constain on all software yet (along with few playing commands as well).


Loadman: That would been very granted, since Im are Danish, and there a lots of gramatical errors here and there (my work is got the all commands done and accepted with UncleT). I prefer html, since I can host the file on the website (I have just registred the domain).


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: unclet on January 13, 2008, 06:33:12 pm
(ADDED BEFORE THE PREVIOUS THREE POSTS WERE READ)
(I WILL LEAVE IT HERE SO EVERYONE CAN READ IF THEY WANT)

(I AGREE WE SHOULD FINISH OFF THE STANDARD AND THEN LET THE PLUGIN AUTHORS DETERMINE WHAT MAKES SENSE OR NOT)

Well my PLUGIN_EVENT_CREATE command has simplified this by getting rid of two separate naming "KEY_EVENT_(name)" and "STATUS_EVENT_(name)" ..... and now simply has one name "PLUGIN_EVENT_(name)" only

I still do not understand what the difference is between a KEY_EVENT and STATUS_EVENT events and I am getting too tired and spending way too much time typing stuff for this thread.  It is my opinion that Space Fractal is designing some really detailed stuff which he can use for his jukebox dealing with KeyEvents (mouseDown, moveUp, etc...) and remote control stuff.   This is good but I think the result is this I just do not understand the commands he needs, and never getting exact details command sequence of what he wants is not helping me undersatnd, so designing something we all can use is getting me to spend way too much time on this activity.

I provide tons of examples and reasoning to try to justify my points for changing or adding commands, however, Space Fractal really does not do the same so most of the time it is quite hard to interpret exactly what is being said.  Everyone in this thread uses the "(quote)/(/quote)" boxes when providing comments so it is easier for the person reading them to undersatnd the relationship.  However, Space Fractal never uses them so trying to figured out what his comments are relating to is also somewhat challenging.  Having a language barrier in the way as well does not help things, but that is not his fault so I do not blame anyone for that.  Also, I might not be the best explainer myself so I might be part of the problem.  However, I feel like I have to ask the same question multiple various ways until I can piece together all the various different answers to get to a solution I at best "think" might be right.  It has resulted in me spending too much time on this.

Now, I believe Space Fractal and I were about to find an agreement again, however, I guess he changed he mind on a few things.    :dunno

What I can do:
I can simply publish the commands which my jukebox software will use and then let people generate their own plugin if they wish to interact with my software. 

I really do not know of a lot of people that use my software at all so possibly only loadman will be writing a plugin for it anyway.  I can just make sure everything loadman wants is included and be done.

I never wanted to spend this much time on it anyway since I have no plans on using a plugin myself.  I was simply trying to help out other jukebox designers design some sort of standard.  Since this time Barcrest has left the discussion and I find myself talking with Space Fractal by myself.  It would have been nice to get some other input along the way instead of Space Fractal and I having to figure out "what would be best". 

It would have been nice to have headkaze and loadman comment along the way as to what "they" believe would be "easy" to do and what commands would be nice and what commands make no sense.

What I can not do:
I will NOT start this discussion over.  I have too much time invested and too much code written to do that at this point.  My fingers hurt from typing so much as well. 

If you want to get rid of all the work we agreed upon so far, then I will simply just post my own commands for my jukebox and let any plugin writers write a specific plugin using the commands I can understand.   


Space Fractal
I would ask that you review my last post and see if you agree with the stuff I propose in there.  If so, then we might be done.

headkaze
Instead of stating that you think a lot of this stuff is becoming overly complicated, perhaps you could provide exact comments as to which stuff is overly complicated so we can address it.   What do you think is complicated?  What way would you propose to approach the problem?  Hearing some comments like these would be nice.

loadman
being another plugin writer it would be nice to hear whether you think any of these commands are hard to understand as well.  If so, whicih commands, and what solution would you offer.


It would just be great if Space Fractal and I were not the only voices in this discussions.

One last point ..... I would like to appreciate Space Fractal's time and effort as well.  He probably feels like me and is spending the same amount of time on this project as well and probably gets frustrated at times as well.   :cheers:



 


 
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: Space Fractal on January 13, 2008, 06:39:30 pm
Done for me, if you doesn't have other comments?

Of course we are all deficient, otherwise we have never made our own software of course.

I have also speed to much time to debate, but even it can been frustrated at time, but it still fun.

Otherwise I have never joined into this project.

Otherwise :cheers: (specific to UncleT), and yes I have same felling as you. Long debate, diddent trhouch the thread would been so big, but still fun.

Is Beta 12 the last (unless we find document errors, here it up to loadman I think)?

Should I change into v1.0 Final?

Rest might just been small document errors, loadman might find. (hence we just use v1.0.1, v1.0.2 in the future).





At last About KEY_EVENT and STATUS_EVENT (diddent notice that first):
AGREE, it no longer using these prefix, due to these change.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: headkaze on January 13, 2008, 06:49:22 pm
headkaze
Instead of stating that you think a lot of this stuff is becoming overly complicated, perhaps you could provide exact comments as to which stuff is overly complicated so we can address it.   What do you think is complicated?  What way would you propose to approach the problem?  Hearing some comments like these would be nice.

Sorry I should have just kept my mouth shut lol I was just a bit worried there was disagreement again with the commands, but you guys seem to be sorting it out.

If I knew more about Jukebox software I could probably help simplify some things. I understand Space Fractal is Danish so he's doing the best he can at writing up the doc's which is great. I don't want to discourage him either because he's doing a great job. So I'll just go back to lurking in this thread and update the examples as you guys update the commands. There is no point in me entering the debate when I don't have any practical help to give.

Overall I think most of the commands are straight forward, some are a little tricky to understand like the two way communication. But once we get some practical plugin examples done I think it will make more sense.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: loadman on January 13, 2008, 07:00:56 pm
loadman
being another plugin writer it would be nice to hear whether you think any of these commands are hard to understand as well.  If so, which commands, and what solution would you offer.

I was being careful not be to critical as that would make me seem ungrateful as it was my suggestion to add plug-ins.

I am happy with whatever system you guys are happy with. I stopped making too many comments as that seemed to be slowing things down. I think barcrest had a similar view.  Too Many Chefs!!!!

I was happy just to wait and see what you guys were happy with as what was there already was much more then I every expected anyway  ;D

I am going through the command list now and there will be questions of things that don't make sense to me (your average dumb dumb)  :banghead:

I will make the doc html not pdf  ;)

Thanks again guys  :cheers:
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b13, Last Beta? !!)
Post by: Space Fractal on January 13, 2008, 07:04:34 pm
ok. I should not change anymore now before after v1.0 (or should I call it v1.02 since we was agree one time ago)?


I think i take a break in few days due to the long debate, but it seen finalize now?

I release my software with plugin support latest sunday with these commands.

But still: Godus to all.

And yes I hoped to get commands from Barcrest as well. One of the commands was from him.


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b12 !!)
Post by: unclet on January 13, 2008, 07:33:41 pm
Quote
UncleT: Just Updated (and yes we was/still only abit disagree on few commands ONLY, not the whole document). We need to make sure we adding them correct and behaiver very much the same.
I agree

Quote
Of course, Loop And Repeat is of course just a features and all user enable/disable features or simular like that should allways go under features command.

I agree.

I do still added the looping command I have to been used by a plugin, but it of course just a another feature.
I agree as well, thanks for defining these.


One thing though .... you have these duplicate REPEAT commands defined now:

Juke_Command("JUKE_SONG_REPEAT","onOnce OR onAlways OR off")
when the "repeat" feature is turned on, then when the current playing song finishes it will be placed at the end of the song queue automatically.

JukeCommand(JUKE_SONG_REPEAT, "")
this is sent when a song HAS finished playing and the song will immediately be played again.


I prefer the bottom definition please, I believe the top definition should be deleted since we added a JUKE_FEATURE_REPEAT_MODE command now.. 


Quote
Features commands is only the list of commands that might not constain on all software yet (along with few playing commands as well).
I agree .... simply send the FEATURE commands if you software supports that type of feature


Quote
Juke_Command("JUKE_VOLUME_CHANGE", "system|curVolumeLevel|minVolumeLevel|maxVolumeLevel")
A new value volume have been changed or set....
Thanks for changing the name of this command ...  not really necessary but I thought it made more sense.


Quote
Juke_Command("JUKE_PLUGIN_EVENT_CREATE",
  "PLUGIN_EVENT_(name)|boolean ENABLE/DISABLE|boolean NUMBER|numOfKeyEvents|keyEvent1|keyEvent2|...|keyEventX")
This command is not in BOLD in your first post .....like the other, so it looks hidden.  Just letting you know.


Quote
MY FINAL THOUGHTS

I agree with the current command set which Space Fractal has posted (accept for the duplicate definitions of the SONG_REPEAT command which he might address after reading this post).

Lets wait for the plugin authors to review these commands and see if it makes sense to them.  Whatever they do not understand can be discussed BEFORE changing anything.  Basically, lets try not to change the command definitions until we all agree.   Keeping track of stuff which changes so frequently is getting hard.

Should we open a new thread with this current command set at the top and then have the thread be commented by plugin authors to hear their thoughts?


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Last Final !!)
Post by: Space Fractal on January 14, 2008, 01:00:47 am
Done. These was just errors.

I think Loadman should create a new thread about gramatic errors or other problems? That part is no my work.


Only little things even it does NOT bother me and can leave at they are:

- SONG_RESTART could restart from begging regaardles it is on the middle on the song or not.
- SONG_REPEAT should roll the song back to the queue, but since it defined in the feature command set, does this command needed and just use SONG_RESTART?

But again, I accepted as they are now, so no need to change them.

This system is really need to been have a seperate Support forum,
so I asked Saint to create that using JukePlugSys as the new support forum...

I have registred the domain, so we should make a mini homepage to JukePlugSys.com, and then have a support forum haven it here (A sticky thread about Plugins can been goes on this forum to link to the new support forum)?
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Last Final !!)
Post by: loadman on January 14, 2008, 04:27:21 am
This system is really need to been have a seperate Support forum,
so I asked Saint to create that using JukePlugSys as the new support forum...


 :dunno  I don't know about that??  I think once the format is set and understood (with good documentation) the posts will settle down a lot.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Last Final !!)
Post by: headkaze on January 14, 2008, 04:45:11 am
This system is really need to been have a seperate Support forum,
so I asked Saint to create that using JukePlugSys as the new support forum...


 :dunno  I don't know about that??  I think once the format is set and understood (with good documentation) the posts will settle down a lot.

I have to agree with loadman on this one. No need for a new forum. Maybe a pinned topic eventually?

I wonder how many plugin's Space Fractal thinks will be made? lol I know he still thinks I'm writing one ::)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Last Final !!)
Post by: loadman on January 14, 2008, 04:48:41 am

Quote
I have to agree with loadman on this one. No need for a new forum. Maybe a pinned topic eventually?
Yeah, it will end up being just the odd new post for new Plug-ins

I wonder how many plugin's Space Fractal thinks will be made?

My plabs are:
- JukeStub (Plug-in tester to save time)
- LcdDisplay (Basic serial Character/ Betabrite display driver) much like the MaLa one

Maybe List
- A Pause/Volume based on external events
- Random sound wav's triggered on certain events (based on mala plug-in)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Last Final !!)
Post by: headkaze on January 14, 2008, 05:03:41 am
Maybe List
- A Pause/Volume based on external events
- Random sound wav's triggered on certain events (based on mala plug-in)

I suppose you could knock up a Speech plugin for it quite easily too. So it says the name of the song, album when you play a song etc.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: unclet on January 14, 2008, 07:09:27 am
I do not think a new forum would be worth it ..... not a lot of people are visiting the Audio/MP3/Jukebox forum as it is .... so I think having posts in this existing forum for plugin will be fine.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: Space Fractal on January 14, 2008, 07:11:18 am
I think the Support forum could also used to release any plugins (both beta and finished) other have wrote and also get help?

Juke like a other Jukebox software, I just like to seperate Plugins and this forum as well.

My Plans (YES, I have planning to create a plugins or two as well):
- Remote Controller from a another machine.
- Better sound plugin, but that one I wrote was just a test.

There have been requsted over the Freebox forum to get freebox support plugins... They can releaed here too.

But otherwice I would release them on the minisite when the domain work. Would just look more proffessionel when the website linking directrly to a support forum at arcadecontrol.com ask for help (Like UncleT have a support forum too, and SK-Jukebox is not actuelly used more, due SalmonKing have leaved the project).

That all.

ETC, mightbe a sticky thread only one can update and post, just like the Jukebox Software list? OR moving the released plugins to the Wiki?

Should we not create a WIki page about it?



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: unclet on January 14, 2008, 07:16:10 am
Quote
- SONG_REPEAT should roll the song back to the queue, but since it defined in the feature command set, does this command needed?

I thought you wanted a way to indicate when a song was finished and has been started again immediately like in a "loop".

Anyway, I do not need the "SONG_REPEAT" command so you can delete it if you really do not need it either.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: Space Fractal on January 14, 2008, 10:35:15 am
I do that using JUKE_FEATURE_LOOP command, can also do that with a defined PLUGIN_EVENT too....

All TRUE/FALSE features can actulle use a PLUGIN_EVENT too, but I leave them all as they are.

Can been renamed to JUKE_SONG_STOP, which the user have stoppet a song, but again I can send a SONG_PAUSE and SONG_RESTART instructions for the same.



Just for fun, here is all PLUGIN_EVENTS I have planning to use in MultiJuke:

Code: [Select]
PLUGIN_EVENT_0|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_1|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_2|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_3|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_4|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_5|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_6|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_7|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_8|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_9|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_ACTIONBUTTON1|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_ACTIONBUTTON2|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_ACTIONBUTTON3|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_ACTIONBUTTON4|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_BACK|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_BLANK|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_CLEAR|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_CONFIG|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_CONTROL|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_CREDITS|FALSE|TRUE|0
PLUGIN_EVENT_GENRELOCK|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_INSERTCOIN1|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_INSERTCOIN2|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LETTERDOWN|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LETTERUP|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LIBRARY 1|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LIBRARY 2|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LIBRARY 3|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LIBRARY 4|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_LOOP|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_MOVEDOWN|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_MOVELEFT|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_MOVERIGHT|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_MOVEUP|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_OK|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_PAGEDOWN|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_PAGEUP|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_PAID|FALSE|TRUE|0
PLUGIN_EVENT_PARENT|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_PAUSE/RESUME|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_QUIT|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_SKIP|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_SONGMODE|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_STOP|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_VOLUMEDOWN|FALSE|FALSE|1|KEYCLICK
PLUGIN_EVENT_VOLUMEMUTE|TRUE|FALSE|1|KEYCLICK
PLUGIN_EVENT_VOLUMESET|FALSE|TRUE|1|KEYCLICK
PLUGIN_EVENT_VOLUMEUP|FALSE|FALSE|1|KEYCLICK
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: unclet on January 14, 2008, 01:07:23 pm
Quote
I do that using JUKE_FEATURE_LOOP command, can also do that with a defined PLUGIN_EVENT too....

All TRUE/FALSE features can actulle use a PLUGIN_EVENT too, but I leave them all as they are.

Yes, perhaps they can .... but I think it is nice that we defined FEATURE commands to indicate the more generic features most all jukebox software have included anyway.   I would suggest we leave the FEATURE commands how they are and simply use the "PLUGIN_EVENT_(name)" events to indicate "jukebox-specific" events only.


Quote
Can been renamed to JUKE_SONG_STOP, which the user have stoppet a song, but again I can send a SONG_PAUSE and SONG_RESTART instructions for the same.
Yes, no need for a "SONG_STOP" commands since that would be true general.  Indicating  the song stopped since it "FINISHED" or has been "RESTARTED" or has been "SKIPPED" is much more helpful I think.

Quote
Just for fun, here is all PLUGIN_EVENTS I have planning to use in MultiJuke:

Looks good to me ..... does this mean you are finding the current "PLUGIN_EVENT_CREATE" command format to be suitable for your needs? 

I noticed you are using the "keyEvent" stuff (glad you left that in there I guess) and that some of your create commands are informing the plugin that 2 keyEvents are allowed to be sent back (KeyDown and KeyUp).  Is there a need to define other keyEvents now?  Perhaps will should wait to see what the plugin authors want. 

I also see that the PLUGIN_EVENT_CREDITS and PLUGIN_EVENT_PAID events are not related to any key events at all.   This exactly how I thought these events could be created and used to inform the plugin exactly what they can be used for and what return values the plugins can send back to the jukebox software.

I need to think about my list ..... might do that later tonight.  At work right now. :P




Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b15, Tiny Fix !!)
Post by: unclet on January 14, 2008, 02:02:13 pm
Quote
Juke_Command("JUKE_PLUGIN_EVENT_CREATE",
  "PLUGIN_EVENT_(name)|boolean ENABLE/DISABLE|boolean NUMBER|numOfKeyEvents|keyEvent1|...|keyEventX")

My software allows the user to go directly to all album covers starting with a particular letter.   For example: The user can enter "M" and then this will result in all the albums starting with "M" being displayed.

As a result I would like you to add "LETTER" to the following command before it becomes finalized.  Seems like we should have a letter in there anyway.

Quote
Juke_Command("JUKE_PLUGIN_EVENT_CREATE",
  "PLUGIN_EVENT_(name)|boolean ENABLE/DISABLE|boolean NUMBER|boolean LETTER|numOfKeyEvents| keyEvent1|...|keyEventX")



After making this change, then here are the command formats I am thinking about supporting right now:

Quote
PLUGIN_EVENT_CONFIG|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_EXIT|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_MEDIA_TAB|FALSE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_TAB|FALSE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SEARCH_TAB|FALSE|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_PLAY|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_PAUSE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_FASTREV|FALSE|FALSE|FALSE|1|KEYDOWN|KEYUP
PLUGIN_EVENT_FASTFWD|FALSE|FALSE|FALSE|1|KEYDOWN|KEYUP
PLUGIN_EVENT_SKIP|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_VOLUMEDOWN|FALSE|FALSE|FALSE|1|KEYDOWN|KEYUP
PLUGIN_EVENT_VOLUMESET|FALSE|TRUE|FALSE|0
PLUGIN_EVENT_VOLUMEUP|FALSE|FALSE|FALSE|2|KEYDOWN|KEYUP
PLUGIN_EVENT_VOLUMEMUTE|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_FULLVIDEO|TRUE|FALSE|FALSE|0

PLUGIN_EVENT_PRIMARY_MONITOR_DISP_CYCLE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_DUAL_MONITOR_DISP_CYCLE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_FULLSCREEN|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_SONGQ_CLEAR|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SONGQ_REPEAT|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_SONGQ_RANDOM|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_SONGQ_MOVE|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_SONGQ_UP|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SONGQ_DOWN|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_IDLEPLAY_ACTIVATE|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_RANDOM|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_GENRE|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_GENRE_CYCLE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_TOP10|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_TOP25|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_TOP50|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_IDLEPLAY_TOP100|TRUE|FALSE|FALSE|0

PLUGIN_EVENT_ENTERSEL_DIGIT0|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT1|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT2|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT3|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT4|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT5|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT6|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT7|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT8|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DIGIT9|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_CLEAR|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_DELETE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ENTERSEL_PLAY|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_ALBUM_COVERS_NAV_UP|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_NAV_DOWN|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_NAV_LEFT|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_NAV_RIGHT|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_ALBUM_COVERS_SEEK_1ST_CHAR|FALSE|TRUE|TRUE|0
PLUGIN_EVENT_ALBUM_COVERS_SEEK_2ND_CHAR|FALSE|TRUE|TRUE|0

PLUGIN_EVENT_SONGTRACKS_UP|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SONGTRACKS_DOWN|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SONGTRACKS_SELECT|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_SONGTRACKS_RANDOM|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_SONGTRACKS_PLAYALL|FALSE|FALSE|FALSE|0

PLUGIN_EVENT_PLAYLISTS_CYCLE|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_PLAYLISTS_UP|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_PLAYLISTS_DOWN|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_PLAYLISTS_SELECT|FALSE|FALSE|FALSE|0
PLUGIN_EVENT_PLAYLISTS_RANDOM|TRUE|FALSE|FALSE|0
PLUGIN_EVENT_PLAYLISTS_PLAYALL|FALSE|FALSE|FALSE|0
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b15, Tiny Fix !!)
Post by: Space Fractal on January 14, 2008, 04:32:34 pm
I do not touch the JUKE_FEATURES anyway  :).

I Think I just adding a KeyLetter for that instead of adding a new boolean feature (and is backward combatible with last SDK beta). That why we can expand KeyEvent List when needed.

KeyClick
KeyDown
KeyUp
KeyLetter?

ETC

PLUGIN_EVENT_ALBUM_COVERS_SEEK_1ST_LETTER|FALSE|TRUE|1|KeyLetter
PLUGIN_EVENT_ALBUM_COVERS_SEEK_2ND_LETTER|FALSE|TRUE|1|KeyLetter

All it should do is using AscII Scancode and send as number to the plugin (Like a Char in C++). If the plugin trying send back other than a letter, just iqnore it.

I now added KeyLetter, so it still fully combatibile with previous beta.

I found small error n your list:
PLUGIN_EVENT_VOLUMEDOWN|FALSE|FALSE|FALSE|1|KEYDOWN|KEYUP should been
PLUGIN_EVENT_VOLUMEDOWN|FALSE|FALSE|FALSE|2|KEYDOWN|KEYUP

The number 2 should the number of argument used (you have a KEYDOWN and KEYUP here).

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b14, Very Last? !!)
Post by: loadman on January 14, 2008, 04:44:35 pm
 :applaud: NICE TO SEE YOU ARE DOWN TO PLANNING A LIST OF SUPPORTED COMMANDS GUYS    :applaud:

I think the Support forum could also used to release any plugins (both beta and finished) other have wrote and also get help?

Again, I think just posting questions or release in this forum will be fine. They may not be seen if they get posted elsewhere.  The balance for FE Plug-ins seems to be ok for mala in the software forum 8)

Quote
ETC, mightbe a sticky thread only one can update and post, just like the Jukebox Software list? OR moving the released plugins to the Wiki?
Should we not create a WIki page about it?]ETC, mightbe a sticky thread only one can update and post, just like the Jukebox Software list? OR moving the released plugins to the Wiki?
Should we not create a WIki page about it?

Wiki has been started.  Feel free to add/change  ;D

http://wiki.arcadecontrols.com/wiki/Jukebox_Plug-Ins (http://wiki.arcadecontrols.com/wiki/Jukebox_Plug-Ins)
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b15, Tiny Fix !!)
Post by: Space Fractal on January 14, 2008, 05:04:32 pm
Like I explain for the other post. what hell can the enduser finding around this big thread, that is mostly technical?

When the SDK is end and release the final version, I like to lock this thread or leave as it are. I guess it would take time before we talk about version 1.1.

Then we should tell the enduser how this is all about as non technical talk (A new thread) what this is all about.

enduser have normally no technical knownable at all.


NB. Plugin support is dropped. Your guys might been right, since this forum might fall neary back to normal after some time. I do still create the mini website about this system.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b16, 1 addition !!)
Post by: Space Fractal on January 14, 2008, 06:23:35 pm
http://www.jukeplugsys.com/ works and now show a WordPress standard site. I guess HeadKaze and others might want some access to write about the SDK, Plugins and About sections.

At by now, it use the default theme. but would nice to change that with a fine logo. I guess HeadKaze and Loadman is intered to mainsstrem the blog?

I looking on the theme of the website tomorrow danish time, but a least it works now. I dedicated to registred the shorted version of the domain, that is easy to remember.

On the frontpage It could been any released plugins and applications. But let me know.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b16, 1 addition !!)
Post by: unclet on January 14, 2008, 07:33:33 pm
Quote
I Think I just adding a KeyLetter for that instead of adding a new boolean feature (and is backward combatible with last SDK beta). That why we can expand KeyEvent List when needed.

Well I did not want to "release" anything official until loadman at least had a chance to see if everything made sense and also until we had a chance to get into the coding part ourselves a bit more.

Adding something called "KeyLetter" is not a correct way to go about this, for what I need. 

Here is what I recommend ........

Lets just do what I first wanted to do until everything got changed to boolean values.... which I thought was fine .... until now.   It is even easier than I first thought and I think everyone should like this format a lot better.

DONT WORRY, IT IS A MINOR CHANGE, but makes a lot more sense


JukeCommand("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)
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


Note: I expanded it to include all current values as well as "ON and "OFF" values since these are not the same as "ENABLE" and "DISABLE".


This is a lot easier since:

1) No parsing has to be done to determine which values are allowed, just see if the text is within the string provided

2) The list of allowable values can easily be expanded without making the whole "PLUGIN_EVENT_CREATE" format larger.

3) Allows me to indicate "ENABLE" should be allowed, but "DISABLE" should NOT be allowed. (This is required when I have "Option buttons" in which you really can only indicate which button is enabled ..... you can not disable all "Option buttons" at once.  Basically, enabling one option button would automatically cause the other option buttons to be disabled)


For example:
To indicate whether something is on or off then the following command would be created:

JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ON OFF"


To indicate a number or letter can be associated with the event:

JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"NUMBER LETTER"


To indicate you can enable or disable something as well as indicating you can receive some keyEvent for it:

JukeCommand("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("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ENABLE DISABLE NUMBER LETTER"


I would highly recommend updating the standard to this format.  This is what I originally wanted but I thought you wanted booleans instead for some reason, which I thought was fine .... until now ...... this is a LOT easier to understand, maintain and expand.



Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b16, 1 addition !!)
Post by: unclet on January 14, 2008, 08:41:59 pm
My new supported events would look like this instead (much easier):


Quote
PLUGIN_EVENT_APP_EXIT|""

PLUGIN_EVENT_MEDIA_TAB|""
PLUGIN_EVENT_ALBUM_TAB|""
PLUGIN_EVENT_SEARCH_TAB|""

PLUGIN_EVENT_PLAY|""
PLUGIN_EVENT_PAUSE|""
PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
PLUGIN_EVENT_SKIP|""
PLUGIN_EVENT_VOLUMESET|"NUMBER"
PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
PLUGIN_EVENT_FULLVIDEO|"ON OFF"

PLUGIN_EVENT_PRIMARY_MONITOR_DISP_CYCLE|""
PLUGIN_EVENT_DUAL_MONITOR_DISP_CYCLE|""
PLUGIN_EVENT_FULLSCREEN|"ON OFF"

PLUGIN_EVENT_SONGQ_CLEAR|""
PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF"
PLUGIN_EVENT_SONGQ_RANDOM|"ON OFF"
PLUGIN_EVENT_SONGQ_MOVE|"ENABLE DISABLE"
PLUGIN_EVENT_SONGQ_UP|""
PLUGIN_EVENT_SONGQ_DOWN|""

PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"
PLUGIN_EVENT_IDLEPLAY_RANDOM|"ON OFF"
PLUGIN_EVENT_IDLEPLAY_GENRE|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_GENRE_CYCLE|""
PLUGIN_EVENT_IDLEPLAY_TOP10|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP25|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP50|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP100|"ENABLE"

PLUGIN_EVENT_ENTERSEL_DIGIT0|""
PLUGIN_EVENT_ENTERSEL_DIGIT1|""
PLUGIN_EVENT_ENTERSEL_DIGIT2|""
PLUGIN_EVENT_ENTERSEL_DIGIT3|""
PLUGIN_EVENT_ENTERSEL_DIGIT4|""
PLUGIN_EVENT_ENTERSEL_DIGIT5|""
PLUGIN_EVENT_ENTERSEL_DIGIT6|""
PLUGIN_EVENT_ENTERSEL_DIGIT7|""
PLUGIN_EVENT_ENTERSEL_DIGIT8|""
PLUGIN_EVENT_ENTERSEL_DIGIT9|""
PLUGIN_EVENT_ENTERSEL_CLEAR|""
PLUGIN_EVENT_ENTERSEL_DELETE|""
PLUGIN_EVENT_ENTERSEL_PLAY|""

PLUGIN_EVENT_ALBUM_COVERS_NAV_UP|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_DOWN|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_LEFT|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_RIGHT|""
PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""
PLUGIN_EVENT_ALBUM_COVERS_SEEK_1ST_CHAR|"NUMBER LETTER"
PLUGIN_EVENT_ALBUM_COVERS_SEEK_2ND_CHAR|"NUMBER LETTER"

PLUGIN_EVENT_SONGTRACKS_UP|""
PLUGIN_EVENT_SONGTRACKS_DOWN|""
PLUGIN_EVENT_SONGTRACKS_SELECT|""
PLUGIN_EVENT_SONGTRACKS_RANDOM|"ON OFF"
PLUGIN_EVENT_SONGTRACKS_PLAYALL|""

PLUGIN_EVENT_PLAYLISTS_CYCLE|""
PLUGIN_EVENT_PLAYLISTS_UP|""
PLUGIN_EVENT_PLAYLISTS_DOWN|""
PLUGIN_EVENT_PLAYLISTS_SELECT|""
PLUGIN_EVENT_PLAYLISTS_RANDOM|"ON OFF"
PLUGIN_EVENT_PLAYLISTS_PLAYALL|""
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b16, 1 addition !!)
Post by: Space Fractal on January 15, 2008, 02:28:57 am
I Update: D, I 100% agree, that one is much much easier to understand and for use.

beware: I add a UTF8 based Letters for unicode support (can use 2-4 bytes for encodning), if unicode is enabled.
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b17, final? !!)
Post by: unclet on January 15, 2008, 07:31:48 am
Quote
I Update: D, I 100% agree, that one is much much easier to understand and for use.
:applaud:   :cheers:  :applaud:

Quote
I add a UTF8 based Letters for unicode support (can use 2-4 bytes for encodning), if unicode is enabled
My UNICODE will always be set to FALSE, so I am not sure whether I need to worry about this stuff. 

Quote

MY LAST RECOMMENDATION
I think we should now remove the "JUKE_FEATURE_xxxxx" stuff now.   I agree these should all be handled by "PLUGIN_EVENT_(name)" events instead.

After this change I think I might be done tweaking ....... what do you think.

PS:  Also make sure you update your Beta version (highlighted in RED) in the first post so headkaze can generate a new code version.  CUrrently it lists beta16, but you are at b17 now.   After removing the "JUKE_FEATURE_xxxx" stuff, you should be at beta18.

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b17, final? !!)
Post by: Space Fractal on January 15, 2008, 08:05:45 am
I removed all TRUE/FALSE commands under features, unless one (CONFIG).....

I leave rest are, because they are NOT a TRUE/FALSE statement commands, ATTRACT MODE, LOOP and AUTOPLAY example. There use a output string or using 3 arguments.

Hence all TRUE/FALSE commands is now allways Plugin_Event commands.... Hence we can have various events about it.

If your software does not support unicode, just set it to false, and you are not need to been worry anything about it....

There is some software (Like MultiJuke) that support Unicode and to been backward com bitable that is why I choice UTF8 to sending with strings, since it use a 8 bit encode system, when char>128 is used.....

I think there is no more TWEEKS, which the last 4 betas was just about? One of the bigger tweak was for easier understand of 3 commands, that still does the same...
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b18, Last Tweak !!)
Post by: unclet on January 15, 2008, 09:41:58 am
1) I think you are missing the advantage of using this type of syntax ...... the advantage of defining individual text to be used in the PLUGIN_EVENT_CREATE command is that you can also define the following text and then simply remove ALL of the "JUKE_FEATURE-xxxx" stuff completely.   This is the whole point of using individual text strings.

Just define these as well:

ONACTIVE = feature is turned ON but is actively running (ex: feature to automatically select a song to play when the jukebox is idle is ON and is ACTIVE now since the jukebox became idle and selected a song to play automatically)

ONNOTACTIVE = feature is turned ON but is NOT actively running  (ex: feature to automatically select a song to play when the jukebox is idle is ON but NOT ACTIVE now since jukebox still has user-selected songs to play)

DOONCE = only perform the action one time (ex: after the currently playing song finishes, then replay the song one more time immediately)

DOALWAYS = perform the action all the time  (ex: after the currently playing song finishes, then replay the song again and keep doing this continuously)


So I would recommend adding the text above and simply removing the JUKE_FEATURE_ xxx stuff ....... makes it even easier for a plugin to understand what is going on.


** One exception might be the "JUKE_FEATURE_AUTOPLAY" feature.  This is a feature which was created to indicate when the software automatically chooses a song to be played instead of letting the jukebox become idle (ie: no songs at all playing). 

I am no longer going to be using this AUTOPLAY feature since I can indicate whether automatic playing of songs is occurring using a "PLUGIN_EVENT" event (using the ONACTIVE, ONNOTACTIVE and OFF indicators).   

Now, it seems the "JUKE_FEATURE_AUTOPLAY" feature also allows a way to indicate to the plugin to display some text on the screen.   Not sure if "JUKE_FEATURE_AUTOPLAY" is really named correctly for this type of function ..... but if you need it then keep it .... but I would think about renaming it to something better.  Up to you.

... but make sure to delete the "JUKE_FEATURE_xxx" stuff from your first post now   :)


2) Please add the RED below:

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

and....

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"


3) Please add this new example under the "PLUGIN_EVENT_CREATE" section:

To indicate you have a feature which can be "turned on but is not active yet", "turned on and is currently active" or is "turned off":
JukeCommand("PLUGIN_EVENT_CREATE", "PLUGIN_EVENT_(name)|"ONACTIVE ONNOTACTIVE OFF"


Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b18, Last Tweak !!)
Post by: Space Fractal on January 15, 2008, 10:39:24 am
I think it way to been too many statament, if these are added i Think? I want this to been general as possible, hence I really like enable/disable/letter/number/on/off and these 3 keyevents as well.

I want to limit to these, you defined at your post.


You could actuelly use something like this to do the same:
PLUGIN_EVENT_ATTRACK_MODE|ENABLE DISABLE ON OFF"

ENABLE DISABLE take care if the ATTRACK MODE is ON (Enabled) or OFF (Disabled).
when the attrackmode is enabled, ON = OnActive, and Off=NoActive.

Due you can do that above for doing the same, I have just marked all features as removed and show what they so would do (I think Barcrest have added most of thest to, hence I cant just remove them, instead marked that with text).

I renamed AUTOPLAY to JUKE_SONG_PLAYMODE(AnyText). You right.



After these tweaks I have this list now to cover the missing various features... Look in commands.txt (this is for INTERNAL use for MultiJuke).

Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b18, Last Tweak !!)
Post by: unclet on January 15, 2008, 11:17:53 am
I think it way to been too many statament, if these are added i Think? I want this to been general as possible, hence I really like enable/disable/letter/number/on/off as well.

I want to limit to these, you defined at your post.


You could actuelly use something like this to do the same:
PLUGIN_EVENT_ATTRACK_MODE|ENABLE DISABLE ON OFF"

ENABLE DISABLE take care if the ATTRACK MODE is ON (Enabled) or OFF (Disabled).
when the attrackmode is enabled, ON = OnActive, and Off=NoActive.

If you do that above, all FEATURES would simple been deleted, only AUTOPLAY. I think I rename that to JUKE_SONG_PLAYMODE(AnyText) for the same.

Ok I agree ..... I will use ENABLE/DISABLE to indicate that the ATTRACT_MODE feature is allowed or not allowed and then I will use ON/OFF to indicate whether it is active or not.

I also like you new name "JUKE_SONG_PLAYMODE(AnyText)" to simply inform the plugin about various play modes which the jukebox is in.   I am assuming you will be listing this next to the other "JUKE_SONG_xxx" commands and then simply removing all "JUKE_FEATURE_xxxx" commands from the bottom.

Also, I do not need the "DOONCE" or "DOALWAYS" but I put them there since I thought you needed them for your LOOP song functions....... you can delete them if you do not need them.

So ... I think I am done.   Go ahead and update your first post and I will review it and then will respond in this thread indicating whether I agree to be finally be DONE.

PS: I am going to lunch now, I will return a bit later so give me a bit of time to return ...
Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b19, Another tweak !!)
Post by: Space Fractal on January 15, 2008, 11:27:08 am
I moved the PLAYMODe command.

As I wrote for the FEATURE COMMANDS, just marked them now, so example Barcrest see why they removed, and what he need to do that same. Doing that we doesn't need to have the same features on all jukebox software, since we just can define them.

Some events might named different, but again, it can been configured (if you want to use PARTY_MODE as name and I have a CONFIG_LOCK doing the same, that OK).

Example the credits mode you doesn't have, I can just use the NUMBER feature to info how many credits there is left....  The rest is up to the writer to configure and checking available defined commands them self and suit theirs need.

I think we cant do that more universal now?


Do we see all is agreed for second time? Should we not stat that as V1.01 (due to these many tweaks, even all betas was for 1.0)?

If do, thanks for the debate :D, I do hope I did head more from Barcrest as well other jukebox authors (where is Chris?).

To HeadKaze and LoadMan, do you want to mainstream the new http://www.jukeplugsys.com homepage (it really need a logo)? Please create a profile, and I enable both of you as authors.




Title: Re: Plugins: A Command List using by Jukebox Plugins (!! V1.0b19, Another tweak
Post by: unclet on January 15, 2008, 01:56:55 pm
Please update this RED text:

Quote
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 = (see "PLUGIN_EVENT_CREATE" command definition)


Anyway, I would not wait.  Barcrest, possibly Chris, and plugin authors have simply be waiting for us to declare the design as FINAL.

Once it is final, they can get to coding and possibly discover and report any further tweaks which might be required.

I would just delete all the features, delete anything else you have marked to be removed, define your new "JUKE_SONGMODE" command properly and then we can be done.

Headkaze can then get on with creating updated code as well.

Congratulations and good job !    :applaud:  :applaud:  :applaud:  :cheers:
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 15, 2008, 04:23:31 pm
DONE.

I have removered all brown marked commands and just tell, how they can used by PLUGIN_EVENT.

Now since it final, I have also removed all Beta texts, so its nicely and short. gosh, it took 2 weeks intesivt debate.

To you UncleT:  :cheers: :cheers:

after a long debate and long posts. Just checkout number of posts.

It was very good idea aboat these PLUGIN_EVENT, only one command might not been needed, that is VOLUME_MUTE, but since ALL software (or should) have that featuere I leave that one.


Now it time to code these in in my software. I dedicated release MultiJuke with this system on Sunday. I hope you also wait, but it up to you.
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 15, 2008, 04:27:49 pm
I have not started to code this stuff ...... I will try to get to it some time soon.  I need a little break first   ;)
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 15, 2008, 04:32:21 pm
he he, I understand  :D. I never trough about this long debalt, but it was fun, even it was a bit upset at time. no worry.

I want also a little break...

Now LoadMan, it time to checking for grammatical errors and such and maybe more in-depth text if needed. I do NOT touch this SDK anymore for a while, even if pluginwriters want some stuff tweaked.


I still waiting for hearing about mainsteam the newly created website.
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 15, 2008, 05:30:03 pm

I have not started to code this stuff ...... I will try to get to it some time soon.  I need a little break first   ;)

Wow.  I did not think it would be done so soon!   :o  .

Now LoadMan, it time to checking for grammatical errors and such and maybe more in-depth text if needed. I do NOT touch this SDK anymore for a while, even if pluginwriters want some stuff tweaked.

Thanks Guys.  :applaud: :applaud:

The real world has caught up with me but I will finish that and report back.    8)
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 16, 2008, 11:02:19 am
loadman

Tell me which of the commands I have listed below do you think you would like to be implemented.   Looking at this effort last night for about 10 minutes, makes me seem I have way too much stuff to try to put in.   I do not want to put everything little thing in if no one is going to use it.  I think I would like to do the least amount of work possible to start and then add stuff in when people request the functionality.  If you are going to be the only person writing a plugin, then perhaps I do not need all of the commands I have listed, thus saving me a lot of time.   

1) Do I really "need" to inform the plugin when I am navigating UP/DOWN through the album covers, song list or song queue?   
2) Do I really need to allow a plugin to move songs around in the song queue? 
3) Do I really need the plugin to be able to switch between the Media/Album/Search tab windows?
4) Do I really need to allow the plugin to cycle through the video, cover and lyrics displays?

All of these actions are not going to be present in all software so I would not think you would be offering these functions in a plugin ..... but I guess I do not really know.


Quote
PLUGIN_EVENT_APP_EXIT|""

PLUGIN_EVENT_MEDIA_TAB|""
PLUGIN_EVENT_ALBUM_TAB|""
PLUGIN_EVENT_SEARCH_TAB|""

PLUGIN_EVENT_PLAY|""
PLUGIN_EVENT_PAUSE|""
PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
PLUGIN_EVENT_SKIP|""
PLUGIN_EVENT_VOLUMESET|"NUMBER"
PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
PLUGIN_EVENT_FULLVIDEO|"ON OFF"

PLUGIN_EVENT_PRIMARY_MONITOR_DISP_CYCLE|""
PLUGIN_EVENT_DUAL_MONITOR_DISP_CYCLE|""
PLUGIN_EVENT_FULLSCREEN|"ON OFF"

PLUGIN_EVENT_SONGQ_CLEAR|""
PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF"
PLUGIN_EVENT_SONGQ_RANDOM|"ON OFF"
PLUGIN_EVENT_SONGQ_MOVE|"ENABLE DISABLE"
PLUGIN_EVENT_SONGQ_UP|""
PLUGIN_EVENT_SONGQ_DOWN|""

PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"
PLUGIN_EVENT_IDLEPLAY_RANDOM|"ON OFF"
PLUGIN_EVENT_IDLEPLAY_GENRE|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_GENRE_CYCLE|""
PLUGIN_EVENT_IDLEPLAY_TOP10|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP25|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP50|"ENABLE"
PLUGIN_EVENT_IDLEPLAY_TOP100|"ENABLE"

PLUGIN_EVENT_ENTERSEL_DIGIT0|""
PLUGIN_EVENT_ENTERSEL_DIGIT1|""
PLUGIN_EVENT_ENTERSEL_DIGIT2|""
PLUGIN_EVENT_ENTERSEL_DIGIT3|""
PLUGIN_EVENT_ENTERSEL_DIGIT4|""
PLUGIN_EVENT_ENTERSEL_DIGIT5|""
PLUGIN_EVENT_ENTERSEL_DIGIT6|""
PLUGIN_EVENT_ENTERSEL_DIGIT7|""
PLUGIN_EVENT_ENTERSEL_DIGIT8|""
PLUGIN_EVENT_ENTERSEL_DIGIT9|""
PLUGIN_EVENT_ENTERSEL_CLEAR|""
PLUGIN_EVENT_ENTERSEL_DELETE|""
PLUGIN_EVENT_ENTERSEL_PLAY|""

PLUGIN_EVENT_ALBUM_COVERS_NAV_UP|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_DOWN|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_LEFT|""
PLUGIN_EVENT_ALBUM_COVERS_NAV_RIGHT|""
PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""
PLUGIN_EVENT_ALBUM_COVERS_SEEK_1ST_CHAR|"NUMBER LETTER"
PLUGIN_EVENT_ALBUM_COVERS_SEEK_2ND_CHAR|"NUMBER LETTER"

PLUGIN_EVENT_SONGTRACKS_UP|""
PLUGIN_EVENT_SONGTRACKS_DOWN|""
PLUGIN_EVENT_SONGTRACKS_SELECT|""
PLUGIN_EVENT_SONGTRACKS_RANDOM|"ON OFF"
PLUGIN_EVENT_SONGTRACKS_PLAYALL|""

PLUGIN_EVENT_PLAYLISTS_CYCLE|""
PLUGIN_EVENT_PLAYLISTS_UP|""
PLUGIN_EVENT_PLAYLISTS_DOWN|""
PLUGIN_EVENT_PLAYLISTS_SELECT|""
PLUGIN_EVENT_PLAYLISTS_RANDOM|"ON OFF"
PLUGIN_EVENT_PLAYLISTS_PLAYALL|""


Here is a list which "I think" might be sufficient for now .... let me know what you think:

Quote
PLUGIN_EVENT_APP_EXIT|""

PLUGIN_EVENT_PLAY|""
PLUGIN_EVENT_PAUSE|""
PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
PLUGIN_EVENT_SKIP|""
PLUGIN_EVENT_VOLUMESET|"NUMBER"
PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
PLUGIN_EVENT_FULLVIDEO|"ON OFF"   <-- do you need this???
PLUGIN_EVENT_FULLSCREEN|"ON OFF" <-- do you need this???

PLUGIN_EVENT_SONGQ_CLEAR|"" <-- do you need this???
PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF" <-- do you need this???

PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"

PLUGIN_EVENT_ENTERSEL_DIGIT|"NUMBER"
PLUGIN_EVENT_ENTERSEL_CLEAR|""
PLUGIN_EVENT_ENTERSEL_DELETE|""
PLUGIN_EVENT_ENTERSEL_PLAY|""
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 16, 2008, 10:11:53 pm
posted in wrong post ...... oops

Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 17, 2008, 04:12:00 am
loadman
1) Do I really "need" to inform the plugin when I am navigating UP/DOWN through the album covers, song list or song queue?   
NIMHO  ;)
Quote

2) Do I really need to allow a plugin to move songs around in the song queue? 

Would be cool long term, But just Skip or Next song would do.
Quote
3) Do I really need the plugin to be able to switch between the Media/Album/Search tab windows?
NIMHO  ;)
Quote
4) Do I really need to allow the plugin to cycle through the video, cover and lyrics displays?
NIMHO  ;)

Here is a list which "I think" might be sufficient for now .... let me know what you think:

Quote
PLUGIN_EVENT_APP_EXIT|""

PLUGIN_EVENT_PLAY|""
PLUGIN_EVENT_PAUSE|""
PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
PLUGIN_EVENT_SKIP|""
PLUGIN_EVENT_VOLUMESET|"NUMBER"
PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
PLUGIN_EVENT_FULLVIDEO|"ON OFF"   <-- do you need this???
NIMHO  ;)
PLUGIN_EVENT_FULLSCREEN|"ON OFF" <-- do you need this???
NIMHO  ;)

PLUGIN_EVENT_SONGQ_CLEAR|"" <-- do you need this???
NIMHO  ;)
PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF" <-- do you need this???
NIMHO  ;)

PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"

PLUGIN_EVENT_ENTERSEL_DIGIT0|""
PLUGIN_EVENT_ENTERSEL_DIGIT1|""
PLUGIN_EVENT_ENTERSEL_DIGIT2|""
PLUGIN_EVENT_ENTERSEL_DIGIT3|""
PLUGIN_EVENT_ENTERSEL_DIGIT4|""
PLUGIN_EVENT_ENTERSEL_DIGIT5|""
PLUGIN_EVENT_ENTERSEL_DIGIT6|""
PLUGIN_EVENT_ENTERSEL_DIGIT7|""
PLUGIN_EVENT_ENTERSEL_DIGIT8|""
PLUGIN_EVENT_ENTERSEL_DIGIT9|""
PLUGIN_EVENT_ENTERSEL_CLEAR|""
PLUGIN_EVENT_ENTERSEL_DELETE|""
PLUGIN_EVENT_ENTERSEL_PLAY|""

Cool   ;)
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 17, 2008, 07:22:09 am
sounds good to me ....
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 18, 2008, 12:28:04 pm
I found a command with very bad destripted and is very usable. Hence I changed it to v1.01. It ONLY that one command I changed a bit and is a minor change.

The command I talking about is:
SuggestionFile=Juke_Command("JUKE_SONGLIST_SUGGESTION", "LastPlayedFile")

I think this is the last change I take on the SDK in a while.
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 18, 2008, 01:21:02 pm
fine with me .....
Title: Re: Plugins: v1.00 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 18, 2008, 10:02:59 pm
sounds good to me ....

What 'JUKE_SONG'  commands will you guys be supporting in the near future realistically?
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 18, 2008, 10:24:33 pm
BLUE = supporting
RED = NOT supporting.   

Code is kind of done, testing is complete but I need to do a few more things before releasing ...... just a few more odds/ends:

Quote
PCHAR  Juke_GetPluginInfo();
int    Juke_Initialize(value);
int    Juke_Shutdown(value);
int    Juke_Configure(HWND hWndParent);
PCHAR  Juke_Command(Pchar Namer, PChar Value);

Juke_Command("JUKE_APP_GAINFOCUS","")
Juke_Command("JUKE_APP_LOSTFOCUS","")
UNICODE_SUPPORT$=Juke_Command("JUKE_APP_UNICODE","TRUE or FALSE")

Juke_Command("JUKE_APP_HOST","SOFTWARE NAME")
Juke_Command("JUKE_SONGLIST_ADD_SONG","system|postition|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|more")
Juke_Command("JUKE_SONGLIST_REMOVE_SONG", "position")
Juke_Command("JUKE_SONGLIST_MOVE_SONG", "oldPosition|newPosition")
Juke_Command("JUKE_SONGLIST_CLEAR", "")
Juke_Command("JUKE_SONGLIST_CURRENTPOSITION", "position")
SuggestionFile=Juke_Command("JUKE_SONGLIST_SUGGESTION", "LastPlayedFile")

Juke_Command("JUKE_SONG_START","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
Juke_Command("JUKE_SONG_NEXT","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
Juke_Command("JUKE_SONG_FINISH","")
Juke_Command("JUKE_SONG_RESTART", "")
Juke_Command("JUKE_SONG_SKIP","")
Juke_Command("JUKE_SONG_PAUSE","")
Juke_Command("JUKE_SONG_RESUME","")
Juke_Command("JUKE_SONG_PLAYMODE", "AnyMode")
Juke_Command("JUKE_SONG_FASTFWD_START","")
Juke_Command("JUKE_SONG_FASTFWD_FINISH","")
Juke_Command("JUKE_SONG_FASTREV_START","")
Juke_Command("JUKE_SONG_FASTREV_FINISH","")
Juke_Command("JUKE_SONG_PLAY_POSITION",curPosSecs|totalDuration)
Juke_Command("JUKE_ENTER_ALBUM_VALUE", "VALUE")
Juke_Command("JUKE_ENTER_TRACK_VALUE", "VALUE")
Juke_Command("JUKE_VOLUME_CHANGE", "system|curVolumeLevel|minVolumeLevel|maxVolumeLevel")
Juke_Command("JUKE_VOLUME_MUTE", "TRUE or FALSE")

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

    where "PLUGIN_EVENT_(name)|valueStr" can be one of the following:

    PLUGIN_EVENT_APP_EXIT|""
    PLUGIN_EVENT_PLAY|""
    PLUGIN_EVENT_PAUSE|""
    PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
    PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
    PLUGIN_EVENT_SKIP|""
    PLUGIN_EVENT_VOLUMESET|"NUMBER"
    PLUGIN_EVENT_VOLUMEMUTE|"ON OFF"
    PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
    PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
    PLUGIN_EVENT_SONGQ_CLEAR|""
    PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF"
    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"
    PLUGIN_EVENT_ENTERSEL_DIGIT|"NUMBER"
    PLUGIN_EVENT_ENTERSEL_CLEAR|""
    PLUGIN_EVENT_ENTERSEL_DELETE|""
    PLUGIN_EVENT_ENTERSEL_PLAY|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""

Juke_Command("JUKE_PLUGIN_EVENT_SEND", "PLUGIN_EVENT_(name)|valueStr")

    where "PLUGIN_EVENT_(name)|valueStr" can be one of the following:

    PLUGIN_EVENT_APP_EXIT|""
    PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF"
    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""


retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

    where "retValStr" is of the format "PLUGIN_EVENT_(name)|valueStr" and can be one of the following:

    PLUGIN_EVENT_APP_EXIT|""
    PLUGIN_EVENT_PLAY|""
    PLUGIN_EVENT_PAUSE|""
    PLUGIN_EVENT_FASTREV|"KEYDOWN" or "KEYUP"
    PLUGIN_EVENT_FASTFWD|"KEYDOWN" or "KEYUP"
    PLUGIN_EVENT_SKIP|""
    PLUGIN_EVENT_VOLUMESET|"NUMBER"
    PLUGIN_EVENT_VOLUMEMUTE|"ON" or "OFF"
    PLUGIN_EVENT_VOLUMEUP|"KEYDOWN" or "KEYUP"
    PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN" or "KEYUP"
    PLUGIN_EVENT_SONGQ_CLEAR|""
    PLUGIN_EVENT_SONGQ_REPEAT|"ON" or "OFF"
    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON" or "OFF"
    PLUGIN_EVENT_ENTERSEL_DIGIT|"NUMBER"
    PLUGIN_EVENT_ENTERSEL_CLEAR|""
    PLUGIN_EVENT_ENTERSEL_DELETE|""
    PLUGIN_EVENT_ENTERSEL_PLAY|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""


Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 18, 2008, 10:45:54 pm
Code is kind of done, testing is complete but I need to do a few more things before releasing ...... just a few more odds/ends:

mate..... No rush .  I'm blown away how quickly this all came together.  :o    :applaud:
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 18, 2008, 11:02:55 pm
Well my artwork for my jukebox has not arrived yet  :-[  so I have some free time.  I thought I would be wrapping up my jukebox build instead of coding, but it just did not happen yet.
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 02:54:56 am
UncleT, SOmethings you can do which some unsupported commands:

Why not support JUKE_SONG_NEXT?
It's just the same song as the first song in your queue?

 LCDS can't typical not need show more than 2 songs, hence the command can been good so it avoid to manage the queue. It only why that command is added. Should been easy to add, because you can send this command just after JUKE_SONG_START (check the first song in the queue and send its songinfo to that command, if there is also a last one song in the queue).

Juke_Command("JUKE_SONG_PLAYMODE", "AnyMode"):
Can you not use this command with "Idle Mode On", "Repeat On", "AttractMode NoActive" and "AttractMode Active" messages? Otherwice it should been empty if all modes is off. PLAYMODE is just a message command and can been used with your defined features as well.

Juke_Command("JUKE_APP_GAINFOCUS","")
Juke_Command("JUKE_APP_LOSTFOCUS","")
If you have options to minimize (like to tray) and maximize your software, use them there, elsewice don't support these commands.

ETC the above is just ideas how you could use them in your software.



Im are going to make a SONGLIST plugin to show the queue and hope it show the same in both MultiJuke And UncleT Jukebox.... Im creating this plugin so we can make sure the songlist would work as it should on all software....

The plugin is unicode aware if enabled. PureBasic is strong with UTF8/Unicode/AscII convertings.


Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 04:19:15 am
Why not support JUKE_SONG_NEXT?
It's just the same song as the first song in your queue?
 LCDS can't typical not need show more than 2 songs, hence the command can been good so it avoid to manage the queue. It only why that command is added.

Good point  ;D  It would be more usefull to me than the song queue for what I want to do short term if that makes any diffrence to your priorities  :dunno
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 07:59:48 am
Quote
Why not support JUKE_SONG_NEXT?
It's just the same song as the first song in your queue?

 LCDS can't typical not need show more than 2 songs, hence the command can been good so it avoid to manage the queue. It only why that command is added. Should been easy to add, because you can send this command just after JUKE_SONG_START (check the first song in the queue and send its songinfo to that command, if there is also a last one song in the queue).

Well, this is the easy case ...... but there are other cases which need to be considered as well which were not that straightforward for me to implement at the moment.    I will revisit this issue though.   Keep in mind my software allows the user to randomly insert songs into the queue, delete songs from the queue, clear the queue, move songs around the queue so the "next song" can change at any time.  This is where all the extra functionality of determining the "next" song gets to be a pain ...... although I will revisit this command.

Quote
Juke_Command("JUKE_SONG_PLAYMODE", "AnyMode"):
Can you not use this command with "Idle Mode On", "Repeat On", "AttractMode NoActive" and "AttractMode Active" messages? Otherwice it should been empty if all modes is off. PLAYMODE is just a message command and can been used with your defined features as well.
I could look into using this command for something ....


Quote
Juke_Command("JUKE_APP_GAINFOCUS","")
Juke_Command("JUKE_APP_LOSTFOCUS","")
If you have options to minimize (like to tray) and maximize your software, use them there, elsewice don't support these commands.
If these commands were called "JUKE_APP_MINIMIZED" and "JUKE_APP_RESTORED" then I would use them.   But right now, they are called "GAINFOCUS" and "LOSTFOCUS".  The term "focus" indicates whether the window is the user's current active working window in their environment or not.  Since I do not just have one main window but have many popup windows which can be displayed, then my "main" window will go out/in of focus everytime one of these popup windows are opened/closed.

Again, if you rename "LOSTFOCUS" to be "MINIMIZED" and "GAINFOCUS" to be "RESTORED", then I can use them ..... otherwise this is not worth the effort for me .... however, if you dont I might add these commands myself as PLUGIN_EVENTs ..... so let me know what you think

Quote
The plugin is unicode aware if enabled. PureBasic is strong with UTF8/Unicode/AscII convertings.
My software does not support Unicode, so I guess the plugin will always be disabled for me.
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 08:31:02 am
I wont really change the SDK again for renamed commands and break combatible. It pretty the same if I should use ATTRACKMODE commands for the SCREENSAVER in MultiJuke (even it not the same, it would been usable).

Other applications typical only use one Windows and these commands would been much more sence. So for you you really only can call them under minimize and maximize. In MultiJuke I Send these commands when the Window is lost focus or when the windows is minimized (I cant really see it should use both MAXIMAZED and GAINFOCUS commands?). Maybe I should write a bit indepth about these commands?


For the SONG_NEXT, I recommered to add a function and checking for the queue each time the have changed something in the queue (you cant change anything in MultiJuke). If the string is changed in the new function (In BlitzMax, you can global a strings inside a function), you can resend the command again with the new info.

For My plugini its would never get a TRUE statement for the unicode, sence I have set unicode flag as FALSE by default....

Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 08:51:05 am
Quote
I wont really change the SDK again for renamed commands and break combatible. It pretty the same if I should use ATTRACKMODE commands for the SCREENSAVER in MultiJuke (even it not the same, it would been usable).

Other applications typical only use one Windows and these commands would been much more sence. So for you you really only can call them under minimize and maximize. In MultiJuke I Send these commands when the Window is lost focus or when the windows is minimized (I cant really see it should use both MAXIMAZED and GAINFOCUS commands?). Maybe I should write a bit indepth about these commands?
Well since you call the LOSTFOCUS command when the window loses focus AND when the window is minimized, then it makes sense the command is called "LOSTFOCUS" then.   This is just too much of a hassle to implement in my code to do the same thing as you since I have many windows.    If I implement it then both of our implementation of these commands would be different .... which would not be right, so I chose not to implement it.

Quote
For the SONG_NEXT, I recommered to add a function and checking for the queue each time the have changed something in the queue (you cant change anything in MultiJuke). If the string is changed in the new function (In BlitzMax, you can global a strings inside a function), you can resend the command again with the new info.
Exactly what I have coded now to use ..... just need to use it now  ;D

How do you inform the plugin that "there is no longer a NEXT song"?  Basically, when my song queue becomes empty, I think I should just send a "JUKE_SONGLIST_CLEAR" to indicate the song queue has been cleared ..... or are you sending a "JUKE_SONG_NEXT" command with no data in it?


** Also, I do not think the "JUKE_SONG_NEXT" command should include the "system" data .....
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 09:36:58 am
System data might been used in MultiJuke if rest of the songs in a album was added when a user choiced a song in MulJuke when the no songs is in queue or is curretly played ("no songs is playing"). Im not sure you have have use of it, so you might just set that system to zero. SONG_NEXT is basically the same as first song in queue (even it might been changed by the user).

The AND should read as AND/OR abot the FOCUS (NOT just ADD), MultiJuke send the command when ONE of them was "activated", not wait when both a accoured. It could been better distripted in the document. That is how I used these commands.... Otherwice I and LoadMand have no clue when your software have been minimezed and maximazed, if he want to use these functions.

JUKE_SONGLIST_CLEAR should not been needed here. I personly recommered you to just send empty data. But I guess both methods might works, but last one might been safer.


BTW. I could elsewice add "JUKE_APP_SUSPEND" and "JUKE_APP_RESTORED" as alternative names to these focus commands? Or should I rename to these to? OK with others (I ask that because it now over V1.0 and wont change without I heard).
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 10:25:12 am
Quote
JUKE_SONGLIST_CLEAR should not been needed here. I personally recommend you to just send empty data. But I guess both methods might works, but last one might been safer.
Actually I think plugin authors should be able to handle both of these cases.  If they get a SONG_NEXT command with empty data, then they know there is no "next" song.   If they get a SONGLIST_CLEAR command then they should understand there is no next song either.   As a result, I will leave it up to the plugin authors to code for both cases.


Quote
BTW. I could otherwise add "JUKE_APP_SUSPEND" and "JUKE_APP_RESTORED" as alternative names to these focus commands? Or should I rename to these to? OK with others (I ask that because it now over V1.0 and wont change without I heard).

If we use these commands differently then it still does not matter what you call the commands themeselves ... the problem would be that be do not implement them the same.

What I mean is ...... if MultiJuke is going to use the "LOSTFOCUS" command to indicate the folllowing two things:

1) Application no longer has the focus
2) Application has been minimized

... and my software is only going to use it to support (2), then we are both not implementing this command the same way which would be bad.  As a result, since I can not support (1) then I decided not to support the "LOSTFOCUS" command at all.

 I can only inform the plugin when the application has been "minimized" and "restored".  If you want to add commands (or rename the current ones to) "JUKE_APP_MINIMIZED" and "JUKE_APP_RESTORED" then I can use them, otherwise it will not work for me. 

The correct way to handle this is to keep the "GAINFOCUS" and "LOSTFOCUS" commands, but also add two new commands called "JUKE_APP_MINIMIZED" and "JUKE_APP_RESTORED".    If you do this then the jukebox software can clear indicate what they are doing to the plugin.


Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 10:46:07 am
I add these two commands, so the SDK would still been backward combatible. No need to change the code again.

I can't do sent a SONGLIST_CLEAR from MultiJuke, but only clear the SONG_NEXT info... But for your application its a good idea to use both commands.

That is why I next week will finish a songlist based plugin to test the queue/playlist system ised in various system and make sure it doing that correct....
Title: Re: Plugins: v1.01 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 11:42:47 am
I add these two commands, so the SDK would still been backward combatible. No need to change the code again.

I can't do sent a SONGLIST_CLEAR from MultiJuke, but only clear the SONG_NEXT info... But for your application its a good idea to use both commands.

That is why I next week will finish a songlist based plugin to test the queue/playlist system ised in various system and make sure it doing that correct....


Good .....  I will support the new commands now.


Here is my new command set:

BLUE = supporting
RED = NOT supporting.   

Quote
PCHAR  Juke_GetPluginInfo();
int    Juke_Initialize(value);
int    Juke_Shutdown(value);
int    Juke_Configure(HWND hWndParent);
PCHAR  Juke_Command(Pchar Namer, PChar Value);

Juke_Command("JUKE_APP_GAINFOCUS","")
Juke_Command("JUKE_APP_LOSTFOCUS","")
Juke_Command("JUKE_APP_RESTORED","")
Juke_Command("JUKE_APP_MINIMIZED","")
UNICODE_SUPPORT$=Juke_Command("JUKE_APP_UNICODE","TRUE or FALSE")
Juke_Command("JUKE_APP_HOST","SOFTWARE NAME")

Juke_Command("JUKE_SONGLIST_ADD_SONG","system|postition|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|more")
Juke_Command("JUKE_SONGLIST_REMOVE_SONG", "position")
Juke_Command("JUKE_SONGLIST_MOVE_SONG", "oldPosition|newPosition")
Juke_Command("JUKE_SONGLIST_CLEAR", "")
Juke_Command("JUKE_SONGLIST_CURRENTPOSITION", "position")
SuggestionFile=Juke_Command("JUKE_SONGLIST_SUGGESTION", "LastPlayedFile")

Juke_Command("JUKE_SONG_START","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
Juke_Command("JUKE_SONG_NEXT","system|title|artist|album|genre|totalDuration|TrackNr|AlbumNr")
Juke_Command("JUKE_SONG_FINISH","")
Juke_Command("JUKE_SONG_RESTART", "")
Juke_Command("JUKE_SONG_SKIP","")
Juke_Command("JUKE_SONG_PAUSE","")
Juke_Command("JUKE_SONG_RESUME","")
Juke_Command("JUKE_SONG_PLAYMODE", "modeTextString")
Juke_Command("JUKE_SONG_FASTFWD_START","")
Juke_Command("JUKE_SONG_FASTFWD_FINISH","")
Juke_Command("JUKE_SONG_FASTREV_START","")
Juke_Command("JUKE_SONG_FASTREV_FINISH","")
Juke_Command("JUKE_SONG_PLAY_POSITION",curPosSecs|totalDuration)

Juke_Command("JUKE_ENTER_ALBUM_VALUE", "VALUE")
Juke_Command("JUKE_ENTER_TRACK_VALUE", "VALUE")

Juke_Command("JUKE_VOLUME_CHANGE", "system|curVolumeLevel|minVolumeLevel|maxVolumeLevel")
Juke_Command("JUKE_VOLUME_MUTE", "TRUE or FALSE")

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

    where "PLUGIN_EVENT_(name)|valueStr" can be one of the following:

    PLUGIN_EVENT_APP_EXIT|""
    PLUGIN_EVENT_PLAY|""
    PLUGIN_EVENT_PAUSE|""
    PLUGIN_EVENT_FASTREV|"KEYDOWN KEYUP"
    PLUGIN_EVENT_FASTFWD|"KEYDOWN KEYUP"
    PLUGIN_EVENT_SKIP|""
    PLUGIN_EVENT_VOLUMESET|"NUMBER"
    PLUGIN_EVENT_VOLUMEMUTE|"ON OFF"
    PLUGIN_EVENT_VOLUMEUP|"KEYDOWN KEYUP"
    PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN KEYUP"
    PLUGIN_EVENT_SONGQ_CLEAR|""
    PLUGIN_EVENT_SONGQ_REPEAT|"ON OFF"
    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON OFF"
    PLUGIN_EVENT_ENTERSEL_DIGIT|"NUMBER"
    PLUGIN_EVENT_ENTERSEL_CLEAR|""
    PLUGIN_EVENT_ENTERSEL_DELETE|""
    PLUGIN_EVENT_ENTERSEL_PLAY|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""

Juke_Command("JUKE_PLUGIN_EVENT_SEND", "PLUGIN_EVENT_(name)|valueStr")

    where "PLUGIN_EVENT_(name)|valueStr" can be one of the following:
   
    PLUGIN_EVENT_APP_EXIT|""
        (application has exited)
   
    PLUGIN_EVENT_SONGQ_REPEAT|"ON" or "OFF"
        (song queue repeat button is turned ON/OFF)
   
    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON" or "OFF"
        (idle play button is turned ON/OFF)

    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
        (album covers were flipped backward)

    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""
        (album covers were flipped forward)



retValStr = Juke_Command("JUKE_PLUGIN_EVENT_GET", "")

    where "retValStr" is of the format "PLUGIN_EVENT_(name)|valueStr" and can be one of the following:
   
    PLUGIN_EVENT_APP_EXIT|""
        (application should exit)

    PLUGIN_EVENT_PLAY|""
        (click the PLAY media button)

    PLUGIN_EVENT_PAUSE|""
        (click the {AUSE media button)

    PLUGIN_EVENT_FASTREV|"KEYDOWN" or "KEYUP"
        (KEYDOWN = start fast reversing the song)
        (KEYUP   = stop  fast reversing the song)

    PLUGIN_EVENT_FASTFWD|"KEYDOWN" or "KEYUP"
        (KEYDOWN = start fast forwarding the song)
        (KEYUP   = stop  fast forwarding the song)

    PLUGIN_EVENT_SKIP|""
        (click the SKIP media button)

    PLUGIN_EVENT_VOLUMESET|"NUMBER"
        (set the volume level directly)

    PLUGIN_EVENT_VOLUMEMUTE|"ON" or "OFF"
        (turn volume mute ON/OFF)

    PLUGIN_EVENT_VOLUMEUP|"KEYDOWN" or "KEYUP"
        (KEYDOWN = start increasing the volume)
        (KEYUP   = stop  increasing the volume)

    PLUGIN_EVENT_VOLUMEDOWN|"KEYDOWN" or "KEYUP"
        (KEYDOWN = start decreasing the volume)
        (KEYUP   = stop  decreasing the volume)

    PLUGIN_EVENT_SONGQ_CLEAR|""
        (click song queue CLEAR button)

    PLUGIN_EVENT_SONGQ_REPEAT|"ON" or "OFF"
        (turn song queue repeat button ON/OFF)

    PLUGIN_EVENT_IDLEPLAY_ACTIVATE|"ON" or "OFF"
        (turn idle-play activate button ON/OFF)

    PLUGIN_EVENT_ENTERSEL_DIGIT|"NUMBER"
        (click specific enter selection number button)

    PLUGIN_EVENT_ENTERSEL_CLEAR|""
        (click CLEAR enter selection button)

    PLUGIN_EVENT_ENTERSEL_DELETE|""
        (click DELETE enter selection button)

    PLUGIN_EVENT_ENTERSEL_PLAY|""
        (click PLAY enter selection button)

    PLUGIN_EVENT_ALBUM_COVERS_FLIP_BACKWARD|""
        (flip album covers page backward)

    PLUGIN_EVENT_ALBUM_COVERS_FLIP_FORWARD|""
        (flip album covers page forward)



Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 12:33:50 pm
headkaze
I have a VB problem I just noticed and perhaps you can help.

problem solved .... nevermind
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 12:39:30 pm
you should include this to you homepage and/or in a readme file for your software. I create mine soon. Still messing about few commands list. It one of the harder one (JUKE_KEY_EVENT_GET). I still make sure it can compile under both Windows and Linux (without the plugin system).

You have mightbeen checking the speed of your mouse whn you moving you mouse? You could code it, so it only is a "user interaction" when the mouse is moved about 5 pixels from the original position when the idle mode was activated.....
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 12:55:11 pm

Quote
you should include this to you homepage and/or in a readme file for your software. I create mine soon. Still messing about few commands list. It one of the harder one (JUKE_KEY_EVENT_GET). I still make sure it can compile under both Windows and Linux (without the plugin system).
This is already embedded inside my jukebox application.  I might add it to my homepage but I think I might be too lazy to change all that stuff ....  :P

Quote
You have might been checking the speed of your mouse whn you moving you mouse? You could code it, so it only is a "user interaction" when the mouse is moved about 5 pixels from the original position when the idle mode was activated.....
I have no idea what I am checking ... I got the mouse hook stuff from somewhere online.  I just know it used to work like a charm and only inform me when the mouse actually moved.    :dunno
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 01:56:58 pm
I hope you get it to work 100%, otherwice make a ektra check how much the mouse is moved (the mouse event might accuar even 1 pixels or such).

Im are not far from finish and guess I can get it finish a beta tomorrow. But I do wait to you to been finished to and release your beta or release. I need to checking if the GET command actuelly works as it should from a plugin. Hence I create a simple sample test later.

Im only missing to add the shutdown feature I have in my app (of course a Event feature).


Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 02:10:39 pm
Yeah I decided to do what you recommend and simply look for mouse movement and not hook the mouse events .... works better .....    :applaud:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 02:21:46 pm
I have never used such a hooks in my own application, since it act like most (BLitzMax) games would do.

Otherwice I have added all commands my software can support, but I need some internal testing before release.

I have also added the new command from v1.02 too. MultiJuke will send a JUKE_APP_MINIMIZED and then JUKE_APP_LOSTFOCUS just after. If just the windows focus is lost, MINIMIZED is not send.

But it seen we soon have working versions using this system soon  :D. I guess we create a new thread about it. PM me when you are ready. Barcrest you can pm me to, if you want a simulate release in same thread (or you could doing that job, UncleT?).
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 02:42:25 pm
I would just release a new software version of my jukebox like I normally do.   If you make a thread before me, then I can simply add to it later and vice versa ... no big deal.
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 04:16:31 pm
Ok, I wrapped everything up much quicker than I thought .....

The new v3.0 of my jukebox software can be found at my site. 

    http://unclet.arcadecontrols.com/Jukebox/

I also added a new section for PLUGINs as well. 

Let me know how it works .....  I will not officially announce the release until I see it is working with some plugins ....
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 06:22:03 pm
Ok, I wrapped everything up much quicker than I thought .....

The new v3.0 of my jukebox software can be found at my site. 

    http://unclet.arcadecontrols.com/Jukebox/

I also added a new section for PLUGINs as well. 

Let me know how it works .....  I will not officially announce the release until I see it is working with some plugins ....

so far so good  :applaud:

Q)  How often are you firing the 'JUKE_PLUGIN_EVENT_GET'?  I was thinking it might be good to have the polling a configuarable value option?  What do you think?.  Depending on the speed of your system you may wish to adjust that?   :dunno 
   I was just thinking on a slow system you might have to accept that you only get this once once a sec and on a fast every 10ms   :dunno  And testing to have that slowed down (or even turned off) might be handy  ;)
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 07:19:31 pm
Congra, UncleT  :cheers:

I release my own one tomorrow or one of the fellow days, when I got more testing. Mine would just update with a new version number from 1.06 to 1.07 (Plug-in support is just a another new feature, even it major).

In MultiJuke I simple do that in each screen flip which is updated 30FPS, so it about 33.33ms timer I use (if it dosent skip a frame over). In MultiJuke's Jukebox GUI the FPS can been set at 60 fps, which the ms would been 20 (this is due with smooth scrolling).

JukeplugSys.com
I have the http://www.jukeplugsys.com domain based on wordpress. I think all plug-in releases should realease that soon as well host using this system. Something Headkaze and Loadman can help me with (please register on the homepage) and also create some content on it?
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 08:33:04 pm
JukeplugSys.com
I have the http://www.jukeplugsys.com domain based on wordpress. I think all plug-in releases should realease that soon as well host using this system. Something Headkaze and Loadman can help me with (please register on the homepage) and also create some content on it?

What do we want to use this minisite for?  Can you leave attachments on it?

I think documentation should be on the wiki personally so anyone can add to it. but plug-ins can be on the website IMHO
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 08:34:51 pm
Quote
Q)  How often are you firing the 'JUKE_PLUGIN_EVENT_GET'?  I was thinking it might be good to have the polling a configuarable value option?  What do you think?.

Good idea .... now go download v3.01 ..... there is a new "Settings" tab under the Plugins option menu

 ;D
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 09:05:28 pm
Quote
Q)  How often are you firing the 'JUKE_PLUGIN_EVENT_GET'?  I was thinking it might be good to have the polling a configuarable value option?  What do you think?.

Good idea .... now go download v3.01 ..... there is a new "Settings" tab under the Plugins option menu

 ;D

About time... Geeeeez   :laugh2:      :applaud:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 09:21:12 pm
I have not used it very much, but it can have I seen, otherwice I just create some space where there plugins can been placed and linked from the website. So I could grant you ftp space for releasing your plugins and for helping me with the website.

IF you want to help me, I can set you as adminstrator for the page? But I need a registration, before I can set a status.

I guess i going to use these Categories when created (havent looked much on this one, due I want codning MultiJuke first):
- News
- Jukebox software
- SDK
- Plugin Releases


I havea lots of space and bandwidth left, and is just added the domain on my normal webhotel. So it only the new domain I paid, not a extra webhotel.

THis domain would been a nice presentation for get attension for other plugin writers and get other jukebox software to get it added into thier system.

The really it need it get a content and a logo, one to website and small one to been used by the Jukeboxsoftware.

NB. I just set your status as editor, loadman.
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 09:45:55 pm
IF you want to help me, I can set you as adminstrator for the page? But I need a registration, before I can set a status.

I have already.

Quote
NB. I just set your status as editor, loadman.
Cool

Good idea .... now go download v3.01 ..... there is a new "Settings" tab under the Plugins option menu
 ;D

Sweet.

I notice that even if a Plug-in is not enabled it still send the plug-in things like:

 int Juke_Initialize(value) 
 int Juke_Shutdown(value)

Is that ok?  Probably is but just checking :-) 
Thinking about it more you really do need to send the shutdown otherwise a plug-in would crash on Jukebox shutdown if you have initialised it.

Cool

As you were  :cheers:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 19, 2008, 09:51:57 pm
Just created some start pages, I hope you are available to edit these. Seen there are bit problems with IE7, cant add links or pictures, but can do add files for the snapshots of software.

I hope HeadKaze would do the same, so he can update the SDK directly on the page as well.
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 19, 2008, 10:05:36 pm
Quote
I notice that even if a Plug-in is not enabled it still send the plug-in things like:

 int Juke_Initialize(value)
 int Juke_Shutdown(value)

Exactly .... the Initialize command must be done when the jukebox application starts for each plugin since this is how it determines whether the plugin is "valid" or not.  If it is valid, then it will be listed on the "Plugins" options page.    Of course, if it was initialized, then it must Shutdown() after.

Glad you like the "Settings" tab I added.  You attached the picture of this Settings page ... are you pointing out a problem with it?
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 19, 2008, 10:24:45 pm
Quote
Just created some start pages, I hope you are available to edit these
I will have a go tonight (AEST)

Glad you like the "Settings" tab I added.  You attached the picture of this Settings page ... are you pointing out a problem with it?

No just showing others of your fine work so they may do the same  ;)
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 20, 2008, 06:19:36 am
Loadman, Seen you edited the start page, but its a new page, so I guess I moved it into "About" page instead and let this is the start page.

When the pages is finished we can so use the news for any new releases.


For The Timer, I really use 33.33ms timer for mine.... But MultiJuke works a bit diffencent.
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 20, 2008, 12:34:06 pm
Will someone please go into the http://www.jukeplugsys.com site and change the current snapshot of my jukebox software for me to this one (it is the 5th screenshot from the top located at my site)

http://unclet.arcadecontrols.com/Jukebox/snaps/snap05full.jpg


btw:  Good job on the site ......
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 20, 2008, 01:53:24 pm
done  :D. Since you are one of authors of this projects, I can give you editor status if you register on the page.

I diddent countinue on the queue plugin, but instead near finish a basic remote plugin to test out the functions in MultiJuke also works.... It still not finished (missing some features, as you can see on the LOOP button), but that one would been good to fix bugs, if the plugin didden't do as it should.... I release it on the homepage soon when done as long with MultiJuke.

Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 20, 2008, 04:01:14 pm
Quote
done 
Thanks

Quote
Since you are one of authors of this projects, I can give you editor status if you register on the page.
I registered already this morning, but I doubt I will spend time updating the site.  I just do not like updating webpages and such.    I am just happy to be done updating the software and updating my own site so I can now get back to finishing up my jukebox build.    :)
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 20, 2008, 05:29:57 pm
Quote
but instead near finish a basic remote plugin to test out the functions in MultiJuke also works...

Cool


I am just happy to be done updating the software and updating my own site so I can now get back to finishing up my jukebox build.    :)

Don't forget to post pictures  ;D
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 20, 2008, 05:39:46 pm
Quote
Don't forget to post pictures
Of course .....   :applaud:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 21, 2008, 11:47:53 am
2 software is released with this system. We still missing Freebox and maybe DWJukebox...
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 21, 2008, 12:45:39 pm
 :cheers:   :cheers:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 21, 2008, 02:37:22 pm
I was bored at work so I decided to update the Wiki ........

http://wiki.arcadecontrols.com/wiki/Jukebox_Plug-Ins

Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 21, 2008, 04:25:22 pm
2 software is released with this system. We still missing Freebox and maybe DWJukebox...

I'm sure they will come onbaord with encouragement, support and time  ;)

I was bored at work so I decided to update the Wiki ........

http://wiki.arcadecontrols.com/wiki/Jukebox_Plug-Ins


I just had a quick look but very nice formatting  :applaud:
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on January 21, 2008, 06:24:38 pm
I changed the formatting a bit around BackGround fact, But I do really like the formatting on the SDK itself.

I might remove all html tags and replace them with wiki tags sooner of later.
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on January 21, 2008, 06:54:26 pm
Yeah, I did not understand the wiki tags at all.  I would have liked to do color, but had no idea how to do that.

Also, I discovered by accident that when the text is not fully left justified, then it is all placed into a box  ...... oh well ... I just went with what I figured out and ran with it.

Do what you want with it ... no worries from me ...... I was just really bored at work today.   ::)
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on January 21, 2008, 08:23:56 pm
..... I was just really bored at work today.   ::)

I wish I was   :o
Title: Re: Plugins: v1.02 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on February 10, 2008, 03:17:22 am
2 software is released with this system. We still missing Freebox and maybe DWJukebox...


C'mon guys  ;D
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on February 10, 2008, 04:51:29 am
Barcrest is linked to the JukePlugSys.com in his homepage, if you check the frontpage out. So I assume version 4 would support it.

So I Guess this would not been supported it in version 3, since he only want to bug fixes issues and doesn't add new feature anymore.

Instead He want to get version 4 finished, which is now in beta state for registered costumers. So I hope he got it added this system to version 4.

I do understand that.

Chris (Author of DWJukebox), any change you add this system to the Windows version? Should I send you the little "wrapper" i used in MultiJuke?


Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 05, 2008, 07:21:47 pm
Hi there. Just joined this forum after lurking on and off for a while.

I've written a jukebox application and am interested in supporting the JPS.
My app is written with Delphi 7. I don't know what the rest of you use.

I'm new to dll's but have had a quick play and am learning fast!
Is anyone here willing to give me some pointers on the host code?

edit:
I've just worked out how to talk to a juke plugin in Delphi.
My main question is do I have to support more than one plugin at once?
If so, do you keep the references to them in an array?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 05, 2008, 08:54:43 pm
Hi there. Just joined this forum after lurking on and off for a while.
Welcome

Quote
I've written a jukebox application and am interested in supporting the JPS.
My app is written with Delphi 7. I don't know what the rest of you use.
I write my Plug-in in Delphi but I think Unclet's Juke is in VB6


Quote
My main question is do I have to support more than one plugin at once?
Yes Please

Quote
If so, do you keep the references to them in an array?
:dunno  Pass


Ahhh pass
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on March 05, 2008, 10:15:37 pm
If you are going to write a plugin supporting the JPS then you are going to need to support the functions listed at the beginning of this post (page 1).

The main ones are:

Juke_GetPluginInfo
Juke_Initialize
Juke_Shutdown
Juke_Configure
Juke_Command

When my jukebox software (written in VB6) starts, it looks into my "plugin" directory to see if any plug files exist in there.  If there are files existing then I loop through each plugin file and determine whether the above routines exist or not.   IF they do not then I do not consider it a valid plugin file.   If the routines do exist, then I call the "Juke_Initialize" routine in the plugin so it can perform any init stuff it needs to and I also call the "Juke_GetPluginInfo" routine to get the plugin name, author, etc... information (which I display inside my software).

I store all of the "valid" plugins in an array.  Whenever I need to send a command to a plugin then I simply loop through my "valid" plugin array and send the command to each plugin by calling the "Juke_Command" routine in the plugin.

Hope this helps some ...... "headkaze" wrote most of the VB6 class module logic which I am using since I had no experience with plugins before implementing all of this JPS stuff.   He is the main guy who might be able to explain the lower level detail stuff if you have more specific questions.   Basically, "headkaze" figured out how a VB6 application can send stuff to a plugin DLL file and how the plugin could return stuff back to the jukebox application when desired.

I just kind of followed what headkaze wrote and that helped a lot.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 06, 2008, 01:35:05 am
OK, a couple of hours of fiddling around and I now have the basic Delphi host code running. It finds all the JPS dll's in the App/Plugins directory and generates the list. It also sends a Juke_Initialize command to each plugin at startup and a Juke_Shutdown to each plugin when it terminates. So far, so good!
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 06, 2008, 03:00:08 am
OK, a couple of hours of fiddling around and I now have the basic Delphi host code running. It finds all the JPS dll's in the App/Plugins directory and generates the list. It also sends a Juke_Initialize command to each plugin at startup and a Juke_Shutdown to each plugin when it terminates. So far, so good!

Cool, It would be cool to post a simpleexample of a Delphi Host to add to the SDK if you could post one.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 06, 2008, 04:55:16 am
No problem. I'll post a host example when I'm sure it's working the way it should. Today was a big learning curve but I'm glad I stuck at it.  :)
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 06, 2008, 06:32:50 am
personly you should use linked list, not array, so you dosent have a limit on number of plugins. Otherwice set a limit to 32 or something like that.

Otherwice I use BlitzMax for my jukebox app, and Pure Basic for the dll examples.

When you release your jukebox application, let us known, so we can add your application on the homepage.

welcome onboard.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on March 06, 2008, 07:02:38 am
I meant to tell you that my jukebox software allows each plugin to be "Enabled" or not via the "Plugin menu" page.   Basically, on the plugin page my application lists all of the plugins found by their name, author, description ,etc... and then allows the user to check which plugins they want to be enabled.   This allows the user to keep different versions of plugins in the "plugin" directory without having the software try to use them all.  When the user highlights a plugin from my list then they can also press a "Configure" button to configure the plugin.  Actually, when this button is pressed then my software simply calls the "Juke_Configure" function of that plugin.   The plugin itself will display a pop up window with all the configuration options it allows.

Good luck
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 06, 2008, 07:17:51 am
Space Fractal:
I've coded it with classes & lists, not arrays so there's no real limit.
Aussie Juke (my program) was released a couple of weeks ago:
Aussie Juke page (http://www.audiovisualdevices.com.au/software/aussiejuke/aussiejuke.php)

unclet:
Good idea for the enable option. I'll add it to the Plugin class now.
I've added all the basic functions to my app now but will have use the event logger to check them.

Got so much done today! Next on the list will be a configuration window I guess.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 06, 2008, 08:47:03 am
I have just added your software to http://wiki.arcadecontrols.com/wiki/Aussie_Juke, but please correct the info about your application and add a screenshot (I can done that for you). If you are not sure how to update the wiki, let me known, then I update it.

Even your app can show coverarts from albums, I have threated your software as singles, since your GUI look like it was suited for Singles. The only problem I actuelly found is the coverart is show in very low resolution on my high resoulution screen. Why not rescale it to the resolution used?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: unclet on March 06, 2008, 11:22:48 am
Any chance of putting a few screen shots of you jukebox application on your site?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 06, 2008, 04:28:43 pm
Yes, it's singles format only at the moment. Still working on the albums part.

With the cover art, I'm just using an image control with the stretch mode on.
Maybe it's to do with the way I'm scaling the whole form?

I'll have to add those screen shots. It's on the list - honest!
The real reason is that the GUI is still in a state of flux at the moment.
I find that one of the more difficult things to get looking right.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 07, 2008, 05:02:41 am
Just uploaded version 1.6.0.0 which has support for a lot of the JPS functions. I tested it with loadman's event logger. About the only major thing missing in my JPS implementation if the configure command. That's simply because I don't have a configuration window for the GIU yet.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 07, 2008, 05:11:20 am
You need to doing something to add the configure command, elsewice the plugins can't been configure by the user, like the sound plugin I have in the SDK.

I have same problem in MultiJuke, so I dedicated to just hide the main window, and then create a another config window just for configure plugin JST. I could nothing do other thing....

You could even create a new exe for config plugins if you need that.

I think you should do for the same.


Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 07, 2008, 05:14:18 am
simply because I don't have a configuration window for the GIU yet.

But isn't the Plug-in the bit that creates the Configure window (for the Plug-in) and the Jukebox just calls it?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 07, 2008, 05:19:30 am
Sorry, should have made that clearer. My app doesn't have anywhere to show the button that you need to press to call up the plugin window. Make sense?

I could map it to a hot key, but if there's more than one plugin, how would you specify the one you want to configure? As unclet said, I need a way of viewing the various plugins and individually enabling / disabling them, as well as sending them a config command.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 07, 2008, 05:27:14 am
Sorrry for being dumb   :banghead:

Here is a screen shot of UncleT's Plug-in configure window

Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 07, 2008, 06:06:18 am
Thanks. I'll look at doing some more on this over the weekend.
Almost all of the host plugin code is in one Delphi class.
It worked out rather nicely even if I do say so myself.  ;D
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 07, 2008, 11:30:03 am
Either you can create a standalone application to the config (which could been included in the SDK as well) or as you wrote, use a speciel hot key for that... Then it can bring up the config window for JST.

In MultiJuke I dedicated to look some thing like that in the screenshot. Since I disabled the pulldown, where you select your plugins, is just because I only have one plugin installed when I created that screenshot.....

If you want to design your diffecent, fell free to do.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 07, 2008, 04:44:39 pm
I'm now a fan of having the configure for Plug-in within the app.

MaLa does not have that yet. You currently have to make a stand alone .exe for configure
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 07, 2008, 06:48:42 pm
Gee, and I just wrote one! (http://www.users.on.net/~avd/aussiejuke/JPS_Config.zip)
I've also integrated it into Aussie Juke and it seems to work nicely.

Thanks for your help guys.
When I've finished testing the Delphi host code, who shall I send it to for inclusion in the SDK?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 07, 2008, 08:35:43 pm
Gee, and I just wrote one! (http://www.users.on.net/~avd/aussiejuke/JPS_Config.zip)
I've also integrated it into Aussie Juke and it seems to work nicely.

Thanks for your help guys.
Looks and feels nice

Thanks that works well.  It also highlights my coding error in my plug-in not finding the logfile saved from that last use . I will fix that

I noticed that your config does not have an enable checkbox......yet

As UncleT said that is very useful.

http://forum.arcadecontrols.com/index.php?topic=75083.msg807733#msg807733 (http://forum.arcadecontrols.com/index.php?topic=75083.msg807733#msg807733)
When testing and using multi versions it is handy to be able to enable and disable plug-ins on the fly.

But up to you really

Quote
When I've finished testing the Delphi host code, who shall I send it to for inclusion in the SDK?
You can send to Headkaze or just post it here (zipped) for him to collect.

I will PM him now so he knows to expect it
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 07, 2008, 08:54:14 pm
The config is really nice. Even it based on a external file, the plugins still see it as it was included in the jukebox application.

Nice job.

I do found a really small minor error, since the window width is about few pixels to small in the default Vista skin. Please large it by about 10 pixels. The height seen to been fine.

Then please update the wiki about your application (that link I gave for some posts ago).

(This post is edited a bit to sync for the loadman post, that came before me)
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 07, 2008, 09:05:58 pm
loadman:
The version built into Aussie Juke does have the enable check boxes. I didn't see any need for them in the external tool as all it does it is activate the config function on the selected plugin.

Space Fractal:
I'll check out the size issue. Can you post a screenshot of the effect you're seeing please?

With regard to the wiki page. it says I don't have a valid username.
Do I need to sign up for that section separately?
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 07, 2008, 10:01:02 pm
With regard to the wiki page. it says I don't have a valid username.
Do I need to sign up for that section separately?

Just use your BYOAC forum login and password
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 08, 2008, 02:23:03 am
Nope. Still won't log me in. Who knows.  :dunno
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 08, 2008, 03:27:14 am
Nope. Still won't log me in. Who knows.  :dunno

Ahh You may be screwed because you have an underscore in your name. I seem to recal another user had an issue once

Post something in the Wiki Discussion for help
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 08, 2008, 04:21:33 am
I've updated the host tool and also made an event viewer.
They can be found here. (http://www.users.on.net/~avd/aussiejuke/JPS%20Tools.zip)
There's nothing wrong with what you guys have made.
I just wanted to write one to prove the plugin dll code I wrote.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 08, 2008, 04:36:37 am
Nope. Still won't log me in. Who knows.  :dunno

Ahh You may be screwed because you have an underscore in your name. I seem to recal another user had an issue once

Post something in the Wiki Discussion for help
All too hard. Tried all the suggestions. No luck. Maybe I should just delete my account.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 08, 2008, 04:59:55 am
I've updated the host tool and also made an event viewer.
They can be found here. (http://www.users.on.net/~avd/aussiejuke/JPS%20Tools.zip)
There's nothing wrong with what you guys have made.
I just wanted to write one to prove the plugin dll code I wrote.

Nice work :-)

Cool, You probably want to start a new thread about new plugins rather than  thsi SDK one.

Minor point.  Your app only seems to fire commands to the highlighted plug-in rather than all of them I assume that's not how your Juke will handle plug-ins
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: David_AVD on March 08, 2008, 05:05:29 am
Minor point.  Your app only seems to fire commands to the highlighted plug-in rather than all of them I assume that's not how your Juke will handle plug-ins
Yes, that's so you can test them one at a time. The juke app does them all at once. (you can disable them too)
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: loadman on March 08, 2008, 05:12:00 am
Minor point.  Your app only seems to fire commands to the highlighted plug-in rather than all of them I assume that's not how your Juke will handle plug-ins
Yes, that's so you can test them one at a time. The juke app does them all at once. (you can disable them too)


Well Done.  :-)  You are all over this  ;D

I hope to see future posts in this section of the forum about future releases.
Title: Re: Plugins: v1.03 Document API for JukePlugSys (!! DONE, YES FINALLY DONE !!)
Post by: Space Fractal on March 08, 2008, 11:58:29 am
you could ask saint to remove the underscore and replace it with space, so it works with wiki too. Otherwice just let us known here, and one of use would update the wiki. I add your software very soon to jukeplugsys.com (if LoadMan not allready have done that, not checked out).

Here is the screenshot of the problem.

If you wish, you can start a new tread about releases of your software, so we can seperate this thread to JST and your software.

I have just added your software on this link:
http://www.jukeplugsys.com/?page_id=7

Your link is a bit to long. I which http://www.audiovisualdevices.com.au/software/aussiejuke worked, but it wont. You might can add a index.php which just include the aussiejuke.php file.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 09, 2008, 05:18:38 am
Hey, I just noticed this thread got stickyed, even I have not asked about this  :D.

So I changed the topic to been more clear (removed version number and removed the DONE message, which is not needed any more). I also added the link to more information about this project.

Also I have added a note about " char with one of the plugin_event command, and is why I updated to v1.04. I know UncleT didden't like that char in that command, even it stated in the document. MultiJuke does not care about that char, since it just removed it before parsing.
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on March 09, 2008, 06:15:32 am
Hey, I just noticed this thread got stickyed, even I have not asked about this  :D.
So I changed the topic to been more clear (removed version number and removed the DONE message, which is not needed any more). I also added the link to more information about this project.
Also I have added a note about " char with one of the plugin_event command, and is why I updated to v1.04. I know UncleT didden't like that char in that command, even it stated in the document. MultiJuke does not care about that char, since it just removed it before parsing.

Yeah I asked for this to be sticky ;D

Nice Work SpaceFractual !!!
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 05:50:53 am
Loadman: I guess you should spell my name correct.... (I noticed in the post, but diddent bother write about it before now).

A idea to a addation to the SDK:

- I would like the possible to pass the  filename to all command that need that (JUKE_SONGLIST_ADD_SONG, JUKE_SONG_START etc) as the last argument. This mean it would not break the combatible on that change, even the software dosen't pass that file or not. In that way I can use it to find coverart in a Webstat plugin im Planning.

I hear about this idea before I add this argument.



Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 21, 2008, 06:00:16 am
Sounds like a good idea to me. It would open up more possibilities for plugins.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 06:09:21 am
I PM Uncle'T about this. Since the  document is mostly made by me and uncle'T. He should agree first.

The filename addations about first addations to SDK could been great for a song preview for the songs that just have been added to the queue.

but the preview idea would not been possible if no songs is in queue and no songs is played, but that feature should been aksed directly to the author instead).

This idea came from the other thread about Idea:.
WaitTimeInMS=Juke_Command("JUKE_SONG_FINISH","")
A song is played finish and it wait this number of MS, before it start the next song.

This mean a Sound FX, ads or other can been played before the next song from a plugin.

Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 21, 2008, 06:24:44 am
This idea came from the other thread about Idea:.
WaitTimeInMS=Juke_Command("JUKE_SONG_FINISH","")
A song is played finish and it wait this number of MS, before it start the next song.

This mean a Sound FX, ads or other can been played before the next song from a plugin.

This works when there's only one plugin, but what happens when there's more than one?
Each of the plugins could return a different value. Which one does the juke app use? The largest?
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 06:35:09 am
Typical this should only been needed by one plugin.

But you right.

If two plugins return a value, the software should of course use the largest value. If a plugin return a 0 and there is allready a ongoing timer, it should not reset that value.

Mightbeen this is not a good idea and should been dropped. Other idea doing a addation?

I guess the  filename addation (first idea) to these 4 commands is a good idea throuch.
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 21, 2008, 06:40:45 am
The filename addition is a good idea and won't break anything.
I just added it to Aussie Juke. Very easy. Only a few lines of code.

Using the return value of Juke_Command("JUKE_SONG_FINISH","") will require more thought.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 06:46:31 am
the major problem is what it would do if a user press a key to try to start a new song, pause ETC? I think the return value should been dropped, since that have some pitfalls and not easy to mainstream. Instead this should up to the jukebox author, if they want to add this feature them self.

I add the filename addation to my software, I hope Uncle'T like that idea. In MultiJuke this was only required 3 code lines for all 3 commands. Theses is:

 JUKE_SONGLIST_ADD_SONG
 JUKE_SONG_START
 JUKE_SONG_NEXT


When I got a green light from UncleT (if it ok with him) I change the first post.
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 21, 2008, 06:56:55 am
I already have an option in Aussie Juke to wait for n seconds between queued songs.
If the ads / FX were all the same length that would work.

The only other way is for the plugin to signal the juke app to stop/pause as soon as
soon as the song finished. It would then have to restart the play queue when it had
finished playing the ad / FX. This would be hard to implement in existing juke apps.
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 21, 2008, 07:00:07 am
I add the filename addation to my software, I hope Uncle'T like that idea. In MultiJuke this was only required 3 code lines for all 3 commands. Theses is:

 JUKE_SONGLIST_ADD_SONG
 JUKE_SONG_START
 JUKE_SONG_NEXT


I've been meaning to ask; when should the juke app send the JUKE_SONG_NEXT command?
Is it as soon as a new song moves to the top of the play queue?
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 07:11:02 am
It could pause the song directly after a new song through a KeyEvent, if it have been defined by the software. If so, it would been possible to do a pause/unpause tricks instead, which would do the same. If the user try to unpause while playing a sound from the plug-in, tell the jukebox software to pause that song again.

Of course this is required the jukebox software to have defined such a command to been used trough PLUGIN_EVENT command.

Because of that, this idea is dropped.


JUKE_SONG_NEXT:
Yes, it used by Sound Wav as well, so the plug-in doesn't need to perform the queue/playlist the software use.

And yes, Its practical the same as the first song in the queue.

In MultiJuke it actuelly the second song, since I use a different songlist system, hence JUKE_SONGLIST_CURRENTPOSITION is set to 1 here. Not all JB software does need that JUKE_SONGLIST_CURRENTPOSITION command yet.
Title: Re: Plugins: Document API for JukePlugSys
Post by: unclet on March 21, 2008, 07:12:38 am
Sorry, I Have been quite busy lately ...... I will try to look at this tonight when I get home, but it might have to wait until this weekend possibly.

It seems you are requesting the filename path be added as the last parameter to the following commands

  JUKE_SONGLIST_ADD_SONG
  JUKE_SONG_START
  JUKE_SONG_NEXT

Is this correct?

As for the JUKE_SONG_NEXT command being sent ...... my software sends this command any time a new "next song" exists.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 07:15:14 am
also filename with full path, otherwice you correct. Should I add this to SDK?
Title: Re: Plugins: Document API for JukePlugSys
Post by: unclet on March 21, 2008, 08:31:58 am
You can add it to the SDK if you want.  If I have trouble supplying the path for some reason then I would simply supply a "nullstring" instead of the file path.  I would assume I would be able to supply the path though, but I have been wrong before so I need to check first  :P
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on March 21, 2008, 08:46:13 am
You can add it to the SDK if you want.  If I have trouble supplying the path for some reason then I would simply supply a "nullstring" instead of the file path.  I would assume I would be able to supply the path though, but I have been wrong before so I need to check first  :P

 :P
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 21, 2008, 08:53:09 am
I guess you doesn't have full path saved to the database? This might because you require the users to have attract same folder structure as you have... But, you should take advance about it and simply "join" them again. Something like this:

Code: [Select]
...\MusicDirectoryPath1
      \Artist1                   
         \Album1
            \01 - Song1.mp3

to

MusicDirectoryPath1\Artist1\Album1\01 - Song1.mp3

So it should been no problem.


SDK updated to v1.05 with  the filename addation. I also wrote not all software might send this.
Title: Re: Plugins: Document API for JukePlugSys
Post by: unclet on March 21, 2008, 09:45:32 pm
Made the updates you requested ........

Quote
Version 03.13

Added: The JUKE_SONGLIST_ADD_SONG, JUKE_SONG_START and JUKE_SONG_NEXT plugin commands were updated to include the full filename path of the song file.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 22, 2008, 05:30:28 pm
The hompage have been updated. I got my friend to create a little logo for the JPS. The logo is not 100% finalized (but about 95%). When then, I upload a bigger version of it as well.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 25, 2008, 12:46:43 pm
The homepage have been changed with my own code instead using WordPres. This allow a much easier to upload plugins from diffecents authors, and then pick automatich from the php script. I do not do someting to the frame, but the content was a higher priotity by now.

I do need to create category when needed and requested.

Soon I pm all JPS "masters" for a account to been upload thiers plugins (and update them). Now it pretty simple and cant nearly do anything wrong. That part need to been created first throuch.

Hope your folks like it.

NB. All content from the wordpres version, includning accounts have been deleted, and I have not saved anything about names, emails etc info.

[ANOTHER EDIT]
I have updated webpage again and have little distription on own page. Since I removed the last database I have rewrote it again. I might add some mistakes. Please verify the text and the screenshot is OK.

Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on March 25, 2008, 07:27:59 pm
You have been busy  ;)
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on March 25, 2008, 09:58:35 pm
Well done Space Fractal, it looks great!  :applaud:
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on March 26, 2008, 07:50:36 am
thanks. Its php site

Im also going to create some sort of admin script, so you guys can upload plugins yourself. Until then just PM me with details, and I'm are happy to include any plugins and updates.

Any plugin writes can until then also info me about coming soon plugins, if any.

I might have missed some (I guess one plugin from AussieJuke)?

.... and no, I have of course not tried to promote my own products throuch the site more than others.
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on March 27, 2008, 07:23:32 am
(http://www.jukeplugsys.com/logo.png)

It's growing on me  ;D
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on April 04, 2008, 07:42:26 pm
api updated to 1.06 to destription how Directory Format should been used (which we all was agree in the another post).

Other few mistakes is corrected which is found while (and still) doing a WebInfo plugin (finally test all JUKE_SONGLIST and JUKE_SONG commands in a real useable plugin which is my second one).

Of course since these commands is still not tested in a plugin, it accoured some bugs in MultiJuke too, which I got fixed and then soon update as long with this plugin.

I do need to test with Uncle'T Jukebox and Aussie Juke as well.
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on April 05, 2008, 12:06:48 am
Nice work as always  ;D
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on April 12, 2008, 10:55:20 am
how goes it about writing plugins? I diddint have time to write on my WebInfo in this week, since I have some other work done first. I do should been finsish with this plugin in the next week.
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on April 12, 2008, 10:26:48 pm
I've just uploaded version 1.2.0.0 of the JPSAttractSounds plugin. (http://www.users.on.net/~avd/aussiejuke/JPSAttractSounds.zip)

Fixed: Was giving an error when triggered with no sound files in directory.
Improved: Status bar shows a countdown of the attract and gap timing.
New: Can be set to also start attract sounds upon JUKE_SONG_PAUSE.


Space Fractal:
Is there a way for us to upload new plugins and update the JPS pages yet?
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on April 13, 2008, 06:09:33 am
No, I diddent have time to look on the admin part of the JPS in this week too. I update your very soon (DONE).

I have send PM for a temporary method for youself to upload.
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on April 13, 2008, 06:30:50 am
Can't see any new messages. Anyway, thanks for updating it for me.  ;D

Still working on the JPS Sound FX plugin. Just have that issue where it crashes if you shut it down while a sound is playing.  :banghead:
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on April 13, 2008, 06:33:42 am
just sent now (but I actuelly not sure I got the PM sent? Otherwice I try again, if you diddent have). You is a to bit to fast  :D

... can you not close down all played files when the software send a Juke_Shutdown function?

Do you use DirectShow or such? I did have simular issue when used the sound commands from PureBasic directly, which used DirectShow. It was also crash on exits too, and got it workaround with using a seperate thread. Hence I changed to bass when I created SoundWav which diddent have that issue.
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on April 13, 2008, 08:25:24 am
JPSAttractSounds works fine... a least in MultiJuke v1.1.5 I release later today. I release very soon with comply of bug fixes to JPS). Auto Attract is not necessity to show to the user. a normal user does not known what these commands does. Event it send a JUKE_SONG_FINISH or not, it should of course been enabled directly from the start. This should been a normal behavior. Just my cent here.

You could even create a option to use the JUKE_SONGLIST_SUGGESTION command instead using your own player routine (a user chooice in the config). But normally these sounds is not been used in the music database. Hence this plug-in would been a good show chase for get this command to work.



Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on May 24, 2008, 07:47:24 am
Can't see any new messages. Anyway, thanks for updating it for me.  ;D

Still working on the JPS Sound FX plugin. Just have that issue where it crashes if you shut it down while a sound is playing.  :banghead:

How is that going anyways ?
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on May 24, 2008, 08:30:03 am
I havent have the time to finishe mine, due to the mala website and playing to much Xbox in the past ;-). I do hope do I finally release the web based plugin last in this or next month.
Title: Adding JUKE_GAMESTART and JUKE_GAMEEND to JPS?
Post by: Space Fractal on June 05, 2008, 10:18:12 am
Since I turning MultiJuke into a FE, but I want to keep JPS for all part.

So I thinking if I could add these 2 commands for that (args not covered yet):

JUKE_GAMESTART
JUKE_GAMEEND

I dosen't think I ever would need other commands than these, due any other features can been coved in the plugin communaction set as well?
Title: Re: Plugins: Document API for JukePlugSys
Post by: AussieJuke on June 05, 2008, 05:00:33 pm
Can you give us an example of their usage?  ???
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on June 05, 2008, 05:39:53 pm
Juke_Command("JUKE_GAMESTART", "romname|title|company|year|genre|category|players|nrbuttons|controller|button help")

This command is used when a game is launced by the user in the frontend part. Some tags above might require controls.dat and catver files, but not all info is not required to send.

When the user exists the game with ESC or such button, JUKE_GAMEEND is simply invoked with no argument.

These commands have no use in a dedicated jukebox application, but these combinered jukebox & frontend applications (like MultiJuke will turn into with all music part intact).

Oterhwice I would create a external file can been invoked for smartLCD application (or other apps), even this would been included or not..... So no big issue if not included.

Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on June 06, 2008, 11:03:03 pm
You could adopt the MaLa Plug-in concept.  The data is sent on game select.

EG
Juke_Command("JUKE_GAMESELECT", "romname|title|company|year|genre|category|players|nrbuttons|controller|button help")

Juke_Command("JUKE_GAMESTART",)

Juke_Command("JUKE_GAMESTOP",)

That way the plug-in (like a LCD display for example) can update before you start the game.
You also need an option to either send the updated details as you scroll through the game list OR just send these details when you stop scrolling like MaLa does.

Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on June 07, 2008, 05:25:01 am
JUKE_GAMESELECT is not a option, due I can't use this command, and event not have a use of that command as well, due my FE actually work very different than MaLa do.

So I do still think these 2 commands cover all for using with Jukebox software with addition FE (and not the other way).

But, if I do want MaLa concept, I think its better to support MaLa Plugins directly (which I might support, but not in first version).

[SORRY for many edit]
Title: Re: Plugins: Document API for JukePlugSys
Post by: Space Fractal on June 30, 2008, 02:37:41 am
after developing future in the MultiFE, it look like i only need one new command at all:

Its JUKE_GAMESTART.

The rest can been used using PLUGIN_EVENT commands, since they either only use on and off statement, or a number. The above is needed, because there is no string can been sent trough by PLUGIN_EVENT. A Another way could also been able to send string to these events as well, by no only one letter or number can been used. Would been nice if STRING can been used.

NB. I can't really use the Mala Plug-In, due that way I use the list, and it even directly impossible when Jukebox GUI is used. MultiFE is of course different than Mala and Mamewah, otherwise I diddent started to write this one.

NB. If this command is not added to the official SDK, I do add this command else Wise, but I do warn about this to plug-in writes as this is NOT a standard command, not used in the official SDK. Any plugins that is only MultiFE compatible, would not been downloadable from the official JPS site (but only from the MultiFE site).
Title: Re: Plugins: Document API for JukePlugSys (use strings with plugins_events)
Post by: Space Fractal on July 15, 2008, 11:48:14 am
I just think how I can send a string to a plugin without broke the SDK with new commands at all:

I simply use send a adress pointer to a NUMBER defined PLUGIN_EVENT where the string is in the memory. The string itself in memory use a OGG formatted TAGS about various info about the game.

More Info soon how to use strings in PLUGIN_EVENTS when I document that in the MulfiFE F.A.Q. Section (soon).

I hope I dosent got any memory invaild issues, since it not tested yet....
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on September 02, 2008, 11:50:19 pm
What about this for an idea:

http://forum.arcadecontrols.com/index.php?topic=84049.0 (http://forum.arcadecontrols.com/index.php?topic=84049.0)
Title: Re: Plugins: Document API for JukePlugSys
Post by: loadman on April 15, 2009, 12:21:07 am
A plugin to trigger a mirror ball and light (via a relay)

very 70's