I don’t get what’s going on. @synthi?
PS isn’t that oval select snazzy?
are you able to record normally ? at the end of a standard process do you get a normal “.wav” file ?
(those 2 are byproducts that should be deleted at the end of the process)
the new engine stream everything in PCM file at the end of the process (STOP recording) uses a separated worker thread to convert the file in the desired format “WAV”
if you generally are able to record wav files and you see these 2 maybe a crash happened ?
Or maybe there is a permission problem on your system a wav3 is just a “wav” 24bit but with a different extension
wonderful OVAL selection !
I think I sometimes close Rack after recording too soon. It is very confusing though. If there’s post-processing happening after one hits stop it would be good if there was some visual feedback. Or if you could trap and prevent the app from terminating until it’s done.
1 Like
for MR2 we are talking about a couple of msecs of post process;
and yes the postprocess is able to do everything you can delete a MR2 during recording and the operation will be successful but I can’t prevent from a detached thread the closing of the app
Why are you detaching threads? I’d recommend not doing that and joining them in the destructor.
~Module::Module() {
thread.join();
}
because they are tasks very specialised and autonomous that can execute one shot and thrown away
I’ll try to refactor attempting a join
One-shot disposable threads are “task workers” and you’d definitely want to join them in a destructor so you can make sure the data they’re processing is valid during their lifetime.
1 Like
that’s exactly why you would thread.join() in the destructor, otherwise the thread will be killed in the middle of its lifecycle. joining in the destructor allows for any threads that are still running at destruction to quickly finish their tasks and exit gracefully.
1 Like
changed (for all 3 main recorder) (will be in release 1 0 9)
3 Likes