PlugIns: Common Format (initial concept discussion)

[loadman]

[Edit] This thread orginally related just to UncleT's JukeBox. It has changed into a global discussion about a format standard for JukeBox Plug-ins. The 'ultimate' goal is to be able to use a plug-in on the Jukebox of your choosing [/Edit]

Hi,

It would be great if your UncleT's JukeBox had the ability to support plug-ins. 

A plug-in is essentially a .dll as you probably know.

I write plug-ins for MaLa using Delphi (you can also use C++)

But I understand that your Jukebox software is written in VB6.

Lucklily I think I have found a way to make a VB6 App talk to a Delphi DLL.

See Attached example.

The idea is you copy and paste the code from the example and try it from your JukeBox code. Obviously you put the declarations at the start and the function calls in the appropriate section of your code.

Note: This is only a basic example. The final version would pass more data over at more sections to the plug-in. It would also have some 'smarts' to find plug-ins and if none found carry on regardless.

I think this could work well with hopefully minimal work form yourself.

Have fun and advise your findings/feelings when you get time. 

[headkaze]

The only problem I see with your code is you can only use one dll (one plugin). So not really much of a plugin system.

What you need to do is use the LoadLibrary/GetProcAddress API functions to dynamically load each dll. To do this in VB6 is a bit ugly but I found a way to do it on the web and wrote a small VB6 Project you can see how it works.

Also check out the example here to determine if a function exists in a dll. You can use this to make sure the dll your trying to load is in fact a plugin. So for example you would make sure that every plugin has a function called UTJuke_Check() and use that code in the link to check that function exists in the dll. If it does you know it's a plugin and load it. Remember just because it's a dll doesn't mean it's a plugin as plugin's may use other dll's that are not plugins but need to be in the same folder.

NOTE: VB6 can only use dll's that have exported functions in stdcall format. So when you declare your functions don't use cdecl.

[unclet]

headkaze

Thanks for the example code ...... couple of questions...

It seems the "CallFuncPtr" function is basically setting up memory with the correct addresses and parameters so a call can be made to the function which is implemented inside the DLL plugin.   Is this correct?  If so, then I guess this function can simply be dropped into a VB project and used as is?

Just so I understand the work required for me to allow plugins ......

1) Create a directory where all plugin files (DLL files) will be placed (ex: new "plugin" directory)

2) I will need to define routine names (ex: UTJuke_SongTrackStart(), UTJuke_SongTrackEnd(), UTJuke_SongTrackSkipped(), etc, etc) along with associated parameter lists for each routine so the plugin developers know which routines will be called by my application in case they are interested in implementing these events in their plugin.  Basically, all the routine names/parameters need to be defined for use in all plugins.

3) When a certain event occurs in my jukebox software, then I should loop through all of the plugin files (located in the plugins directory) and verify whether the "UTJuke_Check()" routine exists.  If so, then the plugin (DLL) file is a "true" plugin file.  I should then verify whether the appropriate event plugin API (ex: UTJuke_SongTrackStart(), UTJuke_SongTrackEnd(), UTJuke_SongTrackSkipped(), etc, etc) exists in the plugin file.  If so, then call the "CallFuncPtr" function accordingly.

Am I missing anything?

[Space Fractal]

I guess it would been awesome if we could share the plugin system in all jukebox software (I also think Freebox, MultiJuke and others).

We cant use Male plugins directly because a mame frontend and jukebox frontend work a bit diffecent.

I guess we should use these functions in each correct dll (and maybe more):

int Juke_Config()
Configurere the plugin.

int Juke_Initialise()
Return a value which should been same to avoid other none plugin dlls to been used.

char* Juke_Name()
Return the name of the plugin and point to a string pointer.

int Juke_Status(char *name, float value
Various play status, example

name=PlayedTime -> Played time in secs.

name=play ->

 -1 - Empty (no songs in queue)
 0 - stopped (stopped in a song and would restart in play)
 1 - play
 2 - paused

name=TotalTime -> Song total time.


Juke_StatusTime(int song, int total)

Juke_CurrentTag(char *name, char *value)
The software will send couble of tags to the plugin in a loop and should end with END:

Name could been these:
 TITLE
 ARTIST
 ALBUM
 TIME
 GENRE

Juke_CurrrentTag_UTF8(char *file)
 A UTF8 version of the tag, because some might use unicode.

Juke_Update()
 Update the whole plugin when something is changed. The plugin should only been updated its content (like LCD) when this command is called. It depite more than one status might been updated in one frame.

Juke_Close()
 Close the dll when software exits.


That can of course been use more status and commands, and this might been useable for all Jukebox software. I do not known I want plugin support, because it need to been changed a bit for the Linux version. But I might support this one.

But it would been dump if each software used thier own plugin system, SO i guess this should been shareable with all jukebox out here.

[Barry Barcrest]

I am very interested in getting in on this. One plugin system that can be used by various software would be a nice touch. Anyone else coding jukebox software could also support this plugin standard.

[headkaze]

It seems the "CallFuncPtr" function is basically setting up memory with the correct addresses and parameters so a call can be made to the function which is implemented inside the DLL plugin.   Is this correct?  If so, then I guess this function can simply be dropped into a VB project and used as is?

Yes that function is a hack to get the address of a function in a dll and call it. Its so you can dynamically load a dll which is what you need for a plugin system. Yes you can drop this function into your own VB project and use it as is.

1) Create a directory where all plugin files (DLL files) will be placed (ex: new "plugin" directory)

Yes create a directory where the plugins go like you say "plugin" makes sense. Remember though my other point, a dll won't always be a plugin. For example if someone writes an LED plugin for it it will require ledwiz.dll and/or pacdrive.dll in the plugin folder along with the plugins. So have a special function you check to see if it exists.

ie.

1. Read in plugin\*.dll
2. Check for a special function Eg. Juke_GetPluginInfo() to see if it's a plugin
3. Read details of plugin (this time call Juke_GetPluginInfo())
4. Display a list of plugins you can enabled / disable using a checked listbox. This might require you write a simple "front end" like the "Plugin Manager" I wrote for GameEx.
5. You will need an array that will hold the name of the dll's that are enabled
6. Loop through the array and use CallFuncPtr() to call the appropriate function in each plugin as necessary

2) I will need to define routine names (ex: UTJuke_SongTrackStart(), UTJuke_SongTrackEnd(), UTJuke_SongTrackSkipped(), etc, etc) along with associated parameter lists for each routine so the plugin developers know which routines will be called by my application in case they are interested in implementing these events in their plugin.  Basically, all the routine names/parameters need to be defined for use in all plugins.

Yes you will need a "Plugin SDK" with documentation for each function what is sends/recieves and how to use it. Examples are always helpful. I'm sure loadman can write a few plugins for it to help you test.

3) When a certain event occurs in my jukebox software, then I should loop through all of the plugin files (located in the plugins directory) and verify whether the "UTJuke_Check()" routine exists.  If so, then the plugin (DLL) file is a "true" plugin file.  I should then verify whether the appropriate event plugin API (ex: UTJuke_SongTrackStart(), UTJuke_SongTrackEnd(), UTJuke_SongTrackSkipped(), etc, etc) exists in the plugin file.  If so, then call the "CallFuncPtr" function accordingly.

Yes part of your code will always check the function exists before calling it. You can always add new functions in later releases of the Plugin SDK; checking the function exists first will tell you if you should call it or not.

As in that link I gave you can check a function exists with the following

Code: [Select]

Function IsProcedureAvailable(ByVal ProcedureName As String, _
    ByVal DllFilename As String) As Boolean

    Dim hModule As Long, procAddr As Long
    ' first, attempt to load the module
    hModule = LoadLibrary(DllFilename)
    If hModule Then
        ' then, retrieve the address of the routine
        procAddr = GetProcAddress(hModule, ProcedureName)
        ' finally, decrement the DLL usage counter
        FreeLibrary hModule
    End If
    ' if procAddr is non-zero, the function is available
    IsProcedureAvailable = (procAddr <> 0)
End Function

Am I missing anything?

I think you've got a good grasp of how it works. You will just need to design the plugin dll format and it helps to have C++ experience to do that. For example how do you send over song information to the plugin? Well personally I would use a struct for that.

Code: [Select]

struct SongInfo
{
   char[256] Name;
   char[256] Artist;
   char[256] Album;
};
In VB6

Code: [Select]

Type SongInfo
   Name as String * 256
   Artist as String * 256
   Album as String * 256
End Type
In VB6 you will have to recieve the struct using "ByRef SngInfo As SongInfo". Not sure how that works using the LoadLibrary method. You may need to play around a bit as getting the parameters to match VB6 <-> dll can be a bit tricky. ByRef and ByVal can be important depending on if your sending value types or reference types (int is a value type and a struct is a reference type). A Long is a 32 bit Int in VB6 so you will notice it's used alot in calling API functions.

If you need any more help let me know

[Space Fractal]

Struct can been very messy to use with blitzmax to send the correct to a plugin. Could not get work correctly and was needed to use a Pure Basic to create a wrapper (that also can create DLLS). Hence I would avoid strucs for combatible reason.

Instead why not use OGG UTF8 based strings instead of structs?

Each tag string is ended with a null pointer (chr=0) with the last one ended with double null pointer. Pretty easy to due that in BlitzMax and I like that tag system in OGG. The name it self is ASCII, but value is UTF8 incoded. Example:

ALBUM=album nameNULLARTIST=artist nameNULLNULL


Could been a good comminuty project by BYOAC developers to have one plugin standard for Jukebox software.

Hence mightbe move this topic to Jukebox software to develop a shared plugin event system.

What do others say?

[unclet]

I already asked "saint" to move this topic to the general "Audio/Jukebox/MP3" forum ......

Also, for me, I do not want to spend a lot of time upgrading my software for this capability.   I just personally do not see myself using any of this plugin funcionality so I am not too interested in spending a lot of time upgrading the software.   Now, I do understand how a standardized plugin syntax would be the best way to move forward but I really do not want to spend my time trying to figure out what the common syntax should be ..... just not really interested in this type of stuff myself.

