Print

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

[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: [Select]

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

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

The docs above indicate the following:

Code: [Select]

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

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]

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

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]

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

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

[mattkhan]

Still need the Steinberg VST3 plugin interface (which uses registered callbacks).

VST is different thing to an MC plugin, I'm referring to the windows specific plugin interface once used for "automation" purposes. Everything these days is directed to MCWS but the broadcast state part is missing.

[ths61]

VST is different thing to an MC plugin, I'm referring to the windows specific plugin interface once used for "automation" purposes. Everything these days is directed to MCWS but the broadcast state part is missing.

I think this is good reason for there to be a separate Linux Plugin thread/section since my OP is specifically for Linux (Linux FireMJEvent callback questions). 

I would like fast, lightweight, tighter tolerances for VST3 plugin processing, else the race conditions would render them useless.

[mattkhan]

what does VST have to do with this thread?

[ths61]

what does VST have to do with this thread?

(Plug-in Development) Really ?

https://yabb.jriver.com/interact/index.php/topic,126706.msg878408.html#msg878408

< Add / Remove VST3 Plugins Here >
 

[JimH]

mattkahn,
Feel free to split.

[mattkhan]

(Plug-in Development) Really ?

https://yabb.jriver.com/interact/index.php/topic,126706.msg878408.html#msg878408

< Add / Remove VST3 Plugins Here >

It's a different thing entirely to https://wiki.jriver.com/index.php/Media_Center_Automation which is about interacting with MC itself using its own API. VST is a 3rd party API which is specifically used within the DSP engine and so it strictly concerned with signal processing only (which the MC API is not concerned with)

[ths61]

It's a different thing entirely to https://wiki.jriver.com/index.php/Media_Center_Automation which is about interacting with MC itself using its own API. VST is a 3rd party API which is specifically used within the DSP engine and so it strictly concerned with signal processing only (which the MC API is not concerned with)

Don't be so obtuse.  Both are plugins, both are written for MC with one being more ubiquitous and applicable to more than 1 host.

They are NOT mutually exclusive as you are implying.

Have you ever used a string library with a math library to create a single shared object ?

Are all of your programs limited to a single header file and single library linked ?

This appears to be the irrelevant off topic point you are trying to repetitiously make.

[ths61]

In the attempt to keep this thread productive and on topic:

Would it be possible to define a set of states supported by MC (Play, Pause, Stop, Gain=value, Mute, etc.) and then pass the state transitions through the VST3 interface such as the following which implements sample-accurate parameter changes ?

Note: If this is implemented through the Steinberg VST3 interface, it would not be limited to a "Windows Only" feature (3 OSes, 1 implementation/interface).

TIA

Code: [Select]

    Advanced VST 3 techniques

On this page:

    Part 1: Sample-accurate parameter handling
    Part 2: Adding 32 and 64 bit audio processing
    Part 3: Thread safe state changes


https://steinbergmedia.github.io/vst3_dev_portal/pages/Tutorials/Advanced+VST+3+techniques.html#part-3-thread-safe-state-changes