On Mon, 17 Dec 2007, Derek Holzer wrote:
I teach my students that the reason you can't send audio to message
(i.e. non-audio) objects is that message objects run slower.
The only ways that they run slower, is that: messages are only applied to
audio between block boundaries; and doing audio
On Mon, 17 Dec 2007, Derek Holzer wrote:
Still, it is an inherent part of PD that you keep messages and audio
separate. Thus the different graphical look of the patch cables, and the
fact that it will not let you connect an audio cable to a non-audio
object. There must be some reason for
On Mon, 17 Dec 2007, IOhannes m zmoelnig wrote:
so all in all, messages are way more powerful than signals.
Especially as one could reimplement signals using messages as their
base. Oops, this is already how signals are implemented! They have this
method for the dsp selector. Granted that
Hallo,
Yvan Vander Sanden hat gesagt: // Yvan Vander Sanden wrote:
Thanks for all the answers. The first ones were a lot of help, and
although it seemed to me that you were all talking in tongues after
that, it sure sounds interesting.
I checked out the tcpclient code by martin peach. The
Hallo,
Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message
rate is constrained by the block size, so you would want to put [metro
1] inside of a subpatch with [block~ 1] for best time resolution.
That's not true. Message
On Dec 17, 2007 3:03 AM, Frank Barknecht [EMAIL PROTECTED] wrote:
Hallo,
Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message
rate is constrained by the block size, so you would want to put [metro
1] inside of a subpatch
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht [EMAIL PROTECTED] wrote:
Hallo,
Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message
rate is constrained by the block size, so you would want to put
Hallo,
Charles Henry hat gesagt: // Charles Henry wrote:
Try it yourself with a phasor~-clone build from metro and vline~!
I see now. That works well up to 1000 Hz.
That's because [metro] is capped for periods smaller than 1 msec. If
you drive the vline~ phasor clone with a self-made metro
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht [EMAIL PROTECTED] wrote:
Hallo,
Charles Henry hat gesagt: // Charles Henry wrote:
[metro 1] creates a bang each millisecond, approximately. The message
rate is constrained by the block size, so you
Thanks, Zen-Master Claudius. Your quantum revelations still leave me
wondering, however, what is the minimum time between two events which
can be scheduled?
I teach my students that the reason you can't send audio to message
(i.e. non-audio) objects is that message objects run slower. While
Derek Holzer wrote:
Thanks, Zen-Master Claudius. Your quantum revelations still leave me
wondering, however, what is the minimum time between two events which
can be scheduled?
[delay 0] works.
I teach my students that the reason you can't send audio to message
(i.e. non-audio) objects
On a closely related topic; Since Pd uses logical time why isn't there
a render mode Csound style, for those occasions where you don't actually
want to run in real time? Is it because blocking on unfinished output would
leave no way for an object to notify that it had finished the computation?
Of course there's render mode
downsample in pd patch- - render to file via sfwrite~ or othe object
-- upsample file with sndfile-convert or sound editor tool
should do the trick. Yes? At least to keep CPU limits from bottlenecking
your render.
d.
Andy Farnell wrote:
On a closely
Hi Claude,
OK, thanks for going into it a bit more. Makes sense to me, of course,
but I'll have to chew on it a while and think of a way to communicate it
without twisting up people's heads too much at too early a part of the
workshops ;-)
Still, it is an inherent part of PD that you keep
Derek Holzer wrote:
Of course there's render mode
downsample in pd patch- - render to file via sfwrite~ or othe object
-- upsample file with sndfile-convert or sound editor tool
should do the trick. Yes? At least to keep CPU limits from bottlenecking
your render.
d.
The problem
particular event will be within about 5 ms of the correct time.
Martin
Derek Holzer wrote:
To: Claude Heiland-Allen [EMAIL PROTECTED]
CC: pd-list@iem.at
Subject: Re: [PD] timing question
Date: Mon, 17 Dec 2007 15:55:28 +0100
Thanks, Zen-Master Claudius. Your quantum revelations still leave me
This is all fine and dandy.
But what about when they ask why they can't connect [osc~ 440] to [+ 1],
for example. Why won't PD let the connection get made? I.e., why can't
audio go to message objects?
d.
Frank Barknecht wrote:
Hallo,
Derek Holzer hat gesagt: // Derek Holzer wrote:
OK,
Sorry, I read this now and it sounds idiotic! Of course, I know why (one
is programmed for DSP and one is not). But again, I thought the
difference was that message objects were calculated slower, ie. at block
boundaries, which in fact is the restriction of DSP objects! So now that
I've been
Derek Holzer wrote:
So now that
I've been told that actually DSP objects are slower, it shakes up my
world view a bit, so I'm looking for new metaphors to get it back
together ;-)
all the slower vs faster is non-sense.
signals are handled in a _synchronous_ way (they have to process
Here's a patch that outputs the actual time of the bangs from a metro,
and also shows the phasor~ clone generated using vline~. You can see
that the actual time that the metro outputs is +/- 5ms (on my system),
but the phasor has a constant period anyways! Craziness.
So if I wanted to use PD to
I don't know if you fell into the same trap as me Derek (because it confused
the heck out of me for ages), but if you've come from Csound, which is a true
multi-rate system it's easy to see messages the wrong way. On one hand
theres a useful analogy between Csound k-rate signals and the Pd
On Mon, 17 Dec 2007, Frank Barknecht wrote:
Though, even in Pd, GUI messages are treated special: If you click on
a [bang( message, this will only be evaluated every 64 samples. But
you probably cannot click the mouse repeatedly with a constant 1 msec
period anyways, so it shouldn't matter.
Hallo,
Derek Holzer hat gesagt: // Derek Holzer wrote:
Sorry, I read this now and it sounds idiotic! Of course, I know why (one
is programmed for DSP and one is not). But again, I thought the
difference was that message objects were calculated slower, ie. at block
boundaries, which in fact
Uh oh! There goes my Christmas weekend!
d.
Frank Barknecht wrote:
Hallo,
Derek Holzer hat gesagt: // Derek Holzer wrote:
Sorry, I read this now and it sounds idiotic! Of course, I know why (one
is programmed for DSP and one is not). But again, I thought the
difference was that message
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 17 Dec 2007, Frank Barknecht wrote:
The second thing, people need to learn then is, that most signal objects
can only be scheduled on block boundaries. So if you send a new
frequency to an [osc~] as a float message, the
On Dec 17, 2007 9:20 AM, Claude Heiland-Allen [EMAIL PROTECTED]
wrote:
BTW, I like how I can turn on [pix_write] and [writesf~] and have
everything work in logical time (with very many dropouts) and the final
video be in perfect sync with the sound. Using [gemhead] for sequencing
the audio
Thanks for all the answers. The first ones were a lot of help, and
although it seemed to me that you were all talking in tongues after
that, it sure sounds interesting.
I checked out the tcpclient code by martin peach. The thread solution
could be useful, but i also spotted something else:
Yvan Vander Sanden wrote:
hi.
I am currently working on an external that generates rhythmic pulses in
a certain way. But I was wondering if I could run into problems with
calling usleep in an external. Alternatively, I suppose i could use a pd
timer as an input and let it give a bang each
On Dec 15, 2007 6:24 PM, Yvan Vander Sanden [EMAIL PROTECTED] wrote:
hi.
I am currently working on an external that generates rhythmic pulses in
a certain way. But I was wondering if I could run into problems with
calling usleep in an external. Alternatively, I suppose i could use a pd
timer
hi.
I am currently working on an external that generates rhythmic pulses in
a certain way. But I was wondering if I could run into problems with
calling usleep in an external. Alternatively, I suppose i could use a pd
timer as an input and let it give a bang each milli-second, but that
30 matches
Mail list logo