Now, if something was already defined and stable, then I can look into adding this stuff into my jukebox software, but I really do not want to spend time being one of the people who defined all this new stuff ..... . not my cup of tea.

I will wait to see how this all pans out and then at a later date see if I can implement something.    It seems defining a standardized syntax and playing around with everything to see if it works properly is going to take some time.   I would rather have everything working with some plugins already created and then I can try to add some functionality into my software ... perhaps.

[Space Fractal]

Here we should of course documentation so easy as possible, and with examples by various language (Here BlitzMax and Visual Basic).

But I'm are not Visual Basic man, so I guess Barcrest, headkaze, loadman to develop a good plug in system.

We could even use one main dll to connect and let this doing the rest and wrap the functions directly to the plug in(s) used through it.

All events could been triggered into few functions like this:

void Init()
void config()
wchar get(char *name)
DWORD Send(char *name, wchar *value)
void Update()

wchar (not sure it correct) is a 16 bit string due for unicode support (don't known this is easier than UTF8?).

You really doesn't need a bunch of functions, just name and value string and then document them.

What do other think about this system?

[loadman]

The only problem I see with your code is you can only use one dll (one plugin). So not really much of a plugin system.

Agreed.  I should have mentined that too. That example was basic (tee he  ) There would have to be a little more code to make sure that the dll was a plug-in with valid functions etc...  This example to give UncleT an opportunity to play and get a feel for how it would work.

4. Display a list of plugins you can enabled / disable using a checked listbox. This might require you write a simple "front end" like the "Plugin Manager" I wrote for GameEx.

MMM I consider this very nice but more of a 'luxury item'.
MaLa works by saying (in it's logic) . If a plug-in exists in the plug-in folder then it will enable it. If you don't want it enabled then cut and paste to another folder.

Thanks for the example and the links too man   

And Thank's for the general input everyone. 

But I'm are not Visual Basic man, so I guess Barcrest, headkaze, loadman to develop a good plug in system.

Neither am I. This is the first time I have done something beyond 'hello world' in VB. But I don't think I need to be.   With some tips from the net and HeadKaze The VB work should all be 'set and forget' ...just some testing initially. All the hard work is developing cool plug-ins.

Even if UncleT does not ending up implementing it to his software it is still an interesting topic I think.

The Beauty of plug-in's as after it's implemented you can sit back and watch as developers got nuts building stuff. 

Attached is a MaLa log. It is me just starting and stopping MaLa. What it does show is how it looks at the plugins upon startup (not all the time) . There are two plug'ins found here. Note that within this plug-ins these are differences on what funtions are used too . Basically if mala does not find a function in the plug-in it is never called in the future, rather than checking all the time. (That is how I assume it works anyway going from these logs)

2008/01/02  09:38:23.48   Info: Starting MaLa 1.0.3.3
2008/01/02  09:38:23.48   Info: Showing splash
2008/01/02  09:38:23.51   Info: Check plugin directory: C:\Mametable\MaLa v1.0 RC9\plugins
2008/01/02  09:38:23.51   Info: Collecting event plugins (*.mplugin) in C:\Mametable\MaLa v1.0 RC9\plugins\
2008/01/02  09:38:23.51   Info: Found event plugin EmuWave.mplugin
2008/01/02  09:38:23.52   Info: Event plugin EmuWave.mplugin loaded
2008/01/02  09:38:23.52   Info: Function: PluginName found
2008/01/02  09:38:23.52   Info: Function: PluginCopyright found
2008/01/02  09:38:23.52   Info: Event Function: MaLaGameSelected not found
2008/01/02  09:38:23.52   Info: Event Function: MaLaEmulatorSelected found
2008/01/02  09:38:23.52   Info: Event Function: MaLaListSelected found
2008/01/02  09:38:23.52   Info: Event Function: MaLaOrientationSwitch found
2008/01/02  09:38:23.52   Info: Event Function: MaLaScreensaverStart found
2008/01/02  09:38:23.52   Info: Event Function: MaLaScreensaverSwitch not found
2008/01/02  09:38:23.52   Info: Event Function: MaLaScreensaverStop found
2008/01/02  09:38:23.52   Info: Event Function: MaLaAttractModeStart found
2008/01/02  09:38:23.52   Info: Event Function: MaLaAttractModeStop found
2008/01/02  09:38:23.52   Info: Event Function: MaLaGameStart found
2008/01/02  09:38:23.52   Info: Event Function: MaLaGameQuit found
2008/01/02  09:38:23.52   Info: Event Function: MaLaStart found
2008/01/02  09:38:23.52   Info: Event Function: MaLaQuit found
2008/01/02  09:38:23.52   Info: Event Function: MaLaTreeUp found
2008/01/02  09:38:23.54   Info: Event Function: MaLaTreeDown found
2008/01/02  09:38:23.54   Info: Found event plugin Speech.mplugin
2008/01/02  09:38:23.56   Info: Event plugin Speech.mplugin loaded
2008/01/02  09:38:23.56   Info: Function: PluginName found
2008/01/02  09:38:23.56   Info: Function: PluginCopyright found
2008/01/02  09:38:23.56   Info: Event Function: MaLaGameSelected found
2008/01/02  09:38:23.56   Info: Event Function: MaLaEmulatorSelected not found
2008/01/02  09:38:23.56   Info: Event Function: MaLaListSelected not found
2008/01/02  09:38:23.56   Info: Event Function: MaLaOrientationSwitch not found
2008/01/02  09:38:23.56   Info: Event Function: MaLaScreensaverStart not found
2008/01/02  09:38:23.56   Info: Event Function: MaLaScreensaverSwitch not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaScreensaverStop not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaAttractModeStart not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaAttractModeStop not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaGameStart found
2008/01/02  09:38:23.57   Info: Event Function: MaLaGameQuit not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaStart found
2008/01/02  09:38:23.57   Info: Event Function: MaLaQuit found
2008/01/02  09:38:23.57   Info: Event Function: MaLaTreeUp not found
2008/01/02  09:38:23.57   Info: Event Function: MaLaTreeDown not found
2008/01/02  09:38:23.62   Info: Check backup directory: C:\Mametable\MaLa v1.0 RC9\backups
2008/01/02  09:38:23.62   Info: Loading hook dll
2008/01/02  09:38:23.76   Info: Loading params from ini file
2008/01/02  09:38:23.81   Info: Setting params from ini file
2008/01/02  09:38:23.81   Info: Creating and loading mame info pages: C:\Mametable\MaLa v1.0 RC9\mame.mli
2008/01/02  09:38:23.81   Info: Creating and loading other emu info pages: C:\Mametable\MaLa v1.0 RC9\otheremu.mli
2008/01/02  09:38:23.81   Info: Creating and loading filter sets: C:\Mametable\MaLa v1.0 RC9\mala.mlf
2008/01/02  09:38:23.81   Info: Creating and loading non mame emulators: C:\Mametable\MaLa v1.0 RC9\mala.mle
2008/01/02  09:38:23.81   Info: Creating and loading layout ...
2008/01/02  09:38:23.81   Info: Collecting layout files (*.mll) in C:\Mametable\MaLa v1.0 RC9\
2008/01/02  09:38:23.81   Info: Creating and loading mala tree
2008/01/02  09:38:23.81   Info: Collecting game list files (mlg) in C:\Mametable\MaLa v1.0 RC9\
2008/01/02  09:38:23.81   Info: Creating and loading bios
2008/01/02  09:38:23.87   Info: Creating audio object
2008/01/02  09:38:24.06   Info: Creating and loading mala lcd screens
2008/01/02  09:38:24.06   Info: Creating and loading mame lcd screens
2008/01/02  09:38:24.06   Info: Creating and loading jukebox lcd screens
2008/01/02  09:38:24.06   Info: Creating and loading led config and attroct mode list
2008/01/02  09:38:24.06   Info: Collecting attract mode files (*.mlc) in C:\Mametable\MaLa v1.0 RC9\
2008/01/02  09:38:24.06   Info: Loading game list: C:\Mametable\MaLa v1.0 RC9\All Games.mlg
2008/01/02  09:38:25.98   Info: Hiding splash
2008/01/02  09:38:25.99   Info: Loading layout: C:\Mametable\MaLa v1.0 RC9\standard.mll
2008/01/02  09:38:28.38   Info: Destroying audio object
2008/01/02  09:38:28.52   Info: Writing params to ini file
2008/01/02  09:38:29.18   Info: Showing taskbar
2008/01/02  09:38:29.18   Info: Closing MaLa 1.0.3.3

[unclet]

Ok, I am in a holding pattern with building my jukebox cabinet.   I need to wait until my artwork is completed and printed out so I can then match the colors of the actual artwork for the paint I wish to use.   Anyway, since the artwork is still being developed by my brother (who is on vacation for a few days) I have some free time.   

Anyway, I decided to update my software with everything headkaze has recommended.  It allows for plugin files to be placed in a new directory, allows the plugins to be enabled/disabled via a new Options menu and also has logic to process certain events which occur.  Thing is I do not have a true plugin to test if any of the code headkaze recommended actually works ....   

So ..... if someone would like to create a plugin DLL file with the following APIs defined, then I can test it:

1) Juke_GetPluginInfo() API routine which I can call so I can determine whether the plugin DLL file is a true "jukebox plugin"

2) Juke_SongStart() API routine which I can call when a song starts.  The plugin should pop up a message box indicating the "song has started" ..... for testing purposes.

3) Juke_SongEnd() API routine which I can call when a song ends.  The plugin should pop up a message box indicating the "song has ended"..... for testing purposes.

[Space Fractal]

Here is it, just a untested coded with message requesters from each function, made in Pure Basic.....

[loadman]

and here is my attempt in Delphi.  Is it OK?

Code: [Select]

library JukePlug;
uses
  Dialogs;
{*******************************************************************************}
procedure Juke_GetPluginInfo(); stdcall;
begin
end;
{*******************************************************************************}
procedure Juke_SongStart(); stdcall;
begin
  Showmessage('Song has started');
