Print

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

[Zoner]

As I've already posted about here several times, I'm working on getting Russound's CAV6.6 system connected to MC10 such that you can use Russound's keypads to control up to 6 MC zones in up to 6 rooms simultaneously.  The software is now functionally complete, but I have come across a major issue with the MC COM object which looks like a show-stopper.

The problem is how to update the keypads with track/artist info.  MC10 doesn't provide any event mechanism to notify me about track changes, so I have to poll, which works OK as long as only one zone is active.  However with 6 zones active I need to poll them all, and here's where it gets really ugly: I have to change the active zone in order to poll it.  In order to avoid a noticeable lag in the keypad display, I have to poll each zone at least once every 2 seconds.  With 6 zones, that means I have to switch zones and poll 3 times per second.  Not only does this burn quite a bit of CPU, but it makes it completely impossible for me to use MC, since the current zone is constantly changing.

This is a real show-stopper for this project, which I've invested thousands of dollars and hundreds of programming hours into so far.  I am prepared to do whatever it takes to get around this (eg write a plug-in), but right now I can't see any solution.  I tried to use Spy++ to see if I could see any windows messages I could tap into help the situation, but it freezes up the whole PC, which is weird.

What I really *need* is "read-only" access to a zone without making it active, so that I can check the currently playing track name/artist and update the keypad displays.  Then I could poll without affecting the MC10 GUI, and it would be OK to use the MC10 GUI as long as no-one pressed a key (eg next-track) on one of the keypads.  If I could get this, I would be a happy camper.

What I really *want* is full read/write access to all zones without having to make them active, and an event-based mechanism for detecting track changes.  Then I could mess around in zone 1 using the MC10 GUI while my wife is flicking through a playlist in the kitchen (zone 2) and the kids are listening to their stuff on zones 3 & 4, all without burning up the CPU with excessive polling.  If I could get this, I would be extatic and eternally grateful.

[Matt]

MC 11 allows you to access and control a zone without switching the active zone.  I think it's exactly what you're looking for.

We may add an event system, but there are some issues with firing synchronous events to third-party plugins in areas of the program where speed is important.

Thanks Zoner, and keep us posted on how the project proceeds

[Zoner]

WOOHOO!!!!!!! YES! YES! YES! YES!  THANK YOU MATT!!!!!!!!!!!!!!

From the latest COM documentation in DevZone:

MJZoneAutomation * GetZone(number nIndex) (requires MC 11.0.20 or later)

Description: gets a MJZoneAutomation interface for this zone (see below)
Return Value: MJZoneAutomationinterface

MJZoneAutomation - interface for working with a single playback zone (requires MC 11.0.20 or later)

Functions

string GetName()

Description: gets the name of the zone
Return Value: the name of the zone

MJPlaybackAutomation * GetPlayback()

Description: gets a MJPlayback interface for this zone (see above)
Return Value: MJPlayback interface

MJCurPlaylistAutomation * GetCurPlaylist()

Description: gets a MJCurPlaylistAutomation interface for this zone (see above)
Return Value: MJCurPlaylistAutomation interface

------------------------------------------------------------------------
Listening to "I'm so excited" by "The Pointer Sisters"

[Zoner]

Matt - I have a question about the new MJZoneAutomation object and threading.  Would it be safe to create six MJZoneAutomation objects (each one representing a unique MC11 zone), and then create 6 threads to poll the zones?  That would be the simplest implementation for me, but before embarking on that, I wanted to make sure that this was a reasonable strategy from MC's point-of-view, or if there are any gotchas I should watch out for.

[Zoner]

One more thing about firing events: my experience is that the best way to do this is to just add them to a queue, and then have a seperate thread (at lower prio than your timing-critical threads) dedicated to firing them one at a time.  That way you ensure that the events get fired in the correct order without slowing down anything important.  This is exactly how I've implemented it in my software: one thread watches the RS-232 stream and queues events to another thread which is communicating with MC.

From my perspective, this event strategy would be perfectly acceptable if implemented within MC: I don't really care whether the event gets fired at the exact millisecond when MC switches tracks.  Just as long as I eventually get notified, and that the events arrive in the right order - that would be fine.

[RhinoBanga]

