I need urgent help – My Max patch has magically lost its timing!!!!

May 17, 2007 at 4:35pm

I need urgent help – My Max patch has magically lost its timing!!!!

Hi,

I have been working on a project for the past month or so – a rhythm action game. I last worked on it on tuesday night and it was working nicely. I have come to reopen the project today and the timing is all over the place. The timing is driven by a timer object, which at 120BPM seems to be now fluctuating anywhere between 2000ms and 2135 – over 1/16th note out at points.

I have tried opening the project in Max 4.5 and 4.6 and experienced the same problem. I have also tried uninstalling and reinstalling max and am now trying it on 4.6.3 and am getting nowhere. I have even tried my patch on somebody elses machine of equivelent processing/RAM/Max version and no luck

Removing my openGL programming seems to let it run properly with the timer giving me exactly 2000ms per note at 120BPM. My question is, if anyone has any idea why a Max patch may suddenly begin to act in such a way when the last time it was opened it ran perfectly fine.

The only thing I have done since last opening the patch is work on a different patch that has nothing in common with this one.

Has anyone experienced a similar problem and managed to resolve it?

Cheers

Andy

PowerMac G5 dual 2 GHZ
2mb RAM
OSX 10.4.9
Doesn’t work on Max 4.5, 4.6 and the new release.
Jitter 1.6

#31966
May 17, 2007 at 4:43pm

try the following:
In DSP Status, set the Max-Scheduler to audio interrupt and/or overdrive, change the audio-rate to another rate and change it back (sounds stupid, but this is a problem I have had.) Make sure that your audio driver is correct. When mine is set to the wrong driver, I get crazy results in Windows.

If nothing else works, use a phasor and rate instead of a timer.

#104429
May 17, 2007 at 5:01pm

Quote: Dayton wrote on Thu, 17 May 2007 10:43
—————————————————-
> try the following:
> In DSP Status, set the Max-Scheduler to audio interrupt and/or overdrive, change the audio-rate to another rate and change it back (sounds stupid, but this is a problem I have had.) Make sure that your audio driver is correct. When mine is set to the wrong driver, I get crazy results in Windows.
>
> If nothing else works, use a phasor and rate instead of a timer.
—————————————————-

Changing the sampling rate to 48K and back to 44.1 and setting to audio interrupt seems to have done the trick. Many Thanks for that.

Would it still be adviseable to use a phasor as the timing mechanism? Is this less costly?

I have to present my patch in a weeks time and this problem has kind of put the fear of god into me that it won’t work for it.

Many Thanks for the suggestions though. My stress levels have gone down significantly

#104430
May 17, 2007 at 8:25pm

#104431
May 18, 2007 at 9:59am

#104432
May 18, 2007 at 11:35am

Quote: Wetterberg wrote on Fri, 18 May 2007 11:59
—————————————————-
> I am sorry, that is not my experience at all!
> For me a simple [phasor~] -> [>~]->[edge~] is infinitely more tight than
> a [metro] – I even believe Stefan Tiedje has a [metro~] abstraction
> based on this very same concept.

… Andreas, is there any way you can make a patch that demonstrates this? Please? For the mental stability of us all?

Mattijs

>
> Andreas.
>
—————————————————-

#104433
May 18, 2007 at 12:33pm

>Quote: Wetterberg wrote on Fri, 18 May 2007 11:59
>—————————————————-
>> I am sorry, that is not my experience at all!
>> For me a simple [phasor~] -> [>~]->[edge~] is infinitely more tight than
>> a [metro] – I even believe Stefan Tiedje has a [metro~] abstraction
>> based on this very same concept.
>
>… Andreas, is there any way you can make a patch that demonstrates
>this? Please? For the mental stability of us all?

like this??

