Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news


  

Author Topic: Plugins: Document API for JukePlugSys  (Read 63802 times)

0 Members and 1 Guest are viewing this topic.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Plugins: Document API for JukePlugSys
« 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:

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




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


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

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

1.03: IMPORTANT: PLUGIN_EVENT_CREATE renamed to JUKE_PLUGIN_EVENT_CREATE

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

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



Directory Format for Plugins:

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

    JukePlugSys\
     \JPSAttractSounds.jps
     \JPSAttractSounds.ini
     \JPSAttractSounds.txt

  • A Plugin can can even want to create a subfolder to, if it plans to use many support files or folders, like this:

    JukePlugSys\
     \JPSAttractSounds\ (folder)
     \JPSSoundFX\ (folder)
       readme.txt (can been any filename)
       any other files or more subfolders
     \JPSAttractSounds.jps (file)
     \JPSSoundsFX.jps (file)



MAIN DLL FUNCTIONS DEFINED:

These functions should been defined by a DLL.

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


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

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

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

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


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



APPLICATION COMMANDS:


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

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

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

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

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

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


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

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

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


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

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

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



PLUGIN_EVENT COMMANDS:

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

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

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


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

where:

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

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

Examples:

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

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

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

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

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

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

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

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

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



SONGLIST COMMANDS:

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


Juke_Command("JUKE_SONGLIST_ADD_SONG",
"system|postition|title|artist|album|genre|totalDuration|TrackNr|AlbumNr|more|FileName")

Add a song into that position in the songlist.

Info about arguments:

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

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

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

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

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

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

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

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

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


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

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

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

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

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




SONG PLAYING COMMANDS:

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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




DIGIT COMMANDS:

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

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

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



VOLUME COMMANDS:

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

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

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




FEATURE COMMANDS:

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



SDK for these commands:

« Last Edit: April 04, 2008, 07:36:57 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #1 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$) ;

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: debating about functions needed by Jukebox Plugins......
« Reply #2 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:


« Last Edit: January 03, 2008, 07:39:04 pm by unclet »

Barry Barcrest

  • I'm only in it for the lack of money
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1606
  • Simple Plan
    • E-Touch Jukebox
Re: debating about functions needed by Jukebox Plugins......
« Reply #3 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.

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #4 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  ;)
« Last Edit: January 03, 2008, 08:14:18 pm by loadman »

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: debating about functions needed by Jukebox Plugins......
« Reply #5 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.
« Last Edit: January 03, 2008, 08:26:24 pm by unclet »

Barry Barcrest

  • I'm only in it for the lack of money
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1606
  • Simple Plan
    • E-Touch Jukebox
Re: debating about functions needed by Jukebox Plugins......
« Reply #6 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #7 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.

Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #8 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #9 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 !!
« Last Edit: January 04, 2008, 06:53:21 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #10 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?

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: debating about functions needed by Jukebox Plugins......
« Reply #11 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.

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #12 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..   ???

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #13 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.
« Last Edit: January 04, 2008, 07:43:44 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #14 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)


« Last Edit: January 04, 2008, 07:58:02 pm by loadman »

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #15 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).
« Last Edit: January 04, 2008, 08:44:32 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: debating about functions needed by Jukebox Plugins......
« Reply #16 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.


« Last Edit: January 04, 2008, 09:07:43 pm by unclet »

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #17 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  ;)

« Last Edit: January 04, 2008, 09:31:01 pm by loadman »

Barry Barcrest

  • I'm only in it for the lack of money
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1606
  • Simple Plan
    • E-Touch Jukebox
Re: debating about functions needed by Jukebox Plugins......
« Reply #18 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #19 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?





« Last Edit: January 04, 2008, 09:23:17 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: debating about functions needed by Jukebox Plugins......
« Reply #20 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.
« Last Edit: January 04, 2008, 09:54:02 pm by unclet »

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #21 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.




 
« Last Edit: January 04, 2008, 09:35:08 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #22 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #23 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.




« Last Edit: January 04, 2008, 09:57:02 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

Barry Barcrest

  • I'm only in it for the lack of money
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1606
  • Simple Plan
    • E-Touch Jukebox
Re: debating about functions needed by Jukebox Plugins......
« Reply #24 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.

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #25 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

Barry Barcrest

  • I'm only in it for the lack of money
  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1606
  • Simple Plan
    • E-Touch Jukebox
Re: debating about functions needed by Jukebox Plugins......
« Reply #26 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.
« Last Edit: January 05, 2008, 04:05:18 am by Barcrest »

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4297
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: debating about functions needed by Jukebox Plugins......
« Reply #27 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
« Last Edit: January 05, 2008, 04:46:12 am by loadman »

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #28 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?
« Last Edit: January 05, 2008, 07:28:03 am by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: debating about functions needed by Jukebox Plugins......
« Reply #29 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....
« Last Edit: January 05, 2008, 08:07:35 am by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: plugins: debating about functions needed by Jukebox Plugins
« Reply #30 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.
« Last Edit: January 05, 2008, 08:28:59 pm by unclet »

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: plugins: debating about functions needed by Jukebox Plugins
« Reply #31 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?



« Last Edit: January 05, 2008, 09:05:39 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: plugins: debating about functions needed by Jukebox Plugins
« Reply #32 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.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2929
  • 0x2b|~0x2b?
Re: plugins: debating about functions needed by Jukebox Plugins
« Reply #33 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: plugins: debating about functions needed by Jukebox Plugins
« Reply #34 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).....
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

unclet

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3551
Re: Plugins: debating about functions needed by Jukebox Plugins
« Reply #35 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....
« Last Edit: January 06, 2008, 07:28:27 am by unclet »

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: Plugins: debating about functions needed by Jukebox Plugins
« Reply #36 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?

« Last Edit: January 06, 2008, 07:47:35 am by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2929
  • 0x2b|~0x2b?
Re: Plugins: debating about functions needed by Jukebox Plugins
« Reply #37 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.

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: Plugins: debating about functions needed by Jukebox Plugins
« Reply #38 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 *).
« Last Edit: January 06, 2008, 08:54:15 am by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

Space Fractal

  • Wiki Master
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 1887
  • Space Fractal
    • Space Fractal
Re: Plugins: debating about functions needed by Jukebox Plugins
« Reply #39 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).






« Last Edit: January 09, 2008, 05:13:34 pm by Space Fractal »
Currectly in work: Greedy Mouse || Previous Work: MultiFE Frontend, ArcadeMusicBox Jukebox || Music for various games (Tardis.dk + Greatflash.co.uk).

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31