end;
{*******************************************************************************}
procedure Juke_SongEnd(); stdcall;
begin
  Showmessage('Song has ended');
end;
{*******************************************************************************}
  exports
  Juke_GetPluginInfo,
  Juke_SongStart,
  Juke_SongEnd;
{$R *.res}
begin
end.

[Space Fractal]

Pure Basic should allready use stdcall calls. The source was included in the file as well. Seen Pure Basic create incredible small exe/dll files.

If both languages works, that would been super.

Hence we just need more functions, but this is a start. Remember some software is button based, other touch based, so we might need to send keypresses which most jukeboxes use (like select and parent, keypad and more, selected entry etc).

[Barry Barcrest]

I will get onto this later today now we have some test plugins i can inerface with to see if it's working that will be great.

Of course the real work does come from plugin authors once the system is in place. Anyone got ant thoughts on plugin config screens like in winamp? I assume we add a button to our jukebox software that says config and this calls the config part of the plugin?

So who wants to set up a trigger list so to speak?

[Space Fractal]

Yep, I guess it would been do. There should of course been a Juke_Config() to been called when a plugin want to been configurated..... But not been neded to just a test if that would work.

Im are also going to code the basic things to work in MultiJuke as well and hope both test plugins would work.....

[headkaze]

I will get onto this later today now we have some test plugins i can inerface with to see if it's working that will be great.

Of course the real work does come from plugin authors once the system is in place. Anyone got ant thoughts on plugin config screens like in winamp? I assume we add a button to our jukebox software that says config and this calls the config part of the plugin?

Yes all you would need to do is call a Plugin_Configure() and the actual Plugin author will need to open up a form/window and allow the user to configure the plugin. Once the basic plugin code is in place it's really a piece of cake, as you say the real work will be done by the plugin authors and includes dealing with the configuration GUI for the plugin.

[headkaze]

Okay here is a C++ Plugin test but this time I've added some structs to test so you can see if you can get strings transferring to and from the plugin. Should be pretty straight forward.

Code: [Select]

typedef struct
{
char Name[256];
char Author[256];
char Version[256];
} PluginInfo;

typedef struct
{
char Name[256];
char Artist[256];
char Album[256];
} SongInfo;


Code: [Select]

// JukePlugin.cpp : Defines the entry point for the DLL application.
//

#include "stdafx.h"
#include "JukePlugin.h"

// standard windows headers
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

#define PLUGIN_NAME "Test Plugin"
#define PLUGIN_AUTHOR "Ben Baker"
#define PLUGIN_VERSION "1.0"

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
)
{
    switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
    }
    return TRUE;
}

JUKEPLUGIN_API int __stdcall Juke_GetPluginInfo(PluginInfo *pluginInfo)
{
strncpy(pluginInfo->Name, PLUGIN_NAME, 256);
strncpy(pluginInfo->Author, PLUGIN_AUTHOR, 256);
strncpy(pluginInfo->Version, PLUGIN_VERSION, 256);

return 1;
}

JUKEPLUGIN_API int __stdcall Juke_SongStart(SongInfo *songInfo)
{
char buf[512];

sprintf(buf, "Song has started, Name: %s, Album: %s, Artist: %s", songInfo->Name,

songInfo->Album, songInfo->Artist);

MessageBox(NULL, buf, "Message", MB_OK);

return 1;
}

JUKEPLUGIN_API int __stdcall Juke_SongEnd(SongInfo *songInfo)
{
char buf[512];

sprintf(buf, "Song has ended, Name: %s, Album: %s, Artist: %s", songInfo->Name,

songInfo->Album, songInfo->Artist);

MessageBox(NULL, buf, "Message", MB_OK);

return 1;
}

[Space Fractal]

The main problem, Plugin screens might blocking the main application, due it waiting to the plugin is finished. In Multiuke it might result the main screen would been totally hanging and is not nice.

Can plugin creators create a thread so it dosent block the application? BlitzMax I used in MultiJuke does NOT support threading, but I known Pure Basic does. Hence I would create a framework example in this language.

So another funcion is actuelly needed to checking if the config is closed, so the plugin system can countinue to send event to it.

Like something this:

Juke_Config()
result=Juke_isConfigClosed()  <- BlitzMax does best like integer and is easist to understand.


=====

Strings using limit based arrays is never good and is easy to break. I never use that type of strings in BLitzMax. Blitzmax use dynamic 16 bit strings (unicode). So much easer is do a ogg like encodning instead like I said before and send a pointer to the dll.

wchar should allways been used (unless if it should been incodning to UTF8 unicode standard instead?).

I am currectly looking in my app to test all plugins.

[Barry Barcrest]

Do we really need to check if the plugin has done it's thing? Do we need feedback from the plugins? I think you just send the command and assume it's done what it should. Plugins shouldn't cause the juke to hang that way.

[unclet]

For now .... please define a "Juke_Config()" routine in the plugin so I can test whether this routine can be called properly.

Also, how about renaming "Juke_SongStart" to be "Juke_SongBegin" ....... it seems like the word "begin" compliments the word "end" better. 


headkaze
Regarding the "CallFuncPtr" function you provided ......  how would I call this function when no parameters exist?    It is crashing for me now when I am trying to call the "Juke_SongStart" routine since there are no parameters required.   Perhaps supply me a new "drop-in" VB6 function which allows no parameters to be used ....? 

Regarding you plugin you provided ..... I am assuming all files located in the "Release" directory only should be placed into my "plugins" software directory ... correct?

[Barry Barcrest]

Loadman your plugin was detected as a backdoor trojan and macaffee deleted it?

UncleT can you not call it with a vbnullstring as a parameter? I am only just about to test it out myself as i only just plugged in the required stuff.

[Space Fractal]

I have simular problems. I guess I  now write a main dll to deal with all plugins in Pure Basic (that is very good about dlls).....

I have not a plan to release it as exclusive to MultiJuke, so I would release it as SDK with source code included.

It would been wrote in Pure Basic with unicode strings enabled (16 bit strings).

More info about it later. I might create a new thread. Not sure when it finshed today. I trying to keep it so simple as possible.

[Barry Barcrest]

SWEET i have it working of sorts.... Can somebody help me though as i have hit a problem.

In my module i have,

Code: [Select]

Public Type SongInfo
   Title As String * 256
   artist As String * 256
   album As String * 256
End Type
Then i set up a procedure i call

Code: [Select]

Public Sub do_plugin()
    Dim hDll As Long
    Dim pTEST As Long
    Dim sng As SongInfo
    sng.artist = Form2.txtArtist.Text
    sng.album = Form2.txtAlbum.Text
    sng.Title = Form2.txtTitle.Text
    hDll = LoadLibrary(App.path + "\Plugins\JukePlugin.dll")
    pTEST = GetProcAddress(hDll, "Juke_SongStart")
   
    CallFuncPtr pTEST, sng
 
    FreeLibrary hDll
End Sub
That fails.

Only user difined types defined in public modules can be coerced to or from a variant passed to late bound functions.

What is that going on about?

[Barry Barcrest]

Code: [Select]

Public Sub do_plugin()
    Dim hDll As Long
    Dim pTEST As Long

    sng.artist = Form2.txtArtist.Text
    sng.album = Form2.txtAlbum.Text
    sng.Title = Form2.txtTitle.Text
    hDll = LoadLibrary(App.path + "\Plugins\JukePlugin.dll")
    pTEST = GetProcAddress(hDll, "Juke_SongStart")

    CallFuncPtr pTEST, sng.artist & sng.album & sng.Title
   
    FreeLibrary hDll
End Sub
That works but the juke closes with no errors after i get the message box appear and i click ok... I am lost, maybe i am out of my depth here i don't mind admitting it.

Calling this works fine.

Code: [Select]

    CallFuncPtr pTEST, "TEST"
I think it doesn't like the fact there are carridge returns in the strings i was passing. I'll try a replace on those before i pass them.


EDIT:

Code: [Select]

CallFuncPtr pTEST, sng.artist & sng.album & sng.Title
That causes the DLL to display everything for the artist, then the album and title for album and title for title and then crashes the juke out with no errors... It's obviously how i am calling it any ideas anyone?

[Space Fractal]

In Pure Basic you need to use a global result variable to aviod a crash. Might it can been the problem with using strings.

I'm currectly just got Juke_init() to work in the wrapepr and get all plugin names.

[Barry Barcrest]

In Pure Basic you need to use a global result variable to aviod a crash. Might it can been the problem with using strings.

I'm currectly just got Juke_init() to work in the wrapepr and get all plugin names.

I'm hard coded to the one plugin right now, once i have that confirmed as working i will add the routines to check the plugins folder for valid plugins etc.. Also the proc i am calling needs to be passed a varible so it can call the right function probably using the case mehod..

Case 1 'Song started
Case 2 ' Song ended

So i can just Call do_plugin(1)  or Call do_plugin(2) from the relavent places in my code.

Makes it easier for me as all the plugin stuff is located in one place then if we add more functions i just add more case statmenets and put the calls in the right place.


Related thought i wanted to put out there...

Using this plugin system would it be possible for someone to code a plugin that was essentially a wrapper to allow use of winamp plugins? I am sure it probably could be done or am i on the wrong track here?

Another crazy thought...

Can we grab the DLL display and dump it in a picture box? I do this with active movie right now and i was think it would good for visualisations as i can just put them in the same picture boxes i use for the video at present.

[Space Fractal]

It seen I my self have very trouble to get the pure basic work correctly with blitzmax without invaild memory issues. Look like it dosent like peeked strings for some reason.

That mean I might need to use the thread in the wrapper I going to create and I do not finish this today. But it might fix config and other issues it should across. By now I have and trying to get these functions to work:


Juke_Count()
{count all found plugins}

Juke_Init(path$)
{init and read all plugins in the path by the wrapper and create a thread}

value$=Juke_GetPluginInfo(pluginnumber, tag$w)
{ get name info using "name", author" or version tags", but the wrapper get the info a bit defficent, more info later}

