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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