(save as abstraction, works as metro – toggle in left, argument as
metro speed (in milisec) default 1000

best

kasper
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 94 74 50 196617 deferlow;
#P flonum 116 183 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 94 141 34 196617 1000;
#P newex 94 120 32 196617 sel 0;
#P newex 94 44 48 196617 loadbang;
#P number 151 71 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 116 162 46 196617 / 1000.;
#P message 94 99 21 196617 $1;
#P inlet 151 50 15 0;
#P newex 61 263 65 196617 gate;
#P newex 116 223 39 196617 >~ 0.9;
#P newex 116 243 36 196617 edge~;
#P newex 116 203 55 196617 phasor~ 1;
#P inlet 61 50 15 0;
#P outlet 61 285 15 0;
#P connect 6 0 9 0;
#P connect 3 0 5 1;
#P connect 4 0 3 0;
#P connect 2 0 4 0;
#P connect 13 0 2 0;
#P connect 8 0 13 0;
#P fasten 12 0 8 0 99 159 121 159;
#P connect 11 1 8 0;
#P fasten 9 0 8 0 156 159 121 159;
#P connect 11 0 12 0;
#P connect 7 0 11 0;
#P connect 14 0 7 0;
#P connect 10 0 14 0;
#P connect 5 0 0 0;
#P connect 1 0 5 0;
#P window clipboard copycount 15;

#104434
May 18, 2007 at 1:08pm

Quote: Kasper T Toeplitz wrote on Fri, 18 May 2007 14:33
—————————————————-
> >… Andreas, is there any way you can make a patch that demonstrates
> >this? Please? For the mental stability of us all?
>
> like this??
>

No, sorry, I guess I wasn’t very clear. I mean a patch that clearly demonstrates that generating bangs with phasor~ and edge~ is more accurate than metro..

Mattijs

#104435
May 18, 2007 at 1:34pm

I think I missed some of this. Why not use metro~

On 5/18/07 8:33 AM, “Kasper T Toeplitz” wrote:

> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 94 74 50 196617 deferlow;
> #P flonum 116 183 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 94 141 34 196617 1000;
> #P newex 94 120 32 196617 sel 0;
> #P newex 94 44 48 196617 loadbang;
> #P number 151 71 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 116 162 46 196617 / 1000.;
> #P message 94 99 21 196617 $1;
> #P inlet 151 50 15 0;
> #P newex 61 263 65 196617 gate;
> #P newex 116 223 39 196617 >~ 0.9;
> #P newex 116 243 36 196617 edge~;
> #P newex 116 203 55 196617 phasor~ 1;
> #P inlet 61 50 15 0;
> #P outlet 61 285 15 0;
> #P connect 6 0 9 0;
> #P connect 3 0 5 1;
> #P connect 4 0 3 0;
> #P connect 2 0 4 0;
> #P connect 13 0 2 0;
> #P connect 8 0 13 0;
> #P fasten 12 0 8 0 99 159 121 159;
> #P connect 11 1 8 0;
> #P fasten 9 0 8 0 156 159 121 159;
> #P connect 11 0 12 0;
> #P connect 7 0 11 0;
> #P connect 14 0 7 0;
> #P connect 10 0 14 0;
> #P connect 5 0 0 0;
> #P connect 1 0 5 0;
> #P window clipboard copycount 15;

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

#104436
May 18, 2007 at 1:42pm

>Quote: Kasper T Toeplitz wrote on Fri, 18 May 2007 14:33
>—————————————————-
>> >… Andreas, is there any way you can make a patch that demonstrates
>> >this? Please? For the mental stability of us all?
>>
>> like this??
>>
>
>No, sorry, I guess I wasn’t very clear. I mean a patch that clearly
>demonstrates that generating bangs with phasor~ and edge~ is more
>accurate than metro..

sorry

i had thi ssame discussion here (on this list) not long ago, i might
find the name of the thread. But when the signal driven bangs were
not 100% accurate most persons pointed to me than it was because of
the innacurrency of the mesurement objects themselves, those which
are not in audio domain. Stll audio driven metro is much more
acuurate:

In most of my patches I build a chronometer – to “see” the elapsed
time. For a long time it was metro-driven and i sometimes had a
difference (with the “real” time) up to 20 minutes in one hour – that
is NOT accurate.

replacing this metro by the patch i just send, made my hour happen in
one hour. It was the only change in the patch, running on the same
computer (I won’t argue if my patch was well written or not – i
belive it was not that bad – the fact is that this was the only
change and that the music played was the same, following the same
score). yes, same sound card, same vector size etc. Just this one
change.

(other solution I used over the years was to sync to computer’s clock
time – thanks to P Castine for the small sub-patch. But now that i
use my metro~ (audio) it all works fine. I actually use metro’s for
“somewhat” random bangs – works well)

of course if you have a patch with just one metro it should work
fine.. but try adding some lp.epoisse~ instances (fro example) and
trouble will soon happen

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#104437
May 18, 2007 at 1:45pm

>I think I missed some of this. Why not use metro~

just because when i needed it i did not knew about metro~ – only when
I wanted to save this abstraction as metro~ did i discover than metro
already exists !!!

but finding the solution by oneself is a good thing, isn’t it??

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#104438
May 18, 2007 at 1:47pm

#104439
May 18, 2007 at 1:51pm

Does anybody know where I can read up on the background of the tuff that you guys are talking about as it sounds very interesting and I imagine would lead to many weeks improving the performance of my patches.

When it comes to threading, high priorites, queues etc I have not a clue. I don’t recall seeing anything in any documentation about it. I’m guessing that its a lower level topic?

Cheers

Andy

#104440
May 18, 2007 at 1:52pm

Mattijs Kneppers skrev:
> Quote: Wetterberg wrote on Fri, 18 May 2007 11:59
> —————————————————-
>
>> I am sorry, that is not my experience at all!
>> For me a simple [phasor~] -> [>~]->[edge~] is infinitely more tight than
>> a [metro] – I even believe Stefan Tiedje has a [metro~] abstraction
>> based on this very same concept.
>>
>
> … Andreas, is there any way you can make a patch that demonstrates this? Please? For the mental stability of us all?
>
> Mattijs
>
Something like this would do, but it doesn’t really reflect the problems
that occur with metro when using it in larger patches… well, you get
the idea.

(and on my system all of a sudden metro appears rock-solid, while
phasor~-controlled bangs look totally ricketty. Oh well. ;) )
Andreas.

