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.