Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
unclet:
I agreed 100% it would be nice to have one plugin work with many jukebox software without having to change the pluging at all ...... but come on .... do you really think that is feasible? Look how fast people write plugins and how fast they ask software developers to support more routines to allow them do what they want to do in their plugins. If someone asks me to support a new routine, should I first make sure whether all other jukebox software is going to support it, before I implement it myself? That does not make that much sense to me.
This is why coming up with a standard routine list is handy along with a list of what jukebox software supports what routines. I think the effort to "standardize the routines" (and their parameters) which might be used by various jukebox software applications would be much more powerful. For example, my software does not sipport coin credits at all. But lets say I decide to put this feature into the software 6 months from now, I would not create my own plugin routine for this, but instead use the standard plugin routine defined by Space Fractal ...... this is where the value of "standardization" comes in ...... in my opinion.
Space Fractal
I know I could populate the ID3 Tag information with the proper information from my database, but I think this would be misleading to plugin authors. They would assume that if my software supports the ID3 Tag routines, then this information is actually coming from the ID3 Tag information located in the music file itself ..... and this would not be the case. It would be much more clear and correct to simply state that my software does not support the ID3 Tag routines.
Space Fractal:
JukeSelectedtags is renamed to JukeSelectedSong.
Credits features is now completed removed.
The idea about remote controlled was think ed with unclet in mind here. I just need to change bit to trying to fit all software due with deficient command sets. Something I have oversaw here?
I left screensaver by now, but again I can remove these commands and move into the command api instead (because they can add screensaver commands in the list)?
And the list the database command is removed. It was really bad here. Could go to the speciel tag instead if needed and can left empty if not used.
loadman:
--- Quote from: unclet on January 04, 2008, 09:17:18 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.
--- End quote ---
: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:
removed screensaver functions at all !!
A plugin writer can of course make a screensaver feature in their configuration if a sceensaver is needed. So screensaver features is NOT needed at all. Removed them.
I might add these 2 completly optimal credits functions back, because I wanted to create a statics plugin who did pay song and which songs they have paid (for MultiJuke, Freebox, and other that used credits). Why I added them.
Barry Barcrest:
--- Quote from: 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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version