#P window setfont “Sans Serif” 9.;
#P flonum 151 176 65 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 91 107 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 249 141 28 9109513 clear;
#P flonum 249 193 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 249 165 31 9109513 mean;
#P newex 151 53 40 9109513 !/ 1000.;
#P newex 151 145 29 9109513 timer;
#P newex 151 120 33 9109513 edge~;
#P newex 151 98 39 9109513 >=~ 0.9;
#P newex 151 76 41 9109513 phasor~;
#P newex 91 79 29 9109513 timer;
#P user ezdac~ 28 60 72 93 0;
#P number 128 22 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 91 25 15 0;
#P newex 91 52 32 9109513 metro;
#P connect 8 0 14 0;
#P connect 8 0 10 0;
#P connect 4 0 13 0;
#P connect 12 0 10 0;
#P connect 10 0 11 0;
#P connect 5 0 6 0;
#P connect 1 0 3 0;
#P connect 1 0 0 0;
#P connect 0 0 4 0;
#P connect 0 0 4 1;
#P connect 2 0 0 1;
#P connect 2 0 9 0;
#P connect 9 0 5 0;
#P connect 6 0 7 0;
#P connect 7 0 8 0;
#P connect 7 0 8 1;
#P window clipboard copycount 15;

#104441
May 18, 2007 at 2:04pm

Quote: Wetterberg wrote on Fri, 18 May 2007 15:52
—————————————————-

> Something like this would do, but it doesn’t really reflect the problems
> that occur with metro when using it in larger patches… well, you get
> the idea.
>
> (and on my system all of a sudden metro appears rock-solid, while
> phasor~-controlled bangs look totally ricketty. Oh well. ;) )
> Andreas.

I get the idea, but I think your patch proves just the opposite of your claim that phasor~ + edge~ works better than metro..

If the issue occurs only with larger patches; simulating a large patch could be done like this:

#P flonum 376 112 87 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 430 26 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 376 25 15 0;
#N counter;
#X flags 0 0;
#P newobj 376 90 66 196617 counter;
#P newex 376 44 52 196617 metro 40;
#P newex 376 68 62 196617 uzi 100000;
#P connect 2 0 5 0;
#P connect 1 0 0 0;
#P connect 0 0 2 0;
#P connect 4 0 1 1;
#P connect 3 0 1 0;

