[PD] Interruption of audio / Loading sound into array

[Jonathan Wilkes]

----- 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?

-Jonathan

> 
>>  [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 
> similar.
> 
> 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 -> 
> http://lists.puredata.info/listinfo/pd-list
>