Messages

1

Plugins / Re: Additional Tagging and Reporting Tools

« on: August 14, 2011, 02:36:26 PM »

The common way to do this is to have a central work queue. Whenever the user confirms an operation, an object representing that operation is pushed into the work queue and a thread backing the queue is pinged. The worker thread associated with the queue simply runs the operations in the queue in order and sleeps when the queue is empty. This provides serialization (i.e. operations which iterate through a library query do not overlap and close each others' queries) and you can add any kind of UI to this, such as a little window that pops up while the queue is non empty, showing a label for the operation in progress, a progress bar and an abort button. If you're careful not to do any actual work in that window's UI code (shouldn't be a problem, after all it merely controls the worker thread and doesn't do the actual work), you can even put this into the MB GUI thread without causing problems.

Steven, couldn't you return a query "handle"? The initual query returns a handle, GetNext requires this handle and once done, the handle is disposed with an EndQuery call. That'd allow for simulatenous queries in a C++-like fashion and C# devs could roll the handle into a custom enumerator which calls EndQuery upon disposal / finalization.

2

MusicBee API / Re: NowPlaying vs. Library

« on: August 04, 2011, 10:30:48 PM »

Ok, will do and test again.

3

MusicBee API / NowPlaying vs. Library

« on: August 04, 2011, 12:06:56 AM »

I'm trying to update tags in a file in the now playing list that wasn't added to the library. Library_SetFileTag returns true (I'm assuming this means that the tag value was parsed ok), but Library_CommitTagsToFile -- which I'm only calling because a NowPlaying_CommitTagsToFile isn't available -- returns false and the tags aren't updated.
Is it at all possible to change the tags of a file that isn't in the library?

4

MusicBee API / MultiArtist and MultiComposer

« on: August 03, 2011, 11:26:03 PM »

I can't find the original post right now, but I believe Steven said the MultiArtist tag contains the list of artists separated by 0-bytes. I'm getting an additional \0 at the end of the string, i.e. "Ray Charles\0\"Joliet\" Jake Blues\0". Is that by design for better compatibility with C/C++ where you read up to the next \0, or should I assume that the list contains three artists where the third is the empty string? Right now I tend to just ignore any trailing \0's before splitting the tag because MB returns the empty string (no \0's at all) when the tag is unset.

5

MusicBee Wishlist / Re: switch from mediafire to a better content distribution system

« on: July 27, 2011, 01:34:13 PM »

Eh, and Bittorrent isn't "associated with pirated software"?
If you can host a dedicated tracker and a reliable seed, you might as well just run a webserver instead and put the files on there, anyways.
Also, having to download MusicBee via Bittorrent would deter lots of users from trying out MB in the first place. Not everyone knows how to use Bittorrent, and a sizeable fraction of users are notoriously lazy.

6

MusicBee API / Re: Impact of plugin callback methods on playback

« on: July 24, 2011, 03:08:45 PM »

Okay, good to know. Tho now I wonder what the debugger does that the audio stream jitters. 

7

MusicBee API / Impact of plugin callback methods on playback

« on: July 24, 2011, 05:42:44 AM »

I've noticed that the debug version of my WiP plugin causes MusicBee's audio playback to slightly stutter whenever I'm doing something that could take longer then a couple microseconds, such as doing blocking file or network I/O on the thread where MusicBee delivers notifications. With the release build and no debugger attached to the process, there are no stutters. Those jitters could be a side-effect of the debugger, but I'm not conviced.

Is it okay for a plugin, in general, to use MusicBee's notification delivery thread for performing potentially costly tasks, or would that collide with other plugins or MusicBee's internals?

8

MusicBee API / Re: MusicBee API

« on: July 23, 2011, 03:42:34 AM »

Just return true from Configure and MusicBee assumes that you have handled configuration and won't show the default about dialog.

9

Plugins / Re: Additional Tagging and Reporting Tools

« on: July 07, 2011, 03:47:31 AM »

".rar" files are compressed archives. The actual plugin file is inside the archive, and you need a program capable of handling RAR archives to read the archive and extract the plugin file, such as the free 7-zip program (www.7-zip.org).

10

MusicBee API / Re: MusicBee API

« on: July 06, 2011, 02:03:30 AM »

I've pushed my plugin API wrapper to github: https://github.com/Elberet/MusicBeeAPI

You can either fork the repository with any implementation of Git or download an archive. Some highlights:

• the PluginInfo struct returned to MusicBee is populated from assembly and plugin attributes. See Properties\AssemblyInfo.cs.
• only Initialize, Dispose and PluginConfigure remain as plugin entrypoints, everything else is driven by event listeners. Example below because it breaks the list if used inline...
• different plugin types can be specified in the frontend attribute: [PluginFrontend(TargetApplication="app", PluginType=PluginType.ArtworkRetrieval)]. This also requires that the frontend class implements the IArtworkProvider interface, but that constraint is checked at runtime only.
• currently incomplete: MultiArtist and MultiComposer tags, querying playlists, querying the library, storage plugins, many methods in the now playing list wrapper, miscellaneous.

Example: listen to TrackChanged events and print the changed-to track's title on the console. (Not terribly useful since there is no console, but the code works.)

Code

using System;
using System.Windows.Forms;
using MusicBeePlugin;

namespace ExamplePlugin
{
    [PluginFrontend]
    class Example : IPluginFrontend
    {
        void IPluginFrontend.Initialize(IMusicBeeAPI api, out int configPanelHeight) {
            configPanelHeight = 0;
            api.PluginStartup += PluginStartup;
        }

        private void PluginStartup(NotificationEventArgs args) {
            args.API.TrackChanged += TrackChanged;
        }

        private void TrackChanged(NotificationEventArgs args) {
            Console.WriteLine(args.RelatedFile.TrackTitle);
        }

        bool IPluginFrontend.PluginConfigure(Panel configPanel) {
            return false;
        }

        void IDisposable.Dispose() { }
    }
}

11

MusicBee API / Re: List of auto generated music urls.

« on: July 05, 2011, 11:37:05 PM »

That explains a lot. So, essentially, MusicBee shouldn't care whether I say
NowPlayingList_PlayNow("E:\\Temp\\test.mp3");
or
NowPlayingList_PlayNow("file:///E:/Temp/test.mp3");

Correct?

12

MusicBee API / Re: List of auto generated music urls.

« on: July 05, 2011, 07:54:55 PM »

The variable name "Uri" is somewhat misleading, I think. MusicBee accepts standard Windows paths for the PlayNow and Queue* commands (hint: those aren't URIs at all) and will actually refuse to open the same files when given as valid file:// URIs. MusicBee's Uri parameters are most likely more closely related to its database entries (which reference files on a local harddisk, after all) then actual URIs.

A clarification would be nice, tho, and I'd prefer if any exchange between MusicBee and plugins was using actual URIs.

13

MusicBee API / Stop after current

« on: July 05, 2011, 11:19:11 AM »

Hm, I'm writing documentation for my wrapper, and these little things crop up...

Anyways, StopAfterCurrent is incomplete, or rather it's missing a corresponding API call to cancel the stop-after-current request (result: MB keeps playing after the current file, as if StopAfterCurrent had never been called), a notification that the stop-after-current trigger is set and a getter call to find out if stop-after-current is scheduled - alternatively, a new PlayState flag.

I'm sure some desktop gadget might be able to use this productively...

14

MusicBee API / Auto-Dj

« on: July 05, 2011, 10:09:03 AM »

Another one of these minor things.

One can derive the state of Auto-Dj from the two notifications, but there's no guarantee that the Auto-Dj is in a certain state when the plugin is started. So Until the first time one of these messages is received, it's impossible for a plugin to determine if the Auto-Dj is running or not.
Suggestion for v1.3: bring Auto-Dj in line with Volume, i.e. a delegate to get the Auto-Dj's state (bool, false = stopped, true = running) and a single notification when it's state is changed.

15

MusicBee API / Re: MusicBee API

« on: July 04, 2011, 03:13:02 PM »

Right. I'll clean this up and put a preview version on GitHub or something.

---

Now to something completely different (not!): NowPlaying_GetDuration returns the current playback duration as an integer number of milliseconds. Library_GetFileProperty and NowPlaying_GetFileProperty when called with FilePropertyTag.Duration return a less precise formatted string. This is weird, and I'd prefer milliseconds in all three cases. :-/