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 fu
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 th
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
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: applicat
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
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 beginnin
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 nec
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,
t
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
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_ __goto10.
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
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
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
>
> 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 between sample
> blocks"? The
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
> > actuall
> 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. Object
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 jit
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
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 independen
>
> 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 i
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
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 alrea
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 ca
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 20
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 ex
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 roun
Hallo,
Roman Haefeli hat gesagt: // 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~].
> one issue might be introduced by the rounding error of floats. the other
> i can
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. ;
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.
ro
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 somethin
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 th
hello frank
i don't have a solution at hand, but a feature request (or maybe better:
wishlist) for miller. i noticed by accident, that also other objects
beside [vline~] and [vd~] started to work with more accuracy than one
block in recent versions of pd, e.g [tabwrite~].
this is good news, but i
32 matches
Mail list logo
