Messages

16

MusicBee API / Re: MusicBee API

« on: July 04, 2011, 11:17:39 AM »

By the way... in my eternal quest for elegant code (it's a curse, really), I've encapsulated the raw MusicBee API in a nicer, more .NET'ish set of classes with Properties and Events -- fancy stuff. Basically, the idea is that I hate (with a vengeance) longwinded switch-case constructs and rather wanted something like...

Code

api.TrackChanged += (MusicBeeEventArgs args) => { Console.WriteLine(args.RelatedFile.AlbumArtist); };

then...

Code

public void ReceiveNotification(string sourceFileUrl, NotificationType type) {
    switch(type) {
        case NotificationType.TrackChanged:
            Console.WriteLine(mbApiInterface.Library_GetFileTag(relatedFile, MetaDataType.AlbumArtist);
            break;
    }
}

Would something like this make life easier for you, R U Bn?

17

MusicBee API / Re: MusicBee API

« on: June 30, 2011, 02:11:10 AM »

Another thing: you mentioned that Library_GetFileProperty only works on files in the library, but NowPlaying_GetFileProperty works on the currently playing file regardless whether it's in the library or not. So for any other files in the Now Playing list that aren't yet in the library, it's not possible to get the properties?

18

MusicBee API / Re: MusicBee API

« on: June 29, 2011, 05:18:41 PM »

I was talking about MusicBee's side... Essentially, when there are any events for a window - mouse movement, key presses, you name it -, they are put into a queue. The program typically contains a loop that calls the Windows API to take an event from that queue and send it to the window's WindowProc. "Posting" a message to a window means that you put a user-defined event into that queue; eventually, the window's WindowProc will be called with that event, and if it knows how to process it, stuff happens... or it will just silently ignore your message.

Regarding Eclipse... maybe these help:
http://emonic.sourceforge.net/html/usage.html - Emonic is a C#/.NET 2.0 plugin for Eclipse, the link explains how it's set up.
http://monodevelop.com/ - Not based on Eclipse. Mono is the opensource implementation of C#/.NET, so this should work just as well with the "real" .NET CLR.
Visual Studio 2010 Express - a free version of Visual Studio. It's a bit crippled (lacks certain refactoring features, you can't manually attach the debugger to random processes, etc.), but otherwise unlimited (no restriction on code size, all .NET features available, and no limitations on how you can license or sell your code/program).

Btw:
MusicBeeInterface.cs contains all the definitions and constants used by MusicBee. (All these enums, delegates and structs are members of the MusicBeePlugin.Plugin class.)
TestCSharpDll.cs contains the rest of the class MusicBeePlugin.Plugin, notably the various well-known methods called by MusicBee to communicate with your plugin, as well as a bit of example code that illustrates how messages are sent to MusicBee and how MusicBee's notifications are handled.
Properties\AssemblyInfo.cs is auto-generated (and auto-modified) by Visual Studio and contains a bunch of attributes that define the product name, description, copyright, version etc. strings embedded into the DLL file.

19

MusicBee API / Re: MusicBee API

« on: June 29, 2011, 01:39:56 PM »

I noticed there's no API to add items to the now playing list other than play now (which replaces everything with the selected file), queue next (which inserts the file after the currently playing item but appears to be broken) and queue last (which I haven't tested yet). I'm not sure how useful this would be, and I don't have an application for this missing API myself, right now... but anyways, a few APIs to remove and insert now-playing list items by index, get the total count of now-playing items, get the index of the currently playing item and get the indices of selected items would be nice to complete the interface.


@R U Bn: As far as I know, MusicBee does not expose any COM interfaces, and I'm not aware that it's even possible to handle direct Post messages in C# (Windows' window messages are handled deep inside the Windows Forms library)...

Personally, I have the luxury of a free Visual Studio 2010 (Pro even) via the MSDNAA program, so I can't help you with setting up things in Eclipse, but if you have any concrete questions about how MusicBee interacts with your plugin DLL, I might be able to give you some pointers. (Basically, MB loads your DLL and invokes a few methods with well-known names, such as MusicBeePlugin.Plugin#Initialize. Any communication from MB to the plugin happens by MB calling these methods, and any communication from the plugin to MB happens by the plugin calling one of a bunch of delegates it received from MB via the Initialize method (if you know C, delegates are type-safe and nicely encapsulated function pointers slash trampolines). As such, MusicBee plugins are quite specialized, as far as Hello-World-type .NET programs go...)

20

MusicBee API / QueueNext bugged?

« on: June 29, 2011, 12:12:01 PM »

Copy & paste bug?

Code

string file = mbApiInterface.NowPlaying_GetFileUrl();
mbApiInterface.NowPlayingList_QueueNext(file);

MusicBee ignores the given file and adds the plugin DLL as the next song instead...

P.S., I'll post any other bugs relating to the API here instead of the general bug reports forum, if that's okay with you, Steven.

21

MusicBee API / Re: MusicBee API

« on: June 28, 2011, 10:29:30 AM »

Download code examples at the beginning of this topic.

Examples are great, but this is not what I'd call documentation... besides, it should be kinda obvious that I've looked at these files before, no? :-)

22

MusicBee API / Re: Ouch, threading...

« on: June 28, 2011, 10:18:00 AM »

