Main > Audio/Jukebox/MP3 Forum
Plugins: Document API for JukePlugSys
headkaze:
--- Quote from: loadman on January 09, 2008, 12:26:01 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?
--- End quote ---
It's nothing to do with the size of the string the problem is were returning a PChar (char pointer) to a local variable. That local variable is just that, local to the function and once the Jukebox software returns from the function call you can't be guaranteed the memory where that PChar was pointing to will still be available. Having that global buffer and copying strings into it then returning a PChar to the buffer is no problem because we know it will be around for the life of the plugin.
Space Fractal:
only standard define set should been defined, that cover all software.
otherwise we have many unused commands, that might only to been used in one single software. That is not a global standard. A singles based Jukebox software have other set of commands to control response (LETTER and NUMBERS). Should we cover them too?
The main problem is NOT the queue and playing based commands, but its ONLY with CONTROLS based commands, that allways is defficent by various software.
CONTROLS is the main reason for various software out here, so of course they are all diffecent. So we can't cover them all here.
I can also accept SCREENSAVER example can named something other and such that thing. they are not CONTROLS.
So I think these 3 is needed for CONTROL based plugins (to feed a sample plugin) before config:
JUKE_CONTROL_CREATE|ACTION_BUTTON_1
to use them:
JUKE_CONTROL_SEND|ACTION_BUTTON_1|ON) <- can been ON or OFF (LedWiz).
and
JUKE_CONTROL_GET <- If a user pressed a key on a remote control.
And then it would cover all controls used (also ONLY controls based commands, think as user with a remote control) and I would been fine.
The sdk is changed to only use these 4 functions, headkaze gave. Later I list the defined commands (that is not controls based). I out now, and update the list when I went home.
unclet:
--- Quote ---only standard define set should been defined, that cover all software.
--- End quote ---
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.
--- End quote ---
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?
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
I have no idea what you are trying to do here ... sorry. :dunno
Space Fractal:
See the changed SDK.
I have now changed the SDK to nearly have your system now, I think is very good.
I have just changed few commands, removed few uneeded arguemtns, and added some other commands as well.
queue.txt is also removed and replaced with some PLAYLIST commands. Hope you like it. There is also some changes about the song info here too.
The major problem about controls using your and mine vision is replaced with KEY EVENT, which i explain what it does:
The whole main problem about various commands we talk very much about is been changed to just use KEY_EVENT, which I guess is a good workaround and a comprimes.
I can see on your UncleT Jukebox homepage, there is overer 70 key mappings provided in your software. It them that have been the the whole point in my Plugin Vision, and it only them, I might have interesed using these KEY_EVENT to been used for some plugins, like sound, ledwiz and others uses.
MultiJuke is a button based jukebox software, where KEY_EVENT would been very strong for the PlugIn. Of course I would let a plugin to use all KEY_EVENTS I have in my software (all buttons) to been controlled. Here KEY_EVENT is a major use.
This is includning Action buttons I have in my software: They are no other than a user KEY_EVENT, also a user keypress to invoke some command in my Jukebox.....
So I think KEY_EVENT is the right word to use?
Because of that, I removed all navigations commands you have, I removed from the SDK. But use the power of KEY_EVENT commands for these navigation commands (like I would due in MultiJuke).
unclet:
headkaze .... please answer this for me
--- Quote ---There is no need for a trailing "|" at the end of the paramter list
--- End quote ---
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
--- End quote ---
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
--- End quote ---
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
--- End quote ---
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
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version