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(a)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).
>
>