I guess the proper solution would be to connect X-10 device to audio pipe with your amp... But currently I guess Media plugin sends commands to pipe connected devices only if they are of certain type (I'm talking this out of my memory - could be wrong about it)...

I see no obvious reasons, why this limitation is coded into Media plugin - am I wrong ? IMHO just any device capable of doing any related commands could be connected to pipes... It's user's responsibility what he will plug to pipes...

I'm not proposing submitting this solution to SVN, so what is the problem? If someone needs to do this right now then this will help them. They should not be able to do this on their own system - that's what your're saying? They should manually turn on their subs and active monitors just because you don't like it and it's not a perfect solution?! WTF?!!!

I'm not proposing submitting this solution to SVN, so what is the problem? If someone needs to do this right now then this will help them. They should not be able to do this on their own system - that's what your're saying? They should manually turn on their subs and active monitors just because you don't like it and it's not a perfect solution?! WTF?!!!

EDIT: Corrected spelling

There still is a type-o in the word "fuck".

Anyway, I think Bulek has got the right idea, we should test removing that limitation. And maybe even implement power pipes as Hari suggests.

if I may add further, when I encountered this problem I had an idea of generic pipe, where one could specify which commands will propagate... So audio, video pipes will be just special case of generic pipe with repdefined command set.

And important, user could be able to add whatever commands he thinks are right to be propagated through pipes...That is probably the ultimate way to solve this once for all.

Also usually similar systems have some kind of hooks in such places - so for instance you can trigger any event,scenario when something gets propagated through pipe (for instance prepend audio announcement sound prior speech announcement, etc...). Similar to events, but would trigger only on events on pipes. Maybe better idea is to have dummy GSD device that is attached to pipe and do whatever is needed there...

presumably you would like the options for synchronous and asynchronous events? So that with a sync event, you can indicate whether the event subscription should trigger before or after, and with async it is implied that the event triggers in parallel. sounds quiet useful, actually