2020-09-25, 16:00
Hello,
I know I have absolutely no reputation on this forum. I'm hoping someone will overlook that and help out with the following questions...
The motivation for the above questions is the goal of making the most-recent contents of the freqData array passed to CInstanceVisualization::AudioData() available to Python service addons. It seems like it shouldn't be too hard to make an atomic copy of the freqData array and "hold onto" it until it is requested. Making use of a pull communication method also ensures that one doesn't overwhelm the Python addon itself with too frequent calls. Some manipulation of the freqData could occur on the C++ side first, like grouping into bins as in StarBurst's implementation of AudioData().
With Kodi performing the FFT, I wouldn't think there would be too much data to store, particularly with only keeping the most-recent data. I'm certain regarding the best way to implement the communication, though, and would greatly appreciate any suggestions.
Forwarding audio and/or frequency data to Python addons (when requested) seems like it could enable some interesting display implementations or even audio analysis. The topic did come up previously, in early 2015:
Expose AudioData to python addon
My goal is summarized in a recent CoreELEC thread on a graphical front panel display.
Finally, and mostly out of curiousity, is there a reason why Kodi's built-in Spectrum Visualization doesn't specify wantsFreq and makes no use of freqData? Was calculation of the FFT just too expensive on the early platforms that were running (at the time) XBMC?
Thanks for your time,
Matt
I know I have absolutely no reputation on this forum. I'm hoping someone will overlook that and help out with the following questions...
- Is Kodi's JSON-RPC extensible by (both C++ and Python) addons?
- In particular, is it possible to use JSON-RPC as a communication method between, say, a visualization addon and a Python service addon or would some alternate mechanism be more straightfoward?
- Would anything untoward occur if a visualization addon had an empty implementation for CInstanceVirtualization::Render()? For instance, if a user has such a non-rendering visualization addon selected, would that then prevent running something the Artist Slideshow while music is playing?
The motivation for the above questions is the goal of making the most-recent contents of the freqData array passed to CInstanceVisualization::AudioData() available to Python service addons. It seems like it shouldn't be too hard to make an atomic copy of the freqData array and "hold onto" it until it is requested. Making use of a pull communication method also ensures that one doesn't overwhelm the Python addon itself with too frequent calls. Some manipulation of the freqData could occur on the C++ side first, like grouping into bins as in StarBurst's implementation of AudioData().
With Kodi performing the FFT, I wouldn't think there would be too much data to store, particularly with only keeping the most-recent data. I'm certain regarding the best way to implement the communication, though, and would greatly appreciate any suggestions.
Forwarding audio and/or frequency data to Python addons (when requested) seems like it could enable some interesting display implementations or even audio analysis. The topic did come up previously, in early 2015:
Expose AudioData to python addon
My goal is summarized in a recent CoreELEC thread on a graphical front panel display.
Finally, and mostly out of curiousity, is there a reason why Kodi's built-in Spectrum Visualization doesn't specify wantsFreq and makes no use of freqData? Was calculation of the FFT just too expensive on the early platforms that were running (at the time) XBMC?
Thanks for your time,
Matt