Juke_Shutdown()
{shutdown all plugins }

Juke_Set(pluginname$, value$)
{ using to enable, disable and config a plugin }

result=Juke_Send(function$, value$)
{ this would been retrived plugin as function name + a value as a argument if it exists then return the result }


WHen I got it working I create a new tread as this would been a little Plugin SDK. But it still lots more work to done.





 
[/b]

[Barry Barcrest]

Well i have it working of sorts like i said so all i am waiting for is a list of functions that can be agreed for the plugins. Would be good to have plugins for reading audio file tags. Pass the path and get the tag info back. That would enable support to be increased for different filetypes and tags.

I am at the point where i can do very little now until we can progress with a set list of functions the plugins will have.

[unclet]

I am also having the same trouble Barcrest is having:

I have the following defined

Public Type PLUGIN_DESC_TYPE
     Name As String * 256
     Author As String * 256
     Version As String * 256
End Type

Dim pluginDesc As PLUGIN_DESC_TYPE

I verify the "Juke_GetPluginInfo()" routine exists in headkaze's plugin, but when I use the following code to call the function:

CallFuncPtr pFunctionPtr, pluginDesc

.... I get the same error Barcrest mentioned:

Only user defined types defined in public modules can be coerced to or from a variant passed to late bound functions.

Any idea how to fix this?   Perhaps we should just have three separate parameters (name, author and version) for the "Juke_GetPluginInfo()" routine instead of using a user-defined structure?

I tried searching for an answer via Google, but can not understand what people are talking about ..... 

Let me know .... I am stuck as well until this is resolved. 



loadman
Please change the original post title to be something like "Standardize plugins for Jukebox apps" ...... since it is no longer specific to my Jukebox software ....

[headkaze]

.... I get the same error Barcrest mentioned:

Only user defined types defined in public modules can be coerced to or from a variant passed to late bound functions.

*bangs head* I've only spent the last hour or so trying to work out a way around that error. Here are my conclusions...

Using CallFuncPtr() has it's limitations and these are

- Can't use structs (aka types in VB6)
- Can't send over Unicode strings
- It only works one way, meaning you can't retrieve data from the plugin like plugin info. But I've left the code in there anyway.

It's understandable afterall the CallFuncPtr() function is a hack to get around the limitations of VB6 so it can dynamically load a dll. I won't bother ranting about how much of a headache coding VB6 gives me 

So with these limitations in mind I have come up with some new example code to work from. It has an example VB6 application and C++ dll plugin example.

I've included a nice JukePlugin class that you can use to wrap a plugin with so you can manage each plugin from an array.

Eg. Creating an array of 10 plugins

Code: [Select]

Dim JukePluginArray(10) As JukePlugin

[Space Fractal]

hence that is why I now creating a SDK with a wrapper that dosent use any type of arrays and do all the work using a simple linked list (do arrays).

Does VB6 actuelly support 16 bit strings (unicode), or do they need to been UTF8 strings?

Struct is not needed in that method I trying to use (since they hard in BlitzMax as well that used a diffecent struct method that is not C++ combatible).

BTW can VB6 send a string pointer to a dll?

I wipe out a wrapper tomorrow to avoid software developers not need to create a plugins list and so on.

[headkaze]

hence that is why I now creating a SDK with a wrapper that dosent use any type of arrays and do all the work using a simple linked list (do arrays).

Does VB6 actuelly support 16 bit strings (unicode), or do they need to been UTF8 strings?

Struct is not needed in that method I trying to use (since they hard in BlitzMax as well that used a diffecent struct method that is not C++ combatible).

BTW can VB6 send a string pointer to a dll?

I wipe out a wrapper tomorrow to avoid software developers not need to create a plugins list and so on.

VB6 normally supports Unicode and structs just not with the hack they need to dynamically load dll's. If it was a single dll to load there would be no problem.

[loadman]

loadman
Please change the original post title to be something like "Standardize plugins for Jukebox apps" ...... since it is no longer specific to my Jukebox software ....

Done. Did my Plug-in Work?

Loadman your plugin was detected as a backdoor Trojan and macaffee deleted it?

Hmm Well obviously it isn't.

So with these limitations in mind I have come up with some new example code to work from. It has an example VB6 application and C++ dll plugin example.

Excellent  .  If you could not create Plug-ins in C++/Delphi I would be out  

[Space Fractal]

Can anyone try this SDK? All sources and little documents is in the attachment. I used Pure Basic to create the dll and BlitzMax to connect the wrapper as a example. Hence the dll it self is very small.

I got finally the system to work with BlitzMax which is a bit speciel without crashes. I do not have tested other the example included in the file.

Juke_GetPluginInfo() need to been changed by other plugins by LoadMan and headkaze, before it would work (and not sure stdcall is needed?).

Please update that code need to been done.

What do the others say? I have not looked on the numbers of functions that can been used, which can been expanded without I need update it (only around config). The wrapper is very dynamic, but still should been simple as possible.

I looking on headkaze one tomorrow, its to late now.

[unclet]

loadman
For what it is worth .... your plugin did not have a virus in it for me .... or at least my computer did not detect it   

headkaze
I will look at your example later tonight and see what is going on.   Hopefully I do not have to change everything around too much.

SpaceFractal
not quite sure I understand the whole wrapper idea ...... let me read what headkaze provides for now and see what it is about.

[Space Fractal]

The wrapper idea:
let the wrapper doing the dynamic loading of all dlls and checking for plugin functions and also using a thread for config (which is not created yet). I have also avoid using arrays which have thier limits about the length. All strings (which is 16 bit strings) is simply ended with a null.

For your software, you only need to connect to PluginSDK.dll and no others, so it let do PluginSDK.dll  linked list work it self and also connect to rest of the other plugin dlls, and also doing the work if the functions exists or not.

For plugin writes, this PluginSDK.dll would been connected to the other plugins with only one functions changed (like I wrote).

That is the basic idea and need to been tested by other before I countinue.

You do not really need to use this dll, but I just hope Juke_GetPluginInfo() can been changed to suit this SDK and all functions in a plugin should hold a 16 bit string as argument. That is really what i basically ask. This SDK was actuelly help to dynamic loading all plugins

Other things:
For security reasons (here it nothing by jukebox software it self, but mere about PluginSDK.dll and its plugins), should I rename the dll to something others (Like MALA) and might be due something checking with a md5 file or such? But here I would make sure it actuelly would work before I countinue working on this one.

I also need to doing some save and load configurations, or should this just leave it to plugins creators (using a ini file with the same name as its dll or what it should been named?

[loadman]

Other things:
For security reasons (here it nothing by jukebox software it self, but mere about PluginSDK.dll and its plugins), should I rename the dll to something others (Like MALA) and might be due something checking with a md5 file or such? But here I would make sure it actuelly would work before I countinue working on this one.

Yes, I think you should rename the .dll  to .jukeplugin      (like mala does .mplugin).    After you make your plugin(dll) you just rename the extension manually. I do this all the time.  Of course the jukebox software will need to look for .jukeplugin rather than .dll's

Especially if you have other .dll's in your plug-in folder. If nothing else it make it clear at a glance what the plug-ins are and what are normal dll's

[Space Fractal]

I doing that, loadman, in the next version of SDK. It correctly only search for dll as extension name. the extension name you gave is clear and fine, so I do that. But I wait for other responses around the getinfo changing.

First I need to get you and others to test what I have changed around the getinfo format.

It only that way I got it working in BlitzMax, but hopefully work on others. So can you change it in your plugin example, so Unclet and Barcrest also can test them again (trouch the wrapper or directly)?

NB. I now wait to response to around this change, so I dosent comment anything.

[unclet]

I kind of like the idea of having everyone place their plugins in my "plugins" directory and having my software determine what plugins are valid, having the user being able to enable/disable them and just having complete control on how this is going to work within my software.    Basically, not to crazy about using someone else's wrapper SDK which I have no control over and probably can not update as I see fit in the future .....

Am I misunderstanding something?

Perhaps it will not matter anyway since I am already thinking I am spending way too much time on this enhancement.   I might once again prefer to wait until everyone else has this working 100% before I try to understand what is required and then try to decide whether I should spend my time on this or not.

[unclet]

Actually it seems like updating a text file with the appropriate data when certain jukebox events occur would be a lot easier.    My software can simply generate this sort of  text file all the time with no plugin functionality required at all.   Any 3rd party application can simply act on the file contents whenever the file's date/time stamp changes.

The first line of the file would always be the EVENT which occurred.   Other lines would be an agreed upon format of data.

Seems a lot easier then trying to add plugin stuff to the mix ......  just thought I would throw the idea out there once again ...

[Barry Barcrest]

no

[Space Fractal]

It might been not a good idea, but of course I could update the wrapper to checking a external file as well, using a external a exe file.

The direct comminutaion trouch the plugins or a wrapper is the best idea, since you wont get any returned values from the plugins using the text file way....

[headkaze]

I kind of like the idea of having everyone place their plugins in my "plugins" directory and having my software determine what plugins are valid, having the user being able to enable/disable them and just having complete control on how this is going to work within my software.    Basically, not to crazy about using someone else's wrapper SDK which I have no control over and probably can not update as I see fit in the future .....

Am I misunderstanding something?

Perhaps it will not matter anyway since I am already thinking I am spending way too much time on this enhancement.   I might once again prefer to wait until everyone else has this working 100% before I try to understand what is required and then try to decide whether I should spend my time on this or not.

Did you take a look at my code? All I meant by wrapper was a VB6 class that takes care of all the library calls for you.

Code: [Select]

Option Explicit

Private pDC As Long
Private hDll As Long

Private pGetPluginInfo As Long
Private pSongStart As Long
Private pSongEnd As Long

Private PluginInfo As PluginInfoType
Private SongInfo As SongInfoType

Public Sub Initialize(hDC As Long, PluginName As String)
    pDC = hDC
    hDll = LoadLibrary(PluginName)
      
    pGetPluginInfo = GetProcAddress(hDll, "Juke_GetPluginInfo")
    
    If IsPlugin Then
        pSongStart = GetProcAddress(hDll, "Juke_SongStart")
        pSongEnd = GetProcAddress(hDll, "Juke_SongEnd")
        
        GetPluginInfo
    Else
        Shutdown
    End If
End Sub

Public Sub Shutdown()
    FreeLibrary hDll
End Sub

Public Sub GetPluginInfo()
    If pGetPluginInfo <> 0 Then
        CallFuncPtr pDC, pGetPluginInfo, PluginInfo.Name, PluginInfo.Author, PluginInfo.Version
    End If
End Sub

Public Sub SongStart()
    If pSongStart <> 0 Then
        SongInfo.Name = "Name" + Chr(0)
        SongInfo.Artist = "Artist" + Chr(0)
        SongInfo.Album = "Album" + Chr(0)
        CallFuncPtr pDC, pSongStart, SongInfo.Name, SongInfo.Artist, SongInfo.Album
    End If
End Sub

Public Sub SongEnd()
    If pSongEnd <> 0 Then
        SongInfo.Name = "Name" + Chr(0)
        SongInfo.Artist = "Artist" + Chr(0)
        SongInfo.Album = "Album" + Chr(0)
        CallFuncPtr pDC, pSongEnd, SongInfo.Name, SongInfo.Artist, SongInfo.Album
    End If
End Sub

Public Property Get IsPlugin() As Boolean
    IsPlugin = (pGetPluginInfo <> 0)
End Property

Public Property Get Name() As String
   Name = PluginInfo.Name
End Property

Public Property Get Author() As String
   Author = PluginInfo.Author
End Property

Public Property Get Version() As String
   Version = PluginInfo.Version
End Property
Then to create a plugin it's as simple as

Code: [Select]

Dim plugin As New JukePlugin
plugin.Initialize Me.hDC, "JukePlugin.dll"
plugin.SongStart
plugin.SongEnd
plugin.Shutdown
So you can just have an array of JukePlugin objects. Read in the plugin directory, use plugin.IsPlugin to check if it's a valid plugin, and away you go.

Keep it simple or you will all give up in frustration and it sounds like unclet is already heading that way lol

[Space Fractal]

HeadKaze, do the each strings actuelly used a 0 pointer at end?

I trying to update the SDK to get it work with the same code like above (I guess your plugin example use the same?).

It just the plugin it self that used a array? Here I do not care how they write thier plugins!


=====

I actuelly got HeadKaze's example plugin working. I update SDK to sync his example.

The HeadKaze example do just have few problems:
- The plugin did not return a unicode strings, so it just shown chinese chars (works if disabled in my code).
- ID3v2 Tags does not have any limits in length and can been unicoded.... Here you still have a string limit.

The plugins should checking how long the strings really is which dosent depite on a array limit. It NOT a problem with plugin info, it mere on tags.

I would like to see you updated your source and examples to support unicode. Unicode is very important to been supported. Unicode is just a 16 bit wide strings up to 65kb chars (which BlitzMax example use).

Normally its Wchar instead of char in C++, but not sure.


 

[unclet]

headkaze
Ok, I had a look at your code in more detail.....

1)  I guess by using this "class" you provided then the calls to CallFuncPtr can occur without problems now?

