PlugIns: Common Format (initial concept discussion)

[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.