Windows > Plug-in Development

Linux FireMJEvent callback questions

(1/3) > >>

ths61:
Is the FireMJEvent() in-shared-object callback supported in Linux ?

If so, is there an example code snippet to register the FireMJEvent() callback function pointer in Linux ?
 
All examples appear to be Microsoft centric.
The SDK does not use FireMJEvent in any of its examples (Microsoft or other).


--- Code: ---3.3 Handling the events from Visual Basic
3.4 Handling the events from Visual C++ with MFC
3.5 Handling the Events from Visual C++ with ATL

--- End code ---

https://wiki.jriver.com/index.php/Media_Center_Automation

The docs above indicate the following:


--- Code: ---The first parameter is the event type and currently there is just one event type, namely "MJEvent type: MCCommand" The second parameter identifies the MCC command.
 MCC: NOTIFY_PLAYERSTATE_CHANGE

    Fired when a the player state changes
        A new track starts to play
        Playback is stopped, paused, or started
    string3 is the zone

--- End code ---

Is it possible to include specifically which of the 3 states has been changed in the NOTIFY_PLAYSTATE_CHANGE callback (stopped, pause, started) ? 

Signaling something has changed is not very useful (latencies, race conditions, extra query overhead) without identifying what has changed.

Should there be a separate Linux and MAC Plugin development threads ?

TIA

Hendrik:
The Automation is only supported on Windows, as it uses Windows specific automation interfaces.

ths61:

--- Quote from: Hendrik on February 04, 2024, 04:58:39 pm ---The Automation is only supported on Windows, as it uses Windows specific automation interfaces.

--- End quote ---

Thanks for the confirmation.

Can an efficient optional registered callback interface for Linux be added to notify the plugin of these playback state changes without incurring network overhead, network latencies and race conditions ?

It might encourage more plugin development.

Thanks much.

mattkhan:
a websocket that broadcasts changes would be better imv and abandon the plugin approach entirely

ths61:

--- Quote from: mattkhan on February 05, 2024, 02:43:57 am ---a websocket that broadcasts changes would be better imv and abandon the plugin approach entirely

--- End quote ---

Still need the Steinberg VST3 plugin interface (which uses registered callbacks, much less overhead, latency and no parsing).

Navigation

[0] Message Index

[#] Next page