2) In the class file there are routines called SongStart and SongEnd which have hardcoded "Name", "Author" and "Artist" values.  I am assuming I would simply update these routines to have input parameters for these values instead.

3) So there is no need for a separate "Juke_Config()" routine for each plugin now?   I guess all configuration can occur when the "Juke_GetPluginInfo()" routine is called initially.

4) Seems pretty straightforward to me I guess       I would just need to make an array of this new class (one for each plugin) .... like you said previously.   I would still allow the user to enable/disable the plugin as normal, but simply use the class to interact with the plugin.   

5) I found the following link which updates the "CallFuncPtr" code to use threads.   It is 95% the exact same function you provided, but instead of calling the "EnumObjects" API, it calls some thread logic instead.   Might be worth using the CallFuncPtr with threads.  How about checking it out and seeing if it makes sense to use.

http://www.instructurez.com/communities.aspx?view=posts&threadid=79


Now, my first priority is finishing my jukebox cabinet build since it is being worked on in the garage and my wife can no longer park in there.   I have discovered there is some wiring work which needs to be performed.

[unclet]

I found some time and added headkaze's logic to my software and have some problems:

1)  Inside the JukePlugIn class there is a routine called "GetPluginInfo()" which calls "CallFuncPtr()".  I just confirmed the "CallFuncPtr()" routine does not populate the name, author or version information at all.   Whatever value these text strings have before the call to "CallFuncPtr()", they have after the call to "CallFuncPtr()", although they are always padded with trailing "space" characters until the length of the text string is 256.

Are the parameters being passed by reference (like they should be) or are they perhaps being passed by value instead (which would be incorrect)?

2) Why is the PluginInfoType and SongInfoType structures defined with a "* 256" value next to each field? 

3) Why are you using "strncpy" to copy the name, artist and album plugin information?  I do not think this appends the null terminator to the end of the string.  Am I wrong?

4) I updated the SongStart routine to have three input parameters (ie: name, artist and album).   Now, when a song is started in my software, the SongStart routine of the plugin is called and a MessageBox is displayed which shows the song which has been started.   When I click on the "OK" box on the MessageBox, then my VisualBasic project closes automatically.   No crashes or anything .... just disappears.

Any idea what is going on here?

I can not proceed any further until this questions have been resolved.....   

[Barry Barcrest]

I found some time and added headkaze's logic to my software and have some problems:

1)  Inside the JukePlugIn class there is a routine called "GetPluginInfo()" which calls "CallFuncPtr()".  I just confirmed the "CallFuncPtr()" routine does not populate the name, author or version information at all.   Whatever value these text strings have before the call to "CallFuncPtr()", they have after the call to "CallFuncPtr()", although they are always padded with trailing "space" characters until the length of the text string is 256.


Are the parameters being passed by reference (like they should be) or are they perhaps being passed by value instead (which would be incorrect)?

Have you made the strings global? I have not had chance to check this out so i can't confim if it works or not.

2) Why is the PluginInfoType and SongInfoType structures defined with a "* 256" value next to each field? 

This means it will be a constant 256 characters long, you can use the VB Trim command to remove spaces....

Trim(String)

Like that.

3) Why are you using "strncpy" to copy the name, artist and album plugin information?  I do not think this appends the null terminator to the end of the string.  Am I wrong?

I don't know anything about this, there doesn't really need to be a terminator as far as i can see...

4) I updated the SongStart routine to have three input parameters (ie: name, artist and album).   Now, when a song is started in my software, the SongStart routine of the plugin is called and a MessageBox is displayed which shows the song which has been started.   When I click on the "OK" box on the MessageBox, then my VisualBasic project closes automatically.   No crashes or anything .... just disappears.

Any idea what is going on here?

I reported tis issue further back in the thred. If you only pass a small smount of data, like just the title or artist it works so something is causing the DLL to crash the juke. It's not specific to your juke cause it does the same on mine so it is the VB code we dumped in to handle the plugins causing the issue... It looks like the plugin is crashing so the plugin might have a bug.

If you look at the alert box does it have all 3 string values for the first entry then 2 string values for the next and then 1 value for the last. It could be the alert box is trying to display too many characters because it works fine if you back off how much you send.

Try sending it with thress strings like this...

"one","two","three"

What do you see then?

Name: One Two Thee Artist: Two Three Album: Three

Something like that would be my guess.

I can not proceed any further until this questions have been resolved.....   

This is partially why i gave up although i would like to see if i can get the returned values from the plugin to work.

[unclet]

Have you made the strings global? I have not had chance to check this out so i can't confim if it works or not.

The following declaration is made in the "General Declarations" section of the JukePlugin class module:

Private PluginInfo As PluginInfoType

and the following call is made to populate the plugin information (name, artist, album):

CallFuncPtr pDC, pGetPluginInfo, PluginInfo.Name, PluginInfo.Author, PluginInfo.Version

This means it will be a constant 256 characters long, you can use the VB Trim command to remove spaces....

Trim(String)

Yes, Trim() works well .... forgot about that command .... been a while   

I don't know anything about this, there doesn't really need to be a terminator as far as i can see...

Yeah I guess this does not matter since I am now using Trim()

I reported this issue further back in the thread.

Headkaze supplied some new example code (using his JukePlugin class module as a wrapper).   I updated his SongStart routine to have three input parameters as follows:

Public Sub SongStart(songName As String, songArtist As String, songAlbum As String)
   
    If pSongStart <> 0 Then
        SongInfo.Name = songName
        SongInfo.Artist = songArtist
        SongInfo.Album = songAlbum
        CallFuncPtr pDC, pSongStart, SongInfo.Name, SongInfo.Artist, SongInfo.Album
    End If
End Sub


When the SongStart routine is called with "ONE", "TWO" and "THREE" text strings then a MessageBox is displayed with the following 788 characters:

Song has started, Name: ONE(padded with 253 space characters), Artist: TWO(padded with 253 space characters), Album: THREE(padded with 251 space characters)


I guess we need headkaze to look into this problem so more.   There is nothing else I can do until this problem is resolved as well as why the actual plugin information (name, artist and version) are not being passed back correctly.

[Barry Barcrest]

Ooops i just noticed this..

Using CallFuncPtr() has it's limitations and these are

- Can't use structs (aka types in VB6)
- Can't send over Unicode strings
- It only works one way, meaning you can't retrieve data from the plugin like plugin info. But I've left the code in there anyway.

Guess that's why we can't get data from the plugin so tag information is out.

[Space Fractal]

The way I did in Pure basic is to connect his plugin was creating a string with 255 chars space and then send a string pointer to its functions (so the plugin got a memory adress, where the strncpy should copy its content to).

If you got it to work wtih about, we could even add a fourth arguments to retrieve any information from the commands if that is needed instead of doing that directly?

Which the above method, that should not have problem to use unicode?

I still want support Unicode !! We should wait to hear from him, how we deal with that problem.

[headkaze]