But even when I activate this so that my event thread takes 100% cpu, both the metro -and- the edge~ construction become inaccurate, exactly as expected.

Let’s try to sort this out once and for all, ok?

Mattijs

>
> #P window setfont “Sans Serif” 9.;
> #P flonum 151 176 65 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 91 107 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P message 249 141 28 9109513 clear;
> #P flonum 249 193 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 249 165 31 9109513 mean;
> #P newex 151 53 40 9109513 !/ 1000.;
> #P newex 151 145 29 9109513 timer;
> #P newex 151 120 33 9109513 edge~;
> #P newex 151 98 39 9109513 >=~ 0.9;
> #P newex 151 76 41 9109513 phasor~;
> #P newex 91 79 29 9109513 timer;
> #P user ezdac~ 28 60 72 93 0;
> #P number 128 22 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 91 25 15 0;
> #P newex 91 52 32 9109513 metro;
> #P connect 8 0 14 0;
> #P connect 8 0 10 0;
> #P connect 4 0 13 0;
> #P connect 12 0 10 0;
> #P connect 10 0 11 0;
> #P connect 5 0 6 0;
> #P connect 1 0 3 0;
> #P connect 1 0 0 0;
> #P connect 0 0 4 0;
> #P connect 0 0 4 1;
> #P connect 2 0 0 1;
> #P connect 2 0 9 0;
> #P connect 9 0 5 0;
> #P connect 6 0 7 0;
> #P connect 7 0 8 0;
> #P connect 7 0 8 1;
> #P window clipboard copycount 15;
>
>
—————————————————-

#104442
May 18, 2007 at 2:12pm

Quote: Andy wrote on Fri, 18 May 2007 15:51
—————————————————-
> Does anybody know where I can read up on the background of the tuff that you guys are talking about as it sounds very interesting and I imagine would lead to many weeks improving the performance of my patches.
>
> When it comes to threading, high priorites, queues etc I have not a clue. I don’t recall seeing anything in any documentation about it. I’m guessing that its a lower level topic?
>
> Cheers
>
> Andy
—————————————————-

Yeah, here is some info. Although this doesn’t explain enough about dsp.

http://www.cycling74.com/story/2005/5/2/133649/9742

Judging from the ongoing discussions about metro and metro~, I dare say that we’re clearly lacking a similar article about dsp. Even better would be a set of examples that don’t require a programmers background at the level of a bachelor or masters degree in software engineering.

Mattijs

#104443
May 18, 2007 at 2:15pm

Kasper T Toeplitz skrev:
> But when the signal driven bangs were not 100% accurate most persons
> pointed to me than it was because of the innacurrency of the
> mesurement objects themselves, those which are not in audio domain.
> Stll audio driven metro is much more acuurate:
>
> In most of my patches I build a chronometer – to “see” the elapsed
> time. For a long time it was metro-driven and i sometimes had a
> difference (with the “real” time) up to 20 minutes in one hour – that
> is NOT accurate.
Some very good points, Kasper.

Andreas.

#104444
May 18, 2007 at 2:28pm

> Yeah, here is some info. Although this doesn’t explain enough about dsp.
>
> http://www.cycling74.com/story/2005/5/2/133649/9742
>
> Judging from the ongoing discussions about metro and metro~, I dare say that we’re clearly lacking a similar article about dsp. Even better would be a set of examples that don’t require a programmers background at the level of a bachelor or masters degree in software engineering.
>
> Mattijs
>

Thanks for that. This is a topic that I have been meaning to look into for some time but it has only been recently – with a some what larger patch than I have previously created – that it has become an issue for me.

Cheers

Andy

#104445
May 18, 2007 at 6:27pm

Mattijs Kneppers skrev:
> Quote: Wetterberg wrote on Fri, 18 May 2007 15:52
> —————————————————-
>
>
>> Something like this would do, but it doesn’t really reflect the problems
>> that occur with metro when using it in larger patches… well, you get
>> the idea.
>>
>> (and on my system all of a sudden metro appears rock-solid, while
>> phasor~-controlled bangs look totally ricketty. Oh well. ;) )
>> Andreas.
>>
>
> I get the idea, but I think your patch proves just the opposite of your claim that phasor~ + edge~ works better than metro..
And that’s what I also say in the parenthesis. But I would also refer
you to Kaspers notion, that using scheduler-timed objects to time the
process is bad science ;-)

