[PD] How's Pd limited?

[Matt Barber]

This is doable, actually, but not easy. [delay] and [vline~] both have
subsample accuracy. It would be substantially easier if you could
preprocess and deliver the sequence as one big message dump to [vline~]. If
you loaded all of the files into one array (up to about 6:20 of audio at
44100) and kept tabs on where each one started and how long it was in
samples and milliseconds, you could then feed [vline~] into [tabread~] to
play the relevant chunk of the array. If you needed to be able to transpose
them, that's a little harder because depending on how long the table was,
you'd need to work in the message onset to [tabread4~]'s right inlet or
face index degradation.

On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt <composer.samuel.burt at gmail.com
> wrote:

> David,
>
> One thing I attempted and couldn't find a solution for was the following,
> mostly owing to the limitation of interfacing with a 64 sample block size.
>
> I wanted to have a directory of hundreds of audio recordings. Each one
> would be a single wavelength from an interesting sound, like a bass
> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
> at a zero crossing so you could chain them together to make complex
> timbres. They could be chained in sequence, randomized, or loaded in
> meta-data-matched chunks. I ran into a problem figuring out how to trigger
> the next sound based on the ending of the last sound in a sample accurate
> way. Sound file loading or even buffer playback triggering waits until the
> start of the next block size before it updates. If you have a waveform that
> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
> the next waveform would start. Not only do you not get the continuous sound
> you want, this winds up creating a periodic pattern with a frequency of 689
> Hz (44100/64).
>
> David, I like your idea "what (if anything) someone tried to do in Pd, but
> couldn't given its limitations". I think this could be a wonderful
> challenge if we could have a monthly thread like this where the best minds
> among us come up with solutions to some of the hardest conceptual
> challenges in Pd.
>
> I'm still struggling with loading dozens of files, audio dropouts, and
> other similar problems. Someone else expressed frustration about Pd's
> single-threaded status. I too have feared upgrading my computer based on
> the limitations of current multicore processors (although realistically I
> think we can all look at the "turbo-boost" level or whatever Intel calls it
> to determine where our processor might run with a demanding patch. I
> understand the fact that you can't run your audio process on multiple
> cores, because it is a linear process. It would be great if the GUI could
> run on a second core, a process that loads audio into memory could run on
> third core, while GEM could automatically run on a fourth core. I don't
> have any concept of how feasible that would be, though. Does the GUI in
> pd-l2orc run on a separate core?
>
> Sam
>
>
>
>
>
>
>> Message: 4
>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>> From: david medine <dmedine at ucsd.edu>
>>
>> One thing I'd be interested in knowing about is what (if anything)
>> someone tried to do in Pd, but couldn't given its limitations (apart
>> from look/feel/convenience issues).
>>
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160223/9741a391/attachment-0001.html>