3) Why are you using "strncpy" to copy the name, artist and album plugin information?  I do not think this appends the null terminator to the end of the string.  Am I wrong?

The only place I use strncpy is to get the PluginInfo from the plugin. But because of the CallFuncPtr() hack were using allocates the strings for each paramter it sends means we can't alter the strings from the plugin because they are a copy. (See my post about the limitations caused by CallFuncPtr())

I would like to see you updated your source and examples to support unicode. Unicode is very important to been supported. Unicode is just a 16 bit wide strings up to 65kb chars (which BlitzMax example use).

I already said in recent post that using the hack for VB6 means it cannot support Unicode strings. (See my post about the limitations caused by CallFuncPtr())

Code: [Select]

Public Sub SongStart(songName As String, songArtist As String, songAlbum As String)
   
    If pSongStart <> 0 Then
        SongInfo.Name = songName + Chr(0)
        SongInfo.Artist = songArtist + Chr(0)
        SongInfo.Album = songAlbum + Chr(0)
        CallFuncPtr pDC, pSongStart, SongInfo.Name, SongInfo.Artist, SongInfo.Album
    End If
End Sub
You need to add a null character. Sorry I should have made the functions with paramters in the first place. Here is the updated source. I also updated to use the multi-threading example of CallFuncPtr().

[Space Fractal]

De bite some language cant support unicode, I have added a fourth argument to the GetPluginInfo function.....

It would tell the plug-in the application can support UTF8 strings or not (hence they are ASCII compatible).

I do recommend plug in writers to support unicode, but with backwards compatible with ASCII. Hence I added the another argument.

[unclet]

headkaze
1) I updated my code to use your new logic.   When the SongStart routine is called with small text strings (ie: name="one", artist="two", album="three") then everything works fine ...... the MessageBox pops up correctly and I can click the OK button to close it and my software continues to run no problem.   However, if the text strings passed into the SongStart routine are larger in size, then this causes my Visual Basic project to simply disappear/close/exit (like Barcrest mentioned previously).   

Please test this on your end to see if you can solve this problem.

2) I am confused ......  are you saying the GetPluginInfo() routine "should" pass back the plugin information now?    Currently it still does not pass back anything.  The text strings have the same value as they had before calling the CallFuncPtr() routine located within the GetPluginInfo() routine.

Now, if obtaining information from a plugin is not allowed using the CallFuncPtr() routine, then perhaps the plugin author can create a simple text file (.TXT) which shares the same name as the plugin to hold the plugin information (name, author and version).   It would be nice to somehow know what version of the plugin is being used from within the software.

3) Check out the following thread logic you added:

   

Do
        ' if exit code is 256 the thread is still running
        GetExitCodeThread hThread, dwExit
        If dwExit <> 259 Then Exit Do
        DoEvents
    Loop

The comment states "if exit code is 256" but the code checks for "If dwExit <> 259".    It seems the code check should check for 256 instead of 259 .... correct?


Anyway ..... until (1) is solved somehow I do not see how this plugin stuff is going to work properly.

[Space Fractal]

The first problem is a buffer overrun problem caused because he didden't check the length of the string... You need to check anything manually in C++ with strings. But for now it seen you can get it to work, which is most important.

Same problem can go with with Juke_GetPluginInfo(), but it a less problem, since it just some info. So here its acceptepeted by me.

I guess to get this to work, You need to create a empty space string with each variable a least 256 bytes long before you call the Juke_GetPluginInfo(). This is due with strncpy command he use.

I think the SDK is by now skipped if both Uncles and Barcrest can get this to work directly with plugins (which is fine with me). I just use the wrapper by my self which is needed by BlitzMax.

[headkaze]

headkaze
1) I updated my code to use your new logic.   When the SongStart routine is called with small text strings (ie: name="one", artist="two", album="three") then everything works fine ...... the MessageBox pops up correctly and I can click the OK button to close it and my software continues to run no problem.   However, if the text strings passed into the SongStart routine are larger in size, then this causes my Visual Basic project to simply disappear/close/exit (like Barcrest mentioned previously). 

[/quote]

Just to reiterate sending strings using the hack means you cant change them in the plugin. I just left the code in there because if someone writes a Jukebox in a language like C++/C#/VB.NET etc. you have no problem retrieving the PluginInfo. So getting the PluginInfo using VB6 is not possible using the hack.

The reason it's not working for long strings is because we are limiting the size of the strings to 256 characters.

This is what this means

Code: [Select]

Public Type PluginInfoType
    Name As String * 256
    Author As String * 256
    Version As String * 256
End Type

Public Type SongInfoType
    Name As String * 256
    Artist As String * 256
    Album As String * 256
End Type
Each string is 256 characters in length. The reason for this is because originally we were going to use structs and you need to specify the size of the strings if you want to manipulate them in the plugin. Sorry I should have re-written it, but I thought you would figure that one out

Because we don't need to change strings in the plugin we dont need a fixed size. And then you can send over whatever size string you want. BUT keep the PluginInfo one with the fixed string sizes because strncpy() will crash your program if you remove that. So you need to change your code to the following.

Code: [Select]

Public Type PluginInfoType
    Name As String * 256
    Author As String * 256
    Version As String * 256
End Type

Public Type SongInfoType
    Name As String
    Artist As String
    Album As String
End Type
That means the SongInfoType will be any size.

..OR you could do away with the SongInfoType definition altogether (now we cant use them anyway).

Code: [Select]

Public Sub SongStart(songName As String, songArtist As String, songAlbum As String)
    If pSongStart <> 0 Then
        CallFuncPtr pSongStart, songName + Chr(0), songArtist + Chr(0), songAlbum + Chr(0)
    End If
End Sub
That should work just as fine and won't limit your size of strings passed to the plugin.

Your wrong about the "If dwExit <> 259 Then" it says "if exit code is 256 the thread is still running" so your still in the loop the dwExit will be 256. If it is 259 it exits (I guess). I just copied the code off that link you gave me. But anyway my feeling is you might want to go back to the version without threading. VB6 is notoriously unstable using threading. So perhaps it would be better to go back to the non-threading version. You will have to change that code back to send the hDC of the form etc. if you do go that way. In my opinion it should be the plugin coder that adds any threading if the task will take a long time, not the host application calling the plugin. But it's up to you.

EDIT: Okay I added a new version without the threading, and fixes the string length limitation.

[unclet]

SongStart and SongEnd routines now work ...... thanks for the updated code.

Do you think a text file with three lines indicating the name,  author and version would be worth it to provide VB6.0 applications the plugin information?

+---------------
|Test Plugin
|Ben Baker
|1.0
|

I guess I can always ask for this file and if it does not exist then ignore the plugin information. 

Come to think of it ....... the name of the plugin file could simply include a nice name and version and perhaps the author name as well..... that might be easier for everyone.

[headkaze]

SongStart and SongEnd routines now work ...... thanks for the updated code.

Do you think a text file with three lines indicating the name,  author and version would be worth it to provide VB6.0 applications the plugin information?

+---------------
|Test Plugin
|Ben Baker
|1.0
|

I guess I can always ask for this file and if it does not exist then ignore the plugin information. 

Come to think of it ....... the name of the plugin file could simply include a nice name and version and perhaps the author name as well..... that might be easier for everyone.

I think that is a good way around that. You could have [PLUGIN_NAME].txt with those values in there. And then If(plugin.IsPlugin()) attempt to read it in. If it doesn't exist then just have PluginInfo.Name=[PLUGIN_NAME] and PluginInfo.Author=Unknown, PluginInfo.Version=Unknown. You could also have the plugin details inside the filename Eg. JukePlugin_v1.0_Ben Baker.dll. I guess it's up to you which way to go

[Barry Barcrest]

The new code works fine, thanks Headkaze.

[headkaze]

The new code works fine, thanks Headkaze.

That's good to hear mate. Although there is one thing I did forget, and that was updating the actual JukePlugin.dll to support longer characters. It's really not important though as it's only a test and a real plugin won't be so dumb as to assume all the song data will fit into a 512 character buffer.

Code: [Select]

JUKEPLUGIN_API int __stdcall Juke_SongStart(PCHAR Name, PCHAR Artist, PCHAR Album)
{
char buf[512];

sprintf(buf, "Song has started, Name: %s, Album: %s, Artist: %s", Name, Album, Artist);

MessageBox(NULL, buf, "Juke_SongStart", MB_OK);

return 1;
}
Obviously making it buf[4096]; would be a safer amount, but hey like I said it's only a demo.

Now, I guess you just gotta figure out all the functions you need and make a demo plugin for that. Then Loadman can get onto writing a real plugin

If you guys need the JukePlugin.dll example extended with the new functions for testing let me know. I would need a list of all the functions and parameters though.

I think once you guys get plugins going you will be really suprised how much they can enhance your software. All you need is some good plugin coders like loadman who already created a tonne of great ones for Mala

[loadman]

Now, I guess you just gotta figure out all the functions you need and make a demo plugin for that. Then Loadman can get onto writing a real plugin
If you guys need the JukePlugin.dll example extended with the new functions for testing let me know. I would need a list of all the functions and parameters though.
I think once you guys get plugins going you will be really suprised how much they can enhance your software. All you need is some good plugin coders like loadman who already created a tonne of great ones for Mala

Hey Dude,

I also got your demo working great with VB6 (as the host) and C++ (to make Plug-ins).

But I would rather code in Delphi as I have existing code.

I got it working to a point but it barfs if I try and see any song info.

This works fine:

Code: [Select]

library JukePlugin;
uses
  Dialogs;
{*******************************************************************************}
procedure Juke_GetPluginInfo(Name: String; Author :STRING; Version:String); stdcall;
begin
Name := 'Load';
Author := 'Me';
Version := 'One';
end;
{*******************************************************************************}
procedure Juke_SongStart(Name: String; Artist :STRING; Album:String); stdcall;
begin
end;
{*******************************************************************************}
procedure Juke_SongEnd(Name: String; Artist :STRING; Album:String); stdcall;
begin
end;
{*******************************************************************************}
  exports
  Juke_GetPluginInfo,
  Juke_SongStart,
  Juke_SongEnd;
{$R *.res}
begin
end.
But it will crash if I do this:

