metro~ (in audio) still not right???
hi
as we all know the accurency problems of metro (and other max
time-related objects) I decided to build a chronometer in audio (as
the one i am using, based on a metro 1000 and counter, reported
during yesterday's rehersal a duration of of 29 minutes when the
piece was 40 minutes long - which is 25% difference, not a minor
problem)
anyhow
so i decided to base the time calculation on a phasor~ 1 - which i
think should be similar to metro 1000, but more precise.
still, when i check with a timer, it does not give a steady pulse...
is that me??? - the patch below was the only one running - on a MAC
OSX47, max 457, a Powerbook G4 1.5Ghz... i mean that should not be
TOO MUCH for such a computer...
many thanks for any help (or explaination)
best
kasper
#P window setfont "Sans Serif" 9.;
#P number 334 286 108 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 334 253 35 196617 timer;
#P newex 334 86 39 196617 >~ 0.9;
#P button 334 163 63 0;
#P newex 334 110 36 196617 edge~;
#P user ezdac~ 468 220 512 253 0;
#P newex 334 63 55 196617 phasor~ 1;
#P connect 5 0 6 0;
#P connect 0 0 4 0;
#P connect 4 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 5 1;
#P connect 3 0 5 0;
#P window clipboard copycount 7;
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
i'm not an msp wizard, but my guess would be that the unsteadyness
you are seeing is due to the 'button' and the 'timer' objects you use
to check your timing..
As far as I understand these matters timing within msp is very solid,
the timing of the max-scheduler (i.e. the sending of max-messages) is
not, and here you are using objects which live in the max-scheduled
world to measure msp-timing.
I am sure I do not use the right vocabulary here, and it is well
possible I didn't understand it right anyways..
ciao,
Joost.
On 17 Sep 2006, at 15:24, Kasper T Toeplitz wrote:
> so i decided to base the time calculation on a phasor~ 1 - which i
> think should be similar to metro 1000, but more precise.
> still, when i check with a timer, it does not give a steady pulse...
>
> is that me??? - the patch below was the only one running - on a MAC
> OSX47, max 457, a Powerbook G4 1.5Ghz... i mean that should not
> be TOO MUCH for such a computer...
In any case i did understood you, and this is also something i thought about
but, if this is the case, using ONLY a button and a timer - on a
not-so-bad computer would create such a sloppiness???
using the same objects, but with a metro 1000 seems perfectly stable
(see patch), driving them with audio (phaser~ -> edge~) is not...
best
kasper
>i'm not an msp wizard, but my guess would be that the unsteadyness
>you are seeing is due to the 'button' and the 'timer' objects you
>use to check your timing..
>
>As far as I understand these matters timing within msp is very
>solid, the timing of the max-scheduler (i.e. the sending of
>max-messages) is not, and here you are using objects which live in
>the max-scheduled world to measure msp-timing.
>
>I am sure I do not use the right vocabulary here, and it is well
>possible I didn't understand it right anyways..
Dear Kasper
Have you tried
count~ -> snapshot~ -> / SR?
I am running it now and it is not so bad... I'll tell you in an hour ;-)
pa
Dear Kasper,
according to my experience timing accuracy between Max and MSP
depends very much on the Signal Vector Size. When using smaller
Vector Sizes, the coordination between Max and MSP gets much tighter.
(The reason why timing in only-Max seems to be more precise is
certainly that the mistakes apply in the same way to all Max objects,
i.e. the metro as well as the timer.)
Best,
Michael
in case my patch was not clear...
After 23 minutes, I have an offset of less than 4 seconds, I presume
it is due to the innacuracy of the 32 bits output of count~
I have done a new verison with JKC' hr objects, will keep you posted.
pa
Dear all.
After 76 minutes, my hr.count~ version is 5 seconds late
After 99 minutes, my count~ version is 9 seconds late
I have a question now for under-the-hood Max people.
If I play an hour long audio file, can I expect the same mistake? 5
seconds on 75 minutes = 0.00111111 = almost 2 cents
Not much indeed, but good to know where is it coming from: sync
chrystal error margin ?
Sorry to ask questions that might be so obvious for certain, but I
want to be very sure before telling students stupid things...
Cheers
pax
>Dear all.
>
>After 76 minutes, my hr.count~ version is 5 seconds late
>After 99 minutes, my count~ version is 9 seconds late
>
i am not as precise as you, but 3 run-through of a 40 minutes piece
when running both a "real" chronometer (you know, hardware with fresh
batteries in !!) and a chronometer made in max with phasor~ 1 ->
edge~ showed a difference of _maybe_ 1 second ( I mean I can not
guarantee I switched them both on/off at exactly the same time...)
will try to run it again, for a longer period (with a heavy patch -
using some lp.epoisse~ from the litter lib is something which is very
bad for timing; i know it from experience!!)
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
I came to the conclusion several years ago that truly accurate timing is not possible in Max. My first attempt to write a drum machine with Max as the clock, back in 1996 had me over-using the phrase "good enough for algorithmic music." But not for techno. The timing is better now, but I haven't been able to get a tight enough clock with Max, ever. The obvious solution is to use MSP instead, and that really works. I wrote a system of externals that do sub-sample accurate clocking and interoperate through signal connections. I'm presenting a paper on them in November at the New Orleans ICMC, and expect to distribute these externals shortly thereafter.
Eric
On Sep 17, 2006, at 10:29 AM, Pierre Alexandre Tremblay wrote:
> After 76 minutes, my hr.count~ version is 5 seconds late
> After 99 minutes, my count~ version is 9 seconds late
This is 32 bit FP resolution plain and simple. Your problem is that
even with hr.count~, you are trying to use a *single* float number to
represent your time if the image of your patch you posted is
indicative of what you're actually doing. This is *not* going to
work. The only way the output of hr.count~ is more resolute is if
*both* the signal values are used, but that's not going to work as
output to max. You need to modify this number to be less than 2
raised to the 23rd power for use within the single precision range
with integer resolution (sometimes much less depending on what you're
looking to do with the number afterwards). You can find more
information about single precision floating point numbers online, and
in the mailing list archives.
I would suggest using multiple floating point signals for your timing
and/or a periodic approach. e.g. use a count to count every sample in
a second, then accumulate seconds with +=~ (as demonstrated in the
+=~ help file or the patch at bottom). Or use something like modulo
arithmetic in the hr objects (hr.wrap~).
FWIW, I personally always use phasor~ to clock any timing information
I wish to be sample accurate. Keeping everything in the signal
domain. This is possible to do without developing any new objects.
Check out the audio-rate-sequencing-looping examples folder.
-Joshua
Damn, I hate when things are mathematically on par and predictable! What about the "end users" who, oh never mind. Sorry, I was pretending like it really mattered.
I have noticed all the same things mentioned above.
Kasper T Toeplitz wrote:
> hi
>
> in may case (yes, it is a slower machine - well, a G4) it's a different
> value at almost every tick - values seem to be between 996 and 1006...
timer is inaccurate, not phasor~, or train~.
It depends a lot on settings. with a 1001 every 16 ticks and 999 elswise
, I'd guess Juliens setting is "scheduler in audiointerupt" and
"overdrive on" as the accuratesse of the scheduler is not better than
around 2 ms (also depending a lot on settings. It seems quite good.
(timers output is even float). with the setings of Kasper you'd need to
average the result to find out more about the correctness of the timing.
Without scheduler in audiointerrupt, there has always been a pretty big
difference between 1000 ms of a metro and 44100 samples at 44.1 kHz...
which would result in "phasing off" between a scheduler timer and an
audiobased time. (for example the position output of sfplay~)
My St.opwatch uses system time by the way, and wouldn't phase of either
(or at least more in the range of years than in minutes)...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
I've followed this topic with great interest (like a lot of people, i
guess) and i wonder now that it seems stuck if there's any conclusions ?
Timing is, would i say, critical, of course, and we need to trust the
main engine we all rely on. So what is the answer for a stable &
accurate metronome ? And for a time counter ? I, personaly, often tear
my hair off when using a sequencer in Max (why is it always out of the
beat, for Puckette's sake ?!). I also have unbearable troubles with
timing issues while using multiple recorders-loopers-crossfaders,
periodicaly have to resync all tracks, which is not very pretty in
performance...
best
f.e
f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|
Stefan Tiedje wrote:
> Kasper T Toeplitz wrote:
>> hi
>>
>> in may case (yes, it is a slower machine - well, a G4) it's a
>> different value at almost every tick - values seem to be between 996
>> and 1006...
>
> timer is inaccurate, not phasor~, or train~.
> It depends a lot on settings. with a 1001 every 16 ticks and 999
> elswise , I'd guess Juliens setting is "scheduler in audiointerupt"
> and "overdrive on" as the accuratesse of the scheduler is not better
> than around 2 ms (also depending a lot on settings. It seems quite
> good. (timers output is even float). with the setings of Kasper you'd
> need to average the result to find out more about the correctness of
> the timing.
>
> Without scheduler in audiointerrupt, there has always been a pretty
> big difference between 1000 ms of a metro and 44100 samples at 44.1
> kHz...
> which would result in "phasing off" between a scheduler timer and an
> audiobased time. (for example the position output of sfplay~)
> My St.opwatch uses system time by the way, and wouldn't phase of
> either (or at least more in the range of years than in minutes)...
>
> Stefan
>
>I've followed this topic with great interest (like a lot of people,
>i guess) and i wonder now that it seems stuck if there's any
>conclusions ? Timing is, would i say, critical, of course, and we
>need to trust the main engine we all rely on. So what is the answer
>for a stable & accurate metronome ? And for a time counter ? I,
>personaly, often tear my hair off when using a sequencer in Max (why
>is it always out of the beat, for Puckette's sake ?!). I also have
>unbearable troubles with timing issues while using multiple
>recorders-loopers-crossfaders, periodicaly have to resync all
>tracks, which is not very pretty in performance...
>
from what i can say, since i build a time counter with phasor~, it
seems to report time OK (it was not the case before)
as for sequencer, i don't know (yet) - here you need a really precise timing
i am also wondering what happens if one loads a reaktor sequencer
into max (as plug-in) - will it keep the reaktor tighness or the max
sloppiness???
which of course is no answer for loopers/recorders
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
- I don't think this particular problem was discussed in this thread
but:
- I was playing around with the jit.freeframe help file last night --
installing some freeframe plugs and playing around with them
- I loaded a movie into the jit.qt.movie object (one of the files
from the ./patches/media folder)
- I started the metro~ object
- the movie played, I loaded different freeframe plugs and played
around with the params a little
- when I stopped the metro~ object (by either clicking off the toggle
switch OR sending an 'off' message) the movie 'image' stopped playing
but the audio from the movie continued playing
- known bug, new feature, something I'm missing...?
-- sorry if this has been discussed before but I wasn't able to track
down any posts pertaining to this in my maxmsp mailbox
thanks in advance
KIM
QuickTime special side effect. Nothing to be done about it, except to
"stop" the movie when you want it to stop.
jb
Am 01.10.2006 um 19:33 schrieb Kim Cascone:
> - when I stopped the metro~ object (by either clicking off the
> toggle switch OR sending an 'off' message) the movie 'image'
> stopped playing but the audio from the movie continued playing
> - known bug, new feature, something I'm missing...?
Kim Cascone wrote:
> - known bug, new feature, something I'm missing...?
Its supposed to be a feature, the only way to come around is to create
an abstraction for those opbjects (especially jit.qt.movie) to make them
behave intuitively for musicians. I just guess that vidoe people more
likely think in frames and ticks than in time for example. Or that
playing a movie is not necessarily seeing it...
All is there to make it behave like you think it should, and its a good
thing to create those abstractions and then really forget about the
original objects in the real patching world...
You gain flexibility in the end.
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com