I'm doing this to test if I don't get an audio dropout in the main patch by running the batch in a pd subprocess.
With [pd~], the parent process "drives" the subprocess. If the subprocess blocks (beyond the given delay time), the parent process also blocks.
No audio is generated at all, I get an audio with 0 seconds.
I checked the code. "sched_fastforward" is only used in the polling scheduler. This means "fast-forward" has no effect in the callback scheduler or in a plugin scheduler (e.g. the one used by the [pd~] subprocess).
Open an issue on GitHub!
Christof
On 17.08.2020 16:52, Alexandre Torres Porres wrote:
I'm having a problem using 'fast-forward' in a patch loaded via [pd~].
I'm doing this to test if I don't get an audio dropout in the main patch by running the batch in a pd subprocess.
The patch runs fine and generates 10 min of white noise. This does cause an audio dropout (much shorter than I expected, wow), so yeah, time to test it inside [pd~]. What happens? No audio is generated at all, I get an audio with 0 seconds.
Perhaps this is something that got overlooked (allowing 'fast-forward' in [pd~])?
If so, clearly, this is something we'd all agree would be great to have, right? :)
Cheers