Andreas.

#104446
May 18, 2007 at 11:40pm

Quote: Wetterberg wrote on Fri, 18 May 2007 20:27
—————————————————-
> Mattijs Kneppers skrev:
> > Quote: Wetterberg wrote on Fri, 18 May 2007 15:52
> > —————————————————-
> >
> >
> >> Something like this would do, but it doesn’t really reflect the problems
> >> that occur with metro when using it in larger patches… well, you get
> >> the idea.
> >>
> >> (and on my system all of a sudden metro appears rock-solid, while
> >> phasor~-controlled bangs look totally ricketty. Oh well. ;) )
> >> Andreas.
> >>
> >
> > I get the idea, but I think your patch proves just the opposite of your claim that phasor~ + edge~ works better than metro..
> And that’s what I also say in the parenthesis.

Ok, so does that mean we agree that there is no difference in interval accuracy of metro and phaser~ + edge~?

If so, let’s move on to a different issue, the -accumulative- accuracy of metro and phasor~ + edge~:

> But I would also refer
> you to Kaspers notion, that using scheduler-timed objects to time the
> process is bad science ;-)

Could you or Kasper provide a patch that demonstrates this in the way that suits you best? Because I think you’re right about this and I believe that I can justify this behaviour and explain more about dsp vs events in general.

Mattijs

>
> Andreas.
>
—————————————————-

#104447
May 20, 2007 at 11:40am

Andreas Wetterberg schrieb:
> Something like this would do, but it doesn’t really reflect the problems
> that occur with metro when using it in larger patches… well, you get
> the idea.
>
> (and on my system all of a sudden metro appears rock-solid, while
> phasor~-controlled bangs look totally ricketty. Oh well. ;) )
> Andreas.

Mattijs Kneppers schrieb:
> But even when I activate this so that my event thread takes 100% cpu,
> both the metro -and- the edge~ construction become inaccurate,
> exactly as expected.
>
> Let’s try to sort this out once and for all, ok?

This ins interesting, I’d like to hear a comment from cycling…
metro seems to have changed. Even when I add Mattijs heavy load, the
compare patch of Andreas would not get out of precisision. (At least the
display of timer which stays accurate if I set it for example to 204 ms.
I didn’t check by ear). Even, and that’s different as before, if I set
all scheduler settings to off…

BUT!!! if I change the vector size above 1024, metro is completely
wrong. This seems to be a bug.

I just verified with the list of changes for Max 4.6.3 and neither metro
nor timer is listed.

Which version are you using Mattijs? Mine is 4.6.3 on a PPC Powerbook
and OS 10.4.9 with the internal sound card…

