Apologies for the confusion. The plugin was a one-day Epic Friday thing that really was just an experimental example and not intended to be used further and due to some limitations with the plugin system when it was done, got inadvertently not marked editor only and experimental. I’ve been very impressed (and surprised) with the things people have done with it.
If you were to look at the code, it relies on having access to the raw wave data which is removed during the cooking/packaging process as only the platform processed data (OGG for most platforms, but not all) data is needed for a runtime game. As with many of the limitations of the sound system, a lot of this stems from the fact that we don’t currently have a software mixer and instead rely on the hardware to process the data for us. On some platforms, such as PS4, this means that we never have access to the raw wave data necessary to run the data through the FFT algorithms because the hardware itself does the work. All this is something that is going to hopefully be changing for the better in the medium term future as we have a full time sound engineer starting next week, but that doesn’t help you out today by any means.
To make the plugin work with packaged content, it will need to be rewritten/restructured to use the platform data instead of the RawData property of USoundWave and that is not something that will be identical (or even doable) for each platform. For the OGG platforms, for all sounds that are decompressed on load (driven via the Sound Group settings in Base/DefaultEngine.ini) you may well be able to get away with simply using the RawPCMData, SampleRate, and some other cached properties instead of extracting them from Wave Header in the RawData, it will require a bit of investigation and experimentation for sure. For non-OGG platforms, I’m not entirely sure what would be needed.
For your job description you are going to be better off looking for someone who has some background in audio programming.