More > JRiver Media Center 32 for Linux
Linux, Mac, Windows Plugin Feature Request (MCWS need not apply)
ths61:
FWIW: Polling unrestricted increases response to 44ms, up from 8ms indicating the server is doing some governing to @ 22 Hz.
--- Code: ---
http://localhost:52199/MCWS/v1/Playback/Info?Zone=0
Found: Volume 0.670000
Found: Muted (0)
Found: State 2, RUN
Found: SampleRate 352800
Found: Channels 2
Found: Bitdepth 24
Found: ZoneID 0
Found: DurationMS 43066
Found: Status (Playin)
Average micros: 44388
--- End code ---
bob:
Currently under Remote in settings, there is a function called PlayPower.
It allows building a command list of things to do when the Play command is invoked including filtering on Media Type.
The only optional component on linux is called "Engen" which connects to a server we built for controlling z-wave devices. However when you select that, even if you don't have an Engen instance, you will have access to other commands, including MC commands and the ability to run external programs with parameters.
You could call a program, shell command, etc to send information to other apps, etc.
Right now it only hooks the Play command but that might be expanded if the function turns out to be useful for more general purposes.
ths61:
--- Quote from: bob on February 13, 2024, 09:32:51 am ---Currently under Remote in settings, there is a function called PlayPower.
It allows building a command list of things to do when the Play command is invoked including filtering on Media Type.
The only optional component on linux is called "Engen" which connects to a server we built for controlling z-wave devices. However when you select that, even if you don't have an Engen instance, you will have access to other commands, including MC commands and the ability to run external programs with parameters.
You could call a program, shell command, etc to send information to other apps, etc.
Right now it only hooks the Play command but that might be expanded if the function turns out to be useful for more general purposes.
--- End quote ---
Good to know for future reference, but spawning an app on every invocation is still very heavy weight with a lot of latency.
None of these solutions are as efficient as making the requested VST3 registered callback ONLY when state transitions occur ( e.g. basic Play/Stop/Pause/Resume/Volume=float/Mute=bool [state=value pair]). No binary to text and text to binary parsing either to pass a couple of numeric #define flags to an in memory shared object linked function.
bob:
--- Quote from: ths61 on February 13, 2024, 11:19:37 am ---Good to know for future reference, but spawning an app on every invocation is still very heavy weight with a lot of latency.
None of these solutions are as efficient as making the requested VST3 registered callback ONLY when state transitions occur ( e.g. basic Play/Stop/Pause/Resume/Volume=float/Mute=bool [state=value pair]). No binary to text and text to binary parsing either to pass a couple of numeric #define flags to an in memory shared object linked function.
--- End quote ---
Really it's not since those calls are only made on state transitions. It's nearly the same as a VST call.
ths61:
--- Quote from: bob on February 13, 2024, 01:14:32 pm ---Really it's not since those calls are only made on state transitions. It's nearly the same as a VST call.
--- End quote ---
Does it spawn an app and use CLI arguments ?
If so, then it isn't (have to [ access hard drive, load app, start app, parse CLI args ], and finally, make the fx call).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version