[PD] Interruption of audio / Loading sound into array
jancsika at yahoo.com
Fri Nov 4 18:51:12 CET 2011
----- Original Message -----
> From: Mathieu Bouchard <matju at artengine.ca>
> To: katja <katjavetter at gmail.com>
> Cc: pd-list at iem.at
> Sent: Friday, November 4, 2011 12:21 PM
> Subject: Re: [PD] Interruption of audio / Loading sound into array
> Le 2011-11-04 à 11:26:00, katja a écrit :
>> By coincidence I noticed an svn commit access request from Damian
>> Stewart, back in 2008, where he proposes to 'implement multithreaded
>> [soundfiler] read'
> But (multi)threaded [soundfiler] had already been implemented in 2005 (or
> 2004 ?) by Tim Blechmann.
> This and other things didn't get accepted by Miller's branch. In the
> end, Blechmann decided to become a SuperCollider developer and apparently has
> stopped using pd.
> His threaded [soundfiler] is not in 0.43 either.
Well if it works it should go into Pd-extended 0.43. But if it goes into Pd-extended
0.43, who will maintain it if there are bugs?
>> [readsf~] and writesf~] are threaded, they operate in a child process.
>> I guess it could not be otherwise? Because they do not intend to read
>> all samples at once.
> No, they could read it with a single thread, but it would be bad for latency,
> because the process could be blocked while waiting for the harddisk, and on top
> of that, the non-blocking mode (of read/write) usually doesn't work for
> ordinary files (when I tried, it only worked on pipes and sockets and perhaps
> some other things, but not ordinary files).
>> Looking at the code in d_soundfile.c, I can understand why the whole of Pd
> should not be multithreaded.
> Look for a branch named devel_0_39.
> I don't find anything named like « threaded soundfiler » in the sourceforge
> tracker, so, it's possible that it hadn't submitted. But that might have
> been already the time at which we started to doubt that things submitted in the
> tracker forms were likely to be accepted.
>> It is a lot of overhead. But [soundfiler~] read is another exceptional case
> indeed, it needs carefully scheduled loading if it is not to cause buffer
> underruns elsewhere. Such loading in portions would also mean the whole
> audiofile is not immediately available in memory. Therefore, the result would
> somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick.
> If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller to
> publish it as an abstraction with pd, which would be called soundfiler2.pd or
> But no abstractions at all are provided with pd, except demos in the tutorials.
> Which is weird for software in which most users rely heavily on abstractions.
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list