Yeah, this is a very very bad idea. One of the fundamental reasons you can’t get “sample accurate” timing in BP (without a fancy “scheduling” mechanism of some sort) is that BP executes on the game thread at a much slower tick-frequency than the audio thread. The audio thread is also not updating at “sample accurate” rates either. It’s updated at a rate equal to the sample rate divided by the size of the callback block (e.g. 48000 / 1024 frames) or roughly every 23 ms.
OnGenerateAudio() is called from the audio render thread (or a worker thread owned by the render thread). Any functions called from this function into BP (or any other game-thread-only code) will definitely cause crashes. Only do audio render thread-safe operations from this function – i.e. DSP/synthesis. Any parameters which are set from the game thread need to safely queue using some thread-safe mechanism. Look at EpicSynth1Component.cpp to see examples of how this is done. E.g. SynthCommand functions take a lambda as an argument and then queue the lambda to be actually executed on the audio render thread.
Getting audio render thread information BACK to the game thread needs to use a similar mechanism – i.e. you need to queue the information from the audio render thread to then be consumed on the game thread. Usually use the ::Tick function on a tickable object and TQueue to queue the information. See SourceEffectEnvelopeFollower.cpp for an example of how I did that for the envelope follower source effect (which gets audio-thread information, i.e. the envelope of a sound, and sends that to the game thread for delegate notification in BP).