procedure Juke_SongStart(Name: pchar; Artist :STRING; Album:String); stdcall;
begin
    Showmessage(Artist);
end;

Any Ideas? I'm sure I can figure it out but I am lazy 

[headkaze]

Loadman: Try PChar no String's just PChar

[Space Fractal]

PChar is I guess used to detect the memory address where it got from the software.

HeadKaze - 
There is a list of re commered functions on this thread:
http://forum.arcadecontrols.com/index.php?topic=75083.0


I agree with the string buffer limit to getting JukeGetPluginInfo(). It now confirmed it would works with all software. I do added a Fourth argument to JukeGetPluginInfo() for to the if the jukebox software is unicode aware or not.

I dropped 16 bit unicode strings for compatible, and instead they now need to been converted to UTF8 before sent to the plug in (if the jukebox software can handle it) and let the plug in convert back.....

There is also a another function in the list that require the same.... Its for player controls.

So please look in the list. I have tried to do that so most universal as possible....

[loadman]

Loadman: Try PChar no String's just PChar

What took you so long??  he he    Thanks. That works.

[Space Fractal]

Any idea for a sweet name for this Plugin system?

Look like MultiJuke (Windows version only), Uncle't Jukebox and Freebox all got some plugin system in the near future. Only problem is how a plugin system should work in Linux (that using SO files, not DLL)? But it not to debate in this thread.

I hope applications like DWJukebox jump into this and let it support it too.

[loadman]

Any idea for a sweet name for this Plugin system?

OK the format is almost settled so it's time for a name.

Lets see...

1)
We could use a 'name follows function name'.
Its a Plugin that works with multiple juekbox's so a name like 'PlugMyJuke'


2) We could go with the 'apple' idea that just uses random real names.

And call it something out there like 'Fonz'.  Images of the 'The Fonz' whacking the Jukebox comes to mind.



I need a Coffee 

[unclet]

Doesn't headkaze have a built-in jukebox system in his frontend?   Lets not forget him since he did a lot of this work as well.

I think prefixing each routine name with "Juke" (like we have it) is nice and sweet.  Do not need to have long names in my opinion.

headkaze
I have no idea what you mean by "supporting longer characters" ...... and do I need to do something special to allow for this?

Space Fractal (or anyone else)
I have no idea what this means:

I dropped 16 bit unicode strings for compatible, and instead they now need to been converted to UTF8 before sent to the plug in (if the jukebox software can handle it) and let the plug in convert back.....

Does my software need to do anything special for text strings?

[loadman]

HeadKaze
The following Delphi code is the only one of have found to keep your VB code happy and allow proceeding procedures to work

Code: [Select]

function Juke_GetPluginInfo(A: pchar; B :pchar; C:pchar):Pchar ; stdcall;
begin
result := PChar('Test');
end;

But how can I do it properly so it send back the details to the Jukebox??
Problems:
1) A function has has one result type
2) VB is not recognising this one result anyway
3) If I don't have the 3 viriables inside the function VB will crash? Weird. It seems like the wrong spot? AHH 


LATER:
Actually The C++ code example you provided does not appear to pass the data to the VB App either.  I added a bit to the VB App:

Code: [Select]

Private Sub Command2_Click()
Text1.Text = "Plugin name is: " + plugin.Name
End Sub
But No data?? 

[Barry Barcrest]

Needs a name to reflect what it is...

Some Suggestions (Too literal?);

Open Source Jukebox Plugin
Multiple Jukebox Plugin System

Obviously something with a nice abbreviation would work.. Then we need a little logo for it. That way any jukebox software that supports it can display the logo. I also think it needs it's own website that can hold the SDK and also the plugins. I would set this up but i have bandwidth issues with my site as it is and i also imagine it might take a bit of work to manage unless we add some sort of uploading front end to it so people can upload thier own plugins. There are loads of PHP scripts actually that could give us something like the winamp plugin page...

HeadKaze:
Can you make a demo plugin supporting what we have documented in the other thred just so we can test that our juke software works with the system as it should.

I have a little app i made in VB that displays a simple vis. If somebody could help me turn that into a DLL i could make it display on song start and close on song end. I could also make it display the song info it would be passed and have a little config that would enable full screen with it. I have never wrote a DLL in VB before so i am not sure what needs to be done. I could just tidy up the code and post the source if anyone fancies playing with it....

EDIT:

It would be cool if we could get LASFM and MUSICIP to code plugins for this system. I am sure it would help with the popularity. I know a couple of apps support last FM it might just be a case of somebody coding some sort or wrapper or them making a plugin that worked. They would also benifit by opening up some more userbase to them...

Just a thought i wanted to note so i don't forget.

[Space Fractal]

Space Fractal (or anyone else)
I have no idea what this means:

I dropped 16 bit unicode strings for compatible, and instead they now need to been converted to UTF8 before sent to the plug in (if the jukebox software can handle it) and let the plug in convert back.....

Does my software need to do anything special for text strings?

If your software only support ASCII (256 Chars) and only using normal 8 bit text strings, there are no need to change anything and can just set UTF8 value to 0.

In BlitzMax its allways use 16 bit strings internal, but can send 8 bit strings to a DLL if needed. For backward combabitble I would need to convert back to 8 bit using the variable 8bit UTF8 encoder system (can been a bit confusion).

So I asume the plugin writer have such a function that just can convert back from 8bit UTF8 to 16bit strings). it might been a problem if a jukebox application only support ASCII, but the plugin allways use 16 bit, but that problem is up to the plugin writer to been fixed.


More info about UTF8:
http://en.wikipedia.org/wiki/UTF8

Other Example is OGG use UTF8 strings for unicode support. Hence I allreay have a function that convert UTF8 back to 16 bit strings. So I would not have problems to get UTF8 strings returned.

[loadman]

I have never wrote a DLL in VB before so i am not sure what needs to be done. I could just tidy up the code and post the source if anyone fancies playing with it....

I'm not sure you can?  I think VB can only create ActiveX DLL's  but it can read proper DLL's.

[unclet]

Jukebox Standard Plugin System (JSPS)  <-- The acronym kind of rolls off your lips

[Space Fractal]

I have no bandwith issue, so I can take that one on my webserver. We also could askask saint/sirwoogie for webspace for this system using own domain or subdomain?

Would been neat if one of these 2  companies, Barcrest named, would wrote such of plugins !!

I do liked this name from Loadman: PlugMyJuke


Pure Basic is such of great language to create small packed dll's, like plugins like these.

[Barry Barcrest]

I am testing a VB DLL i just made with it now, i doubt it will work as it seemed to easy to do LOL

I have never wrote a DLL in VB before so i am not sure what needs to be done. I could just tidy up the code and post the source if anyone fancies playing with it....

I'm not sure you can?  I think VB can only create ActiveX DLL's  but it can read proper DLL's.

Yes you are correct.. I thought an activeX DLL would work but i guess not, it doesn't throw up any errors it just doesn't do anything. I guees it doesn't load it becasue it's not the right type of DLL file....

[loadman]

Jukebox Standard Plugin System (JSPS)  <-- The acronym kind of rolls off your lips

Poll Created

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

[unclet]

Ahhhh ... you did not need to create poll for this, I like PlugMyJuke (.pmj) as well!

It is funny ..... the only ones who pretty much ever join in jukebox conversations are:

headkaze
SpaceFractal
Barcrest
loadman
unclet


I would be surprised if other people chime in at all on your poll ..... but I do like surprises.

[Barry Barcrest]

Shame that i can't make it work with VB DLL files because i could have made that plugin. Never mind though not a big deal... I just wanted to create something LOL

[Space Fractal]

I can (using Pure Basic, since BlitzMax cant write DLLS).

Barcrest, which plugin would you want to been useful?

[headkaze]

HeadKaze
The following Delphi code is the only one of have found to keep your VB code happy and allow proceeding procedures to work

Code: [Select]

function Juke_GetPluginInfo(A: pchar; B :pchar; C:pchar):Pchar ; stdcall;
begin
result := PChar('Test');
end;

But how can I do it properly so it send back the details to the Jukebox??
Problems:
1) A function has has one result type
2) VB is not recognising this one result anyway
3) If I don't have the 3 viriables inside the function VB will crash? Weird. It seems like the wrong spot? AHH 


LATER:
Actually The C++ code example you provided does not appear to pass the data to the VB App either.  I added a bit to the VB App:

Code: [Select]

Private Sub Command2_Click()
Text1.Text = "Plugin name is: " + plugin.Name
End Sub
But No data?? 

Mate you can't send data from the plugin that is a limitation of the CallFuncPtr() function I just left the code in there for other languages. I've said it a few times but noone seems to get it. Maybe I should just remove the PluginInfo code?

This is why unclet was thinking of other ways to send the plugin info like using a text file or having the details in the filename.

[Barry Barcrest]

Dude i got it.... EVENTUALLY.

The only thing i would have liked to have recieved info from the plugins for would have been if i could pass the filename and it returned the tag info. So people could code plugins to handle the tag info so more file types could be supported. However like you said it doesn't work so it's no hastle.

[Space Fractal]

I through your folks got it working with returned string using a string buffer like 256 bytes? If yes, it can been used with some other commands with same scheme.

Or is it more sending strings to the plugins that is the problem? And not the other way?

If one way worked (plugin -> software), why not use the same method to the other way (also by the plugin here)?

So, Barcrest, I just added a another command to your idea about getting tag info if add2queue() have sent to the plugin with no songinfo at all.

[Barry Barcrest]

Space fractal Don't add anything that requires the plugin to send info the application. We can't do this in visual basic using the dynamic loading of DLLS that we have now.

That is what Headkaze has been saying for the past day or so.

[headkaze]

Here is the plugin with all the functions but I had to add a paramter to the functions without one as the (now famously limited) CallFuncPtr() won't allow it.

Code: [Select]

// QUEUE FUNCTIONS

