Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[paul1970]

OK, I'll have another stab at getting a reply...
When I started trying to write a Vis plugin I wasted some time trying to use the API linked to at DevZone before being told this was out of date, so I'm trying to avoid that happening again. There is some info I want in my Vis plugin that isn't available through the Vis C++ API (sample rate, song name etc). I'm presuming that to get at this information I need to use the automation interface(?). The automation interface detailed at DevZone is COM-based but I was told before that COM APIs had been dumped in favour of non-OS-specific APIs, so is what's at DevZone really what I need to use? Don't want to bang my head against a wall only to have to bin stuff again.

I really want to get this to work. If you're going to publish APIs please support them (and remove the misleading out-of-date information from your Wikis).

[glynor]

The COM interface still works but isn't very actively developed.  There are basically two options:

1.  COM -  Which is generally more powerful but requires the copy of MC that you're using to be locally installed (and is OS specific).

The Wiki is pretty good for the COM interface.  The SDK examples are all just quite old.  If you're interested, I have a wrapper class in C# for COM (and the MCC windows messages, etc).  I can give you a copy if you'd like.

2.  MC's REST Interface -  This is what the Media Network and Library Server system is built on.  This is a web framework, is self documenting, and is generally more modern (and can connect to remote copies of MC across the network, of course), but is somewhat more limited currently.

To access documentation for the REST interface, just connect to your Library Server via a web browser.

[glynor]

I should mention... The main remaining deficiency of the REST based interface over COM is when trying to modify a Library's views.  If you are just pulling information about files in the Library, or the library itself, Media Network will work well.  COM has just a few capabilities over the REST interface in this area, though really not too much.

But if you need to modify the Library itself (sounds like no, for your purposes) it won't be much help except for in very simple circumstances.

Again, though, COM works perfectly well.  If you want to pull details that way, you can.  Of course, if you want to write something that might end up working on the Mac version of MC, then using the REST based interface is the only option.

[paul1970]

Thanks for the information.
My Vis plugin is Windows-specific due to making use of DirectX and I expect MC to be installed locally for a Vis plugin. Sounds like the web sever has advantages, but I think it requires the user to enter an auth code which doesn't really suit this kind of plugin (I may have this wrong). On balance I think I'll stick with the COM interface. All I really needed to know was 'Is the DevZone documentation useful for simple purposes and does it still work under Windows?'.

Thanks for the offer of your C# wrapper. My plugin is all coded in C++, but I might tap you up for future projects if the offer is still open. Off to delve into the COM API then...

[glynor]

All I really needed to know was 'Is the DevZone documentation useful for simple purposes and does it still work under Windows?'.

Thanks for the offer of your C# wrapper. My plugin is all coded in C++, but I might tap you up for future projects if the offer is still open. Off to delve into the COM API then...

Yep, yep, and yep.

I'm going to actually publish my wrapper eventually, but it isn't done.  PM me if you want it though.

It is basically a Singleton pattern class for the core MJAutomation interface, that makes connecting to MC as easy as accessing a static property.  It also has a bunch of static methods (and some properties) that provide advanced functions and modify behaviors.  I haven't done any in-process automation so it might not be as useful for plugin use, but if you're doing stuff from "outside" of MC, it makes accessing it drop-dead simple.

There are essentially three things I'd like to add before I'd call it "done":

1. A MCWS sub-class for the REST based API.
2. Better wrapping for the Events MC raises through COM.  It can handle them, but it doesn't provide much more than the RAW COM API does now.  I'm planning to better wrap them with .NET-like EventArgs classes (the framework is there, but the classes just expose the raw info from MC directly).
3. Right now, it is mostly based around that Singleton with the Static classes.  That works great for my purposes, but it means that the wrapper itself can't be COM-visible (COM can't use Static methods or properties).  That means that you can't use it from VBScript, which is too bad, because otherwise you could just call my DLL and write easy-peasy VBScripts to do stuff.  I'm going to add a COM-visible wrapper for the wrapper at some point (that is an instance class that simply calls the core classes' methods and properties).

I'm still trying to decide how best to do part 3, and... You know, looking for motivation.

[paul1970]

... You know, looking for motivation.

Sounds like quite a bit of work. It would seem rude not to use it for something.