[PD] New "fast-forward" message

[Christof Ressi]

> 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