Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This interval also is independent from the blocksize! You can
check this with attached patch
Now you can...
Ciao
--
Frank Barknecht _ __footils.org_ __goto10.org__
blocksize-messages.pd
Description:
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
does this all make sense?
smaller blocksizes give you the possibility to handle messages in even
shorter time intervals, bigger blocksizes may help to declick for
example when you write to arrays. [for some objects blocksize is
First of all thanks for all the elaborate explanations. They are all
greatly appreciated!
On 08/05/2007, at 20.06, Roman Haefeli wrote:
On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote:
I understand that decreasing the block size will possible requirer
more computation/logical time then
Hallo,
Steffen hat gesagt: // Steffen wrote:
And therefore that the information in a block is available
to the program to process. Which also means that after that block has
been processes the information is not longer available. Is that true?
i am afraid, i couldn't fully follow.
Frank Barknecht wrote:
Hallo,
Objects like [delay] or [metro] produce these clock-delayed messages.
They register their clocks with Pd's main scheduler using
clock_new(...) and then order the scheduler to generate the
clock-delayed messages like the metro-bangs using clock_delay(). The
On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote:
because they do not interface with the world outside.
I feel that i don't interface with the world inside. I would
greatly appreciate if someone would translate the scope of this
discussion into noobish.
I sense that it's not that hard to
Steffen wrote:
On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote:
because they do not interface with the world outside.
I feel that i don't interface with the world inside. I would
greatly appreciate if someone would translate the scope of this
discussion into noobish.
sorry if i
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
unfortunately i am not very good at explaining things in simple words;
anyone else wants togive it a try?
Pd is nirvana, comport is the harsh reality.
Ciao
--
Frank Barknecht _ __footils.org_
On Tue, 2007-05-08 at 13:12 +0200, Steffen wrote:
On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote:
because they do not interface with the world outside.
I feel that i don't interface with the world inside. I would
greatly appreciate if someone would translate the scope of this
Steffen wrote:
On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote:
because they do not interface with the world outside.
I feel that i don't interface with the world inside. I would
greatly appreciate if someone would translate the scope of this
discussion into noobish.
hi,
think of
On 08/05/2007, at 14.36, Roman Haefeli wrote:
i think, i understood, what IOhannes explained,
I'm sorry i wasn't cleat about what i didn't understand. By this
discussion i mean to refer not only to IOhannes mail but the whole
thread.
Confusion Is Sex, they say. So i guess it's not
what happens in a block cycle?
first all dsp computation is done, then all new messaging is handled:
usually 64 samples of digital (audio) signal are blocked together.
so lets say you have a line~ object that received a message [0, 1 10(
before the new block started. so that is executed
On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote:
Marius also ends out with some explanation of the 'block' concept. I
think that what i don't really get.
I understand that decreasing the block size will possible requirer
more computation/logical time then there is real time enough to
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe
others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~]
object!! It should do what the
On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote:
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
it would be very cool, if [snapshot~] and [threshold~] (and maybe
others) would provide sample accuracy as well (when triggered by [metro]
Now I discovered something: Pd
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not
working as expected, though it definitely gives other results than
[snapshot~].
one issue might be introduced by the rounding error of floats. the other
i cannot explain. vsnapshot~ seems to pick sometimes the wrong value.
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
wow, great news again how did you find out about this? it is not
mentioned in the release notes.
Use the source, Luke: I was considereing to code my own vsnapshot~ and
looked into d_ctl.c where I found, that Miller already did it. ;)
Roman Haefeli wrote:
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not
working as expected, though it definitely gives other results than
[snapshot~].
i think it is working as expected but there are 2 things to bear in mind:
one issue might be introduced by the
On Mon, 2007-05-07 at 12:58 +0200, IOhannes m zmoelnig wrote:
when you send a message to [vline~] it is scheduled to the next
dsp-block (sample accurateley); the last one is already done
when you send a message to [vsnapshot~] it operates on the last
dsp-block; the next one does not yet exist
two side questions:
1) since computers are much faster now than in 1998, would it be
possible to change the 64 sample block timing of messages to a block~ 1
and use block~ 64 only for talking to the soundcard?
2) Is it possible to get microsecond accuracy in metro?
the difference between metro
Roman Haefeli wrote:
what/where is that [vmetro] object from? it is not included in my
version of pd 0.40.2. anyway, if i am not mistaken, your patch works
also with [metro].
oh yes, i forgot.
[vmetro] is just a [metro] replacement based on [delay] so i can use
small cycles (1ms); you can
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
two side questions:
1) since computers are much faster now than in 1998, would it be
possible to change the 64 sample block timing of messages to a block~ 1
and use block~ 64 only for talking to the soundcard?
Messages already
On Mon, 2007-05-07 at 16:57 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
what/where is that [vmetro] object from? it is not included in my
version of pd 0.40.2. anyway, if i am not mistaken, your patch works
also with [metro].
oh yes, i forgot.
[vmetro] is just a [metro]
marius schebella wrote:
2) Is it possible to get microsecond accuracy in metro?
the difference between metro 200 and 200.5 would be one beat per minute.
for synchronizing a big difference.
marius.
[metro] is very accurate over time, it just has a jitter as the bangs have to
happen in
Hallo,
[EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote:
[metro] is very accurate over time, it just has a jitter as the
bangs have to happen in between sample blocks
What do you mean by this bangs have to happen in between sample
blocks? The bangs from metro AFAIK happen independent
On Mon, 2007-05-07 at 20:59 +0200, Frank Barknecht wrote:
Hallo,
[EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote:
[metro] is very accurate over time, it just has a jitter as the
bangs have to happen in between sample blocks
What do you mean by this bangs have to happen in
Hallo,
[EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote:
I think the bangs are independent but they don't get processed until any
pending samples have been dealt with.
That was the impression I got when testing [comport] by setting the DTR pin
using [metro]: there is always a jitter
Frank Barknecht wrote:
I think, it's comport's fault: [metro] generates clock-delayed
messages. These are like messages tagged with a time-stamp referring
to Pd's internal clock. However an object needs to actually use the
time-stamps and look at the clock to see what time it is. Objects
Hallo,
[EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote:
Frank Barknecht wrote:
I think, it's comport's fault: [metro] generates clock-delayed
messages. These are like messages tagged with a time-stamp
referring to Pd's internal clock. However an object needs to
actually use the
29 matches
Mail list logo