Alright. Would it be safe(ish) to run the message pump manually while doing more stuff in a background thread? Is MusicBee locked on any Monitors or waiting on any threads or wait handles while Close() runs?

23

MusicBee API / Re: MusicBee API

« on: June 23, 2011, 02:35:40 AM »

With regard to this...
http://getmusicbee.com/forum/index.php?action=post;topic=3778.0;num_replies=2

This took me a bit by surprise... I, too, assumed that a plugin would get a TagsChanged notification whenever a file in the library had its tags altered...

I'm probably just too blind, but is there a complete documentation for the API somewhere? Such as what gets fired when, what the more obscure API calls actually do, and so on?

24

MusicBee API / Re: Ouch, threading...

« on: June 23, 2011, 12:38:01 AM »

Oh sorry, that didn't come out clear. By "told to quit" I meant "clicked the X button on MusicBee's main window", the point being that MusicBee is quitting due to a user-generated event, which a plugin may want to respond to in some way.

on recieving the quit message MB sends a Stop AutoDJ message on the plugin thread (which perhaps should not be sent at all if the application is closing because of timing issues)

Timing is one issue, another is that while a plugin is receiving notifications, it should not have to worry about MusicBee possibly being in a weird state, such as the middle of shutting down.

25

MusicBee API / Ouch, threading...

« on: June 22, 2011, 03:17:48 PM »

I'm going to post this hoping that it'll help others avoid my stupid blunders... and hoping that Steven might have a bright idea how plugins can be shielded from this complexity.

What I did:
- For debugging, print each received notificatio to a small window.
- The window runs on MusicBee's main thread.
- Messages are printed by Invoke'ing the textbox control (owned by the main thread).
- I prevented the plugin from running entry points (PluginClosed, NotificationReceived, etc.) concurrently.
Sounds innocent enough, right?

Here's what happens:
- MusicBee gets quit, which gets handled on the main thread.
- MB stops the auto Dj which results in a notification on a separate thread.
- On the worker thread, plugin tries to Invoke a control on the main thread, and Invoke locks.
- Back on the main thread, MB tries to run PluginClosed on the plugin, which conflicts with the blocking Invoke above and deadlocks.
- Alternatively, without the explicit locks, MB finishes shutting down; but when the main thread is free to handle the still waiting Invoke, the control that was originally invoked is now disposed and the invoking thread is thrown an exception.

So, what to do, what to do. In my case, I'll use an asynchronous BeginInvoke and catch the exception, but plugins that want to do some legitimate GUI work might run into problems here. How about if disposing the main window is delayed until plugins have finished closing on their worker thread? That way, the GUI thread could be freed up for plugins to do some last-minute user interaction.

26

MusicBee API / Re: MusicBee API

« on: June 06, 2011, 05:43:49 PM »

However, there are different fonts for buttons and labels -- at least the font size on MusicBee's own buttons is noticeably smaller then the font size used for most labels.

Do you have any guidelines on how large a plugins' configuration panel may get? Would modal dialog windows be acceptable?

27

MusicBee API / Re: MusicBee API

« on: June 01, 2011, 01:20:47 PM »

While you're looking at letting MB create custom-styled controls, would it be possible to add an API call to get the fonts and font sizes used throughout MB? (Especially for buttons...)

28

MusicBee API / Re: Bug in MB_GetWindowHandle

« on: May 29, 2011, 01:19:05 AM »

Yeah, maybe don't 'fix' the code but write some documentation for the API calls. ;-D


It's unbelieveable how rusty I've become with GUI code and heavy multithreading. Having spent the last year or so exclusively with Java-based lowlevel development (yeah, sounds strange...), I can't quite get my bearings with a huge framework like .NET... ^^;

29

MusicBee API / Bug in MB_GetWindowHandle

« on: May 28, 2011, 09:25:13 PM »

Man, it's been ages since I posted in this forum... ^^

Anyhow, I've been toying with the plugin API and I think I found a bug in MB_GetWindowHandle. When this delegate is called e.g. in response to the PluginStartup notification, the call is running on a background thread where MusicBee can't query the main Form's handle:

Code

       bei System.Windows.Forms.Control.get_Handle()
       bei #=qzjQScvhaxDGgseRKuAhV_kELbKEcrC_gcOcNkdsp1mc=.#=qrVSCRWSBIFxMCO4aVHPWuKX_K15AMOs2Pj2p4C4EKR0=()
       bei MusicBeePlugin.MusicBeeAPI.get_MainWindow()
       bei TestPlugin.TestPlugin.OnPluginStartup()

Ah, isn't .NET lovely...

30

MusicBee Wishlist / Re: Enhance duplicate files finding

« on: September 19, 2010, 04:27:18 AM »

Yeah, and 'R&B' is an example why matching like that is anything but foolproof.

According to your rules - remove "special" chars, collapse whitespace -, "R'n'B", "RnB" and "RNB" are all considered equal, while "R&B" differs. But the users will naturally expect that "R&B" == "RnB"...

Intelligent matching is a race between the programmer and users that the former can't ever win - not because we don't have the technology, but because no two people have the absolutely exact same idea of which two words are identical and which aren't. The best thing the program can do is to give the user the tools they need to get it to do what they want, which MusicBee already does quite well: have you checked out genre categories?