Reliable printouts in plugin?

Developers
#1

Hi guys, I am trying to work on my plugin, and would like to see some printouts to understand the current state of my plugin fresh built and running on MDX.

I am using DPF, and d_stdout function to print, and journalctl -f to see the output.
Result, however, is completely unreliable - quite a lot of prints just do not appear - for example prints from “activate” “deactivate” or plugin constructor function may appear or not appear in the log, or appear with a huge delay, printout to show setParameters event data almost never shows printout for the several last parameter changes, messages appear in blocks, or output can be silent for several minutes or messages never arrive.

Is there any way to get my prints reliably? I am a bit confused how to proceed further being that blindfolded.

P.S. printf was not any better. Also there is some disrupting dark magic happening when using prints in run() function, for example, adding print before sending midi note seems to work, but adding print after sending note breaks plugin and it stops sending anything to midi. Realtime stuff is strange, is it really easier to process megabytes of samples, running neural networks and applying complex effects than send 24 bytes to stdout…

#2

DPF does not support this for the moment.
LV2 has extensions to get logs from plugin into the host (CLAP does too by the way), but I haven’t implemented this on the DPF side yet.

“print” is not a realtime-safe operation because it involves locking and waiting, so it causes xruns and problems for audio. it is not about the amount of cpu it consumes, but that it waits on other resources.

4 Likes
#3

Makes sense, thanks.
Would try to modify DPF lib code to inject an LV2 logger method then.
Or maybe I would have some luck with writing to pipe file made with mkfifo, do not know if it is any better in terms of real time.

UPD: Writing to pipe seems to work for me of sort, at least messages appear fast in the pipe,
where I can catch them with tail -f, but plugin midi output still can be broken by unluckily placed pipe writing even with O_NONBLOCK , so I assume it is not real time safe either. But already better anyway.