Stefan

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 173 24 30 196617 204;
#P user umenu 171 256 49 196645 1 64 272 0;
#X add Off;
#X add On;
#P newex 269 256 94 196617 adstatus overdrive;
#P user umenu 171 275 49 196645 1 64 291 0;
#X add Off;
#X add On;
#P newex 269 275 89 196617 adstatus takeover;
#P user umenu 39 156 36 196647 1 64 172 0;
#X add 0ff;
#X add heavy 1;
#X add heavy 2;
#P user umenu 171 316 72 196647 1 64 332 0;
#X add 1;
#X add 2;
#X add 4;
#X add 8;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#X add 256;
#X add 512;
#X add 1024;
#X add 2048;
#X add 4096;
#P newex 269 316 73 196617 adstatus sigvs;
#P user umenu 171 297 72 196647 1 64 313 0;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#X add 256;
#X add 512;
#X add 1024;
#X add 2048;
#X add 4096;
#P newex 269 297 68 196617 adstatus iovs;
#P newex 39 197 50 196617 switch;
#P flonum 39 267 87 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter;
#X flags 0 0;
#P newobj 39 245 66 196617 counter;
#P newex 39 223 62 196617 uzi 100000;
#P flonum 151 176 65 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 91 107 52 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 218 124 28 196617 clear;
#P flonum 218 176 67 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 218 148 31 196617 mean;
#P newex 151 53 54 196617 !/ 1000.;
#P newex 151 145 43 196617 timer;
#P newex 151 120 33 196617 edge~;
#P newex 151 98 53 196617 < ~ 0.5;
#P newex 151 76 41 196617 phasor~;
#P newex 91 79 47 196617 timer;
#P user ezdac~ 28 60 72 93 0;
#P number 128 24 40 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 91 25 15 0;
#P newex 91 52 47 196617 metro;
#P connect 8 0 14 0;
#P connect 8 0 10 0;
#P connect 28 0 0 1;
#P connect 28 0 9 0;
#P connect 2 0 0 1;
#P connect 2 0 9 0;
#P connect 1 0 3 0;
#P connect 1 0 0 0;
#P connect 0 0 18 1;
#P connect 0 0 4 0;
#P connect 0 0 4 1;
#P hidden fasten 26 0 27 0 274 276 248 276 218 254 176 254;
#P hidden fasten 24 0 25 0 274 295 269 295 239 273 176 273;
#P hidden fasten 27 0 26 0 176 274 222 274 248 253 274 253;
#P hidden fasten 25 0 24 0 176 293 243 293 269 272 274 272;
#P connect 23 0 18 0;
#P hidden fasten 19 0 20 0 274 318 270 318 240 296 176 296;
#P hidden fasten 21 0 22 0 274 337 272 337 242 315 176 315;
#P hidden fasten 20 0 19 0 176 316 243 316 269 295 274 295;
#P hidden fasten 22 0 21 0 176 335 246 335 272 314 274 314;
#P connect 7 0 18 2;
#P connect 7 0 8 0;
#P connect 7 0 8 1;
#P connect 18 0 15 0;
#P connect 15 0 16 0;
#P connect 16 0 17 0;
#P connect 5 0 6 0;
#P connect 6 0 7 0;
#P connect 9 0 5 0;
#P connect 10 0 11 0;
#P connect 12 0 10 0;
#P connect 4 0 13 0;
#P window clipboard copycount 29;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#104448
May 20, 2007 at 7:55pm

Quote: Stefan Tiedje wrote on Sun, 20 May 2007 13:40
—————————————————-

> This ins interesting, I’d like to hear a comment from cycling…
> metro seems to have changed. Even when I add Mattijs heavy load, the
> compare patch of Andreas would not get out of precisision. (At least the
> display of timer which stays accurate if I set it for example to 204 ms.
> I didn’t check by ear).

With overdrive on, I can imagine timer bases its output on the supposed execution time of each event so will always display the correct interval even if there is some deviation. Am I correct?

> Even, and that’s different as before, if I set
> all scheduler settings to off…

This sounds like overdrive is on. If timer says 204 ms when overdrive is off and the heavyload part is on, I’d say something strange is going on.

>
> BUT!!! if I change the vector size above 1024, metro is completely
> wrong. This seems to be a bug.
>
> I just verified with the list of changes for Max 4.6.3 and neither metro
> nor timer is listed.
>
> Which version are you using Mattijs? Mine is 4.6.3 on a PPC Powerbook
> and OS 10.4.9 with the internal sound card…

On ppc powerbook, os 10.4.9, internal soundcard, max 4.6.2. Here, in overdrive timer displays 204 ms for both metro and phasor~ + edge~, when overdrive is off, both metro and phasor~ + edge~ deviate a lot when cpu is at 100%.

Mattijs

#104449
May 20, 2007 at 8:19pm

Mattijs Kneppers skrev:
> Quote: Stefan Tiedje wrote on Sun, 20 May 2007 13:40
> —————————————————-
>
>
>> This ins interesting, I’d like to hear a comment from cycling…
>> metro seems to have changed. Even when I add Mattijs heavy load, the
>> compare patch of Andreas would not get out of precisision. (At least the
>> display of timer which stays accurate if I set it for example to 204 ms.
>> I didn’t check by ear).
>>
>
> With overdrive on, I can imagine timer bases its output on the supposed execution time of each event so will always display the correct interval even if there is some deviation. Am I correct?
>
That is what I suspect too:

> But I would also refer you to Kaspers notion, that using
> scheduler-timed objects to time the process is bad science ;-)
Andreas.

#104450

You must be logged in to reply to this topic.