Andy

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?

Doesn't work on Max 4.5, 4.6 and the new release.

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. 

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


i-need-urgent-help-my-max-patch-has-magically-lost-its-timing

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.

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.


Quote: Dayton wrote on Thu, 17 May 2007 10:43

----------------------------------------------------

> 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

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.
----------------------------------------------------

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

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


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 

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

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.
>
----------------------------------------------------


>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

>... Andreas, is there any way you can make a patch that demonstrates 

>this? Please? For the mental stability of us all?

(save as abstraction, works as metro - toggle in left, argument as 

>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?

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

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?

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..

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??
>

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

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

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

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

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

>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?

>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 

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 

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 

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 

(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 

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 

>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..

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

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

>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 

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

>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??

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?

> Quote: Wetterberg wrote on Fri, 18 May 2007 11:59

> ---------------------------------------------------- 

>> For me a simple [phasor~] -> [>~]->[edge~] is infinitely more tight than 

>> a [metro] - I even believe Stefan Tiedje has a [metro~] abstraction 

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

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 

(and on my system all of a sudden metro appears rock-solid, while 

phasor~-controlled bangs look totally ricketty. Oh well. ;) )

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.

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 

> (and on my system all of a sudden metro appears rock-solid, while 

> phasor~-controlled bangs look totally ricketty. Oh well. ;) )

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:

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?

> #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 flonum 249 193 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P number 128 22 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

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.

>
> #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;
>
>
----------------------------------------------------


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?

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

https://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.

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
----------------------------------------------------

> 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 

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.

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

> 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.

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.

> Yeah, here is some info. Although this doesn't explain enough about dsp.
>
> https://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. 

> 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 

>> (and on my system all of a sudden metro appears rock-solid, while 

>> phasor~-controlled bangs look totally ricketty. Oh well. ;) )

> 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 

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 ;-)

Quote: Wetterberg wrote on Fri, 18 May 2007 20:27

> > 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 

> >> (and on my system all of a sudden metro appears rock-solid, while 

> >> phasor~-controlled bangs look totally ricketty. Oh well. ;) )

> > 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~:

> you to Kaspers notion, that using scheduler-timed objects to time the 

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.

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. 

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

> But even when I activate this so that my event thread takes 100% cpu,

> both the metro -and- the edge~ construction become inaccurate,

> 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 

BUT!!! if I change the vector size above 1024, metro is completely 

I just verified with the list of changes for Max 4.6.3 and neither metro 

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...

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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. 

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 

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 

> I just verified with the list of changes for Max 4.6.3 and neither metro 

> 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%.

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). 

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

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