JUKEPLUGIN_API int __stdcall Juke_AddQueue(PCHAR File, int SongTime, int Auto, PCHAR CoverArt, PCHAR Title, PCHAR Artist, PCHAR Album, PCHAR Genre, PCHAR Special);
JUKEPLUGIN_API int __stdcall Juke_QueueClear(int ReSubmit);
JUKEPLUGIN_API int __stdcall Juke_SongSuggestion(PCHAR File);

// STATUS FUNCTIONS

JUKEPLUGIN_API int __stdcall Juke_SongStart(int Value);
JUKEPLUGIN_API int __stdcall Juke_SongEnd(int Skipped);
JUKEPLUGIN_API int __stdcall Juke_SongPlayed(int Seconds);
JUKEPLUGIN_API int __stdcall Juke_SongStatus(int Status);

// APPLICATION INFO

JUKEPLUGIN_API int __stdcall Juke_GetPluginInfo(PCHAR Name, PCHAR Author, PCHAR Version, int UTF8);
JUKEPLUGIN_API int __stdcall Juke_Volume(int Value);
JUKEPLUGIN_API int __stdcall Juke_Initialize(int Value);
JUKEPLUGIN_API int __stdcall Juke_Shutdown(int Value);

// COMMANDS (Eg Play, Skip, VolumeUp VolumeDown, Lock, UnLock)

JUKEPLUGIN_API int __stdcall Juke_Command(PCHAR Name, PCHAR Value);

// CREDIT FUNCTIONS

JUKEPLUGIN_API int __stdcall Juke_AddCoin(int Coins);
JUKEPLUGIN_API int __stdcall Juke_PaidCoin(int Coins);

[Space Fractal]

Even If I can dynamic loading the plugins using a special wrapper SDK and use this SDK to visual basic?

I have no problem with dynamic loading in Pure Basic at all. It really designed to doing that way.

I also saw Unclet got it working? I assume he use the same language?

This mean retrieve tagging and the important getinfo() cant been used and got empty strings?

Which command(s) do have a problem?

We need something workaround, since few functions require that (and you cant get your tag idea working that way?).

[unclet]

Space Fractal
Since I am using VB, I can not rely on the JukeGetPluginInfo() routine to provide the plugin information.   The CallFuncPtr() routine does not allow data to be passed from the plugin to the software.  No big deal for me.

For the Juke_Command() routine ..... why are we relying on a command.txt file to be created.   Why not create a standard list of set values which can be used in this routine instead.

For example:

JUKE_COMMAND_PLAY
JUKE_COMMAND_VOLUME_UP
JUKE_COMMAND_VOLUME_DOWN
JUKE_COMMAND_PARTY_LOCK_ON
JUKE_COMMAND_PARTY_LOCK_OFF
JUKE_COMMAND_MUTE_ON
JUKE_COMMAND_MUTE_OFF
etc.
etc.

Just a thought .... since I am still not crazy about supporting a "command.txt" file
 

[Space Fractal]

I have faced into the same problems like you folks when I tried communicate directly. But I have found a work around you should check out.

I have created a PlugMyJuke.dll that is basically a wrapper that read all plugin with it.

I used few more commands and I have created a test plugin with all commands used from the other thread (there was few erros in HeadKaze ones, but it can been used if the command list exists or not).

When you connect PlugMyJuke.dll, you need to invoke Load_Plugins(path$) first with a path$ to the plugin folder.

Then all commands is the same as in SDK wich one exception:
You need to add a plugin number as the first argument for all commands.

Examples:
Juke_Initialize() whould been Juke_Initialize(PluginNumber)
Juke_GetPluginInfo() whould been Juke_GetPluginInfo(PluginNumber, value$)

and so on. I change the list on the other thread to sync this SDK. PlugMyJuke.dll it self should been moved to your main software folder, not the plugin. Hence it need where the plugins is, hence the path.

All commands return a number, if the functions did have some success:

0 = not found.
-1 = plugin found, but not the function.
1 or a string is the functions was invoked.

All sources and files is included in the attachement file. Hope you now got it to work.

By now I use PlugMyJuke as a work name, if it would change to something other.

[Space Fractal]

For the Juke_Command() routine ..... why are we relying on a command.txt file to be created.   Why not create a standard list of set values which can be used in this routine instead.

For example:

JUKE_COMMAND_PLAY
JUKE_COMMAND_VOLUME_UP
JUKE_COMMAND_VOLUME_DOWN
JUKE_COMMAND_PARTY_LOCK_ON
JUKE_COMMAND_PARTY_LOCK_OFF
JUKE_COMMAND_MUTE_ON
JUKE_COMMAND_MUTE_OFF
etc.
etc.

Just a thought .... since I am still not crazy about supporting a "command.txt" file

MutiJuke does not have JUKE_COMMAND_PARTY commands. I think a commands.txt would been better for more effective use of all commands, even some commands in a software is unique.

[loadman]

Mate you can't send data from the plugin that is a limitation of the CallFuncPtr() function I just left the code in there for other languages. I've said it a few times but noone seems to get it. Maybe I should just remove the PluginInfo code?

This is why unclet was thinking of other ways to send the plugin info like using a text file or having the details in the filename.

Thanks.  I should learn to read 

Here is the plugin with all the functions but I had to add a paramter to the functions without one as the (now famously limited) CallFuncPtr() won't allow it.

Thanks 

[Space Fractal]

I created a new thread about a main dll to been used as well.

Loadman: Can you change both of your thread to starting with Plugins?

I created a new thread due with a new SDK. Since we now have 4 threads, I goes a main title should constring Plugins so they can been easier found.

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

Later we might have a plug-in forum as a child board to the jukebox section?

[Arcade Freak]

hi guys,

i have been following your conversation since the beginning and its fantastic how people from the four corners of the world can work together on such a project. Give and receive critesizime and still pull together and work to be able to acheive such a project. i think the plugin will be great.

my programming skills are very low (college level 7 years ago) so i didn't dare to join but i am enjoying tremendously.

keep up the great work guys 
 
 

[Arcade Freak]

hi guys,

once this all done, if i get this right is that within unclet jukebox there will be an option to listen to the radio?

then will there be somekind of a default video to go with it or somekind of a screen saver or even a screen from like windows media player...just to fill out the screen?

cheers,
calude

[unclet]

Hello again   

My jukebox software can be read about at my site:

http://unclet.arcadecontrols.com/Jukebox/index.html

It is a video and/or audio music player.  The majority of people have MP3 files they want to use on my jukebox and that works perfectly, although some people (including myself) have tons of music videos to watch instead of listening to just MP3 tracks.  As a result my jukebox was designed to allow videos as well.  My jukebox has nothing to do with Radio stations though ... sorry.   I prefer to keep my jukebox software to be more like a real jukebox instead of a radio tuner   

Anyway, my software interfaces with WMP to show the videos and hear the audio, so the user will need to have WMP 9.0 (or higher) installed.  If you select a video file to play, then the WMP player window will show you the video.

Anyway, you can download it and play around with the software if you like (link above).  It is packed with various features and settings so you really just need to play around to see if it suits your needs.  I basically just made it to suit my needs by then decided to share it with others.

[headkaze]

It is a video and/or audio music player.  The majority of people have MP3 files they want to use on my jukebox and that works perfectly, although some people (including myself) have tons of music videos to watch instead of listening to just MP3 tracks.  As a result my jukebox was designed to allow videos as well.  My jukebox has nothing to do with Radio stations though ... sorry.   I prefer to keep my jukebox software to be more like a real jukebox instead of a radio tuner   

I think he's talking about having a plugin that adds radio playback to your Jukebox. But if your using the WMP engine for video playback, then it should be able to play streaming radio since WMP can play that. All you need is the ability to run *.lnk files which are shortcuts to the address of the radio station.

For example right click on your desktop and select New > Shortcut. Paste in http://www.abc.net.au/streaming/triplej.asx as the location and JJJ as the name. Then double click the shortcut and it will play streaming radio through WMP.

[Space Fractal]

They are ASX files, NOT LNK files.

LNK is just a shortcuts to anyway to a net or harddrive. Some nasty webradio does use flash  today, so they cant been used other than a browser, so LNK might been needed, but just hope they dosent use popups (use a blocker).

Otherwice direct links to net radios is ASX and PLS files and both plays fine in Windows Media Player. Just add these extension to add net radio support.

[headkaze]

They are ASX files, NOT LNK files.

LNK is just a shortcuts to anyway to a net or harddrive. Some nasty webradio does use flash  today, so they cant been used other than a browser, so LNK might been needed, but just hope they dosent use popups (use a blocker).

Otherwice direct links to net radios is ASX and PLS files and both plays fine in Windows Media Player. Just add these extension to add net radio support.

I understand lnk's are just shortcuts, I just didn't realise what asx files were. But your right you can actually right-click the asx and save them as a file. All it is is a html tag with a link to the stream.

Code: [Select]

<ASX version = "3.0" BannerBar = "FIXED">
   <Entry>
<Ref href = "mms://media3.abc.net.au/triplej"/>
   </Entry>
</ASX>
So if you create a shortcut to mms://media3.abc.net.au/triplej instead it will play the stream directly without any potential popup's.

[unclet]

I think he's talking about having a plugin that adds radio playback to your Jukebox. But if your using the WMP engine for video playback, then it should be able to play streaming radio since WMP can play that. All you need is the ability to run *.lnk files which are shortcuts to the address of the radio station.

WMP can do a lot of stuff which has not be incorporated into my jukebox.   Radio playback is one of these features, however, if I do not update my software to interact with WMP to support this feature then that WMP functionality will not be working via my jukebox interface.

WMP also allows playlist lists (like Space Fractal mentioned previously ... I think).  My jukebox does not use the playlist functionality from WMP to manage the songs .... I implemented my own queue instead

[Space Fractal]

Even WMP and PLS is both a Playlist files, these are also used to send the link to the current streams by some webradios (Like danish DR).... Here not been treated as a normal PlayList. That should been mainstream in WMP automatic.