This doesn't answer Matt's question at all (apologies), but just as a
clarification, ChucK /does /block audio. It's just that ChucK always
blocks at the minimum size of 1 sample per block. 1 is still a block
size though, and it still implies the same problems associated with
order of operations, feedback, interpolating control input, and
parallelization that a block size of 64 does.
Also, maybe this has already been pointed out on this thread, but block
1 is super slow because it means that you have to load all your DSP
functions onto the CPU cache every 1/SR seconds instead of 64/SR
seconds. Blocking by 64 buys a lot. Having a locally adjustable block
size is a great feature (that ChucK lacks) because you can do it for
special needs cases (like variable delay patches, for example).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit
to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block
audio? Last time I tried ChucK (2012?) its efficiency was still
abysmal. [block~ 1] definitely takes a hit, but it's usually possible
to minimize how much of the DSP chain is actually blocked at 1. I
guess with Csound you can specify a k-rate equal to the sample rate
which is also effectively a single sample block. I haven't ever used
Csound in a real-time context, and most of what I do with it compiles
much more slowly than real time in any case.
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi
<peimankhosr...@gmail.com <mailto:peimankhosr...@gmail.com>> wrote:
You can do this with MSP's poly~ too but I'm guessing that the CPU
costs are quite heavy. Moreover, there are operators in gen that
are designed for low-level operations.
*www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> *
On 24 February 2016 at 16:15, cyrille henry <c...@chnry.net
<mailto:c...@chnry.net>> wrote:
Le 24/02/2016 16:50, peiman khosravi a écrit :
One great advantage of maxmsp is gen, which gives you
sample-level patching with the possibility of a one-sample
delay.
you can use [block~ 1 1 1] in a pd subpatch.
cheers
c
P
On Tuesday, February 23, 2016, Samuel Burt
<composer.samuel.b...@gmail.com
<mailto:composer.samuel.b...@gmail.com>
<mailto:composer.samuel.b...@gmail.com
<mailto:composer.samuel.b...@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 <dmed...@ucsd.edu
<mailto:dmed...@ucsd.edu>
<javascript:_e(%7B%7D,'cvml','dmed...@ucsd.edu
<mailto:dmed...@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).
--
*www.peimankhosravi.co.uk
<http://www.peimankhosravi.co.uk>
<http://www.peimankhosravi.co.uk>
<http://peimankhosravi.co.uk/miscposts.rss><http://spectralkimia.wordpress.com/>*
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing
list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