Having a delayed notification may introduce timing issues.   For example I have a text-to-speech option in playing now (undocumented at the moment) that announces the playing track.   Using a delayed event mechanism may produce a situation like this:

Track X plays
MC logs "playing track X" to the event queue
Track Y plays
MC add "playing track Y" to the event queue
The event thread gets some CPU and sends the first event
Plugin receives the event saying that Track X is now playing and announces it ... wrong


Although an unlikely situation it is still possible to happen.


I vote for immediate notification.

[Matt]

Matt - I have a question about the new MJZoneAutomation object and threading.  Would it be safe to create six MJZoneAutomation objects (each one representing a unique MC11 zone), and then create 6 threads to poll the zones?  That would be the simplest implementation for me, but before embarking on that, I wanted to make sure that this was a reasonable strategy from MC's point-of-view, or if there are any gotchas I should watch out for.

Should be fine.  Just never use a single instance of an object from two threads at once.  Use critical sections, or better yet, create a new instance of the object in each thread.

Also, 6 threads may be overkill -- rolling through the 6 zones in one thread is probably faster than you'd guess.

[Zoner]

Having a delayed notification may introduce timing issues.  

That depends on how much data the even contains.  If the event simply said "the current track has changed", then the data would never be stale.

[Zoner]

One more question for Matt (thanks for your answer, BTW): do I have to delete the objects returned by functions like GetPlayback() in some way?  It's a basic question, I know, but I don't do a lot of COM stuff.

[RhinoBanga]

That depends on how much data the even contains.  If the event simply said "the current track has changed", then the data would never be stale.

I would think that any event would tell you the affected file if appropriate, e.g. when a track gets updated.

Also if it didn't tell you then in my example you would hear the announcement of the same track twice unless you kept state information, which then means more work for the programmer and dilutes the usefulness of events.   For example imagine the WM_SIZE message not telling you the width/height of the change.   It would force every programmer to have to query the window to get the current size which is a waste since windows knows the information up-front.

One more question for Matt (thanks for your answer, BTW): do I have to delete the objects returned by functions like GetPlayback() in some way?  It's a basic question, I know, but I don't do a lot of COM stuff.

Normally with COM you have to do a Release() but MC objects are smart pointers and they take care of that for you.

[Zoner]

I would think that any event would tell you the affected file if appropriate.

But that would cause the problems you've already described.

Imagine the WM_SIZE message not telling you the width/height of the change.

But that's a very simple message, with very little data attached.  If a "next track" event was going to specify what had changed, then it would have to attach an IMJFileAutomationPtr object.  There are plenty of Windows messages that don't attach any data - they just inform you that a specific change has taken place, and let those who are interested dig deeper.  WM_TIMECHANGE springs to mind.  Not everyone is interested in every event at all times.

[Zoner]

Normally with COM you have to do a Release() but MC objects are smart pointers and they take care of that for you.

Thank you!

[RhinoBanga]

But that's a very simple message, with very little data attached.  If a "next track" event was going to specify what had changed, then it would have to attach an IMJFileAutomationPtr object.

Then that would show the problem if we had a delayed notification system.

There are plenty of Windows messages that don't attach any data - they just inform you that a specific change has taken place, and let those who are interested dig deeper.  WM_TIMECHANGE springs to mind.

That was the old message types.   Look at all the new ones and you will see that MS now supplies as much information as possible upfront.   Just look at all the LVN_* / TVN_* notifications.   Would it make sense for Windows to use PostMessage to send those instead of SendMessage?

Not everyone is interested in every event at all times.

Exactly.   You may not be interested in it but others are and they want as much information regarding the event as possible supplied to them.

[Zoner]

Well it seems like I'm not convincing you, and you're not convincing me, so I guess we're just going to have to agree to disagree !  I'd be happy with *any* sort of event-based notification system.  There are ways to work around all of the problems we've described in this thread, so it doesn't matter how Matt implements it - we'll both be able to do what we need to do.  The question is: will he implement it?  Only time will tell.  For now I'm very grateful for the additions already added in v11.

[RhinoBanga]

Well it seems like I'm not convincing you, and you're not convincing me, so I guess we're just going to have to agree to disagree

Hehehehehe ... I'll agree to that