Just poll every microsecond, and increment the counter by one microsecond.
If there's something scheduled for that microsecond, do it.
:)
On Wednesday, February 24, 2016 4:19 PM, Matt Barber <[email protected]>
wrote:
OK, now I'm having trouble even imagining how an unblocked audio model could
possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine <[email protected]> wrote:
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 <[email protected]>
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
On 24 February 2016 at 16:15, cyrille henry <[email protected]> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
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://peimankhosravi.co.uk/miscposts.rss><http://spectralkimia.wordpress.com/>*
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
