MisterW

Hi, I have been busy at work trying to make a phasor~ sync up with midi real time clock info (24 ticks per beat). I've gotten a pretty decent patch that continually checks the value of the phasor and either speeds it up or slows it down based on where it should be. Ok. cool.

But, in the course of doing all of that, I have noticed that something is very wrong...what that something is? Hopefully someone out there can help me.

Basically, I have noticed that my MSP is not right. For example, I set a phasor~ to 2 Hz and have it play a sample. At the same time, I use a metro set at 500ms to trigger another sample. I start them at the same time so they are perfectlly sync'd. However, after only 20 beats or so, they are completely out of phase. Now, I cannot believe that the timing is so bad that it would do this in normal operations. The patch that I wrote is "holding" the phasor to a frequency of around 1.9Hz when it should be at 2hz, now that is definately wrong.

Furthermore, I've also noticed other things are wrong. Unfortunately, I can't find the patch that did this, but awhile back I noticed that when i did certain operations on signals, ie. attempt to multiply them, i was getting wrong answers.

Can anyone tell me why my computer might be doing this? Do i have some setting wrong? My i/o vector and signal vector sizes are 512, i've tried it in overdrive and with interrupt both on and off. I don't know what else it could be, any ideas? Please help, this is really frusterating! thanks and hope to hear from all of you

Hi, I have been busy at work trying to make a phasor~ sync up with midi real time clock info (24 ticks per beat).  I've gotten a pretty decent patch that continually checks the value of the phasor and either speeds it up or slows it down based on where it should be.  Ok.  cool.  

But, in the course of doing all of that, I have noticed that something is very wrong...what that something is?  Hopefully someone out there can help me.  

Basically, I have noticed that my MSP is not right.  For example,  I set a phasor~ to 2 Hz and have it play a sample.  At the same time, I use a metro set at 500ms to trigger another sample.  I start them at the same time so they are perfectlly sync'd.  However, after only 20 beats or so, they are completely out of phase.  Now, I cannot believe that the timing is so bad that it would do this in normal operations.  The patch that I wrote is "holding" the phasor to a frequency of around 1.9Hz when it should be at 2hz, now that is definately wrong.  

Furthermore, I've also noticed other things are wrong.  Unfortunately, I can't find the patch that did this, but awhile back I noticed that when i did certain operations on signals, ie. attempt to multiply them, i was getting wrong answers.  

Can anyone tell me why my computer might be doing this?  Do i have some setting wrong?  My i/o vector and signal vector sizes are 512, i've tried it in overdrive and with interrupt both on and off.  I don't know what else it could be, any ideas?  Please help, this is really frusterating!  thanks and hope to hear from all of you

issues-with-msp-timing

> Basically, I have noticed that my MSP is not right. For example, I

> set a phasor~ to 2 Hz and have it play a sample. At the same time, I

> use a metro set at 500ms to trigger another sample. I start them at

> the same time so they are perfectlly sync'd. However, after only 20

> beats or so, they are completely out of phase.

It's not MSP which is wrong, its Max! This has been around since ever. 

You might get better results if you switch on "Scheduler in Audio 

Interrupt" But in general in a "seperated scheduler worlds" approach, 

you have to sync as you would do in analog/digital hardware components.

It's a different way of thinking times, versus triggering of events.

This should be actually mentioned in 48 point size within the metro help 

file: DO NOT EXPECT TO HAVE EXACT TIMING IF YOU LET THIS RUN FREELY.

And if you do not let run it freely, you just don't need metro ;-)

Search the archives for different approaches to sync bangs to audio. 

Look into edge~ and >~ 0.5 to get bangs perfectly synced to your phasor~....

Matthew Wilkens wrote:
> Basically, I have noticed that my MSP is not right.  For example,  I
> set a phasor~ to 2 Hz and have it play a sample.  At the same time, I
> use a metro set at 500ms to trigger another sample.  I start them at
> the same time so they are perfectlly sync'd.  However, after only 20
> beats or so, they are completely out of phase.

It's not MSP which is wrong, its Max! This has been around since ever. 
You might get better results if you switch on "Scheduler in Audio 
Interrupt" But in general in a "seperated scheduler worlds" approach, 
you have to sync as you would do in analog/digital hardware components.
It's a different way of thinking times, versus triggering of events.

This should be actually mentioned in 48 point size within the metro help 
file: DO NOT EXPECT TO HAVE EXACT TIMING IF YOU LET THIS RUN FREELY.

Search the archives for different approaches to sync bangs to audio. 
Look into edge~ and >~ 0.5 to get bangs perfectly synced to your phasor~....

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


> Can anyone tell me why my computer might be doing this? Do i have some setting wrong? My i/o vector and signal vector sizes are 512, i've tried it in overdrive and with interrupt both on and off. I don't know what else it could be, any ideas? Please help, this is really frusterating! thanks and hope to hear from all of you

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

sorry Matt , catching up on this thread a little late , so i dont know if you figured everything out.

as Stephan mentionned doing evertything in MSP will b the safest way to go.

here are a few examples among stephan's solution, the question remains open on which one of these is the best . and has been widely discussed on previuous threads .

> Can anyone tell me why my computer might be doing this?  Do i have some setting wrong?  My i/o vector and signal vector sizes are 512, i've tried it in overdrive and with interrupt both on and off.  I don't know what else it could be, any ideas?  Please help, this is really frusterating!  thanks and hope to hear from all of you
>
> matt
----------------------------------------------------

sorry Matt , catching up on this thread a little late , so i dont know if you figured everything out.
as Stephan mentionned doing evertything in MSP will b the safest way to go.
here are a few examples among stephan's solution,  the question remains open on which one of these is the best . and has been widely discussed on previuous threads .
good luck

thanks for the feedback guys, unfortunately the reason I am trying to sync a phasor~ with bangs is because I want to sync it with an incoming midi time clock...which are basically bangs. Most people will immediately say why not use your computer as the master clock and sync your midi devices from that, well, the midi device I am using is Red Sounds SoundBite Micro, which takes an audio signal in and sends synchronized midi clock out. The whole point is so you can sync other devices up to an audio signal. The beat counting engine from red sound is really good.

Anyways, thanks for the feedback and I'll keep plugging away

thanks for the feedback guys, unfortunately the reason I am trying to sync a phasor~ with bangs is because I want to sync it with an incoming midi time clock...which are basically bangs.  Most people will immediately say why not use your computer as the master clock and sync your midi devices from that, well, the midi device I am using is Red Sounds SoundBite Micro, which takes an audio signal in and sends synchronized midi clock out.  The whole point is so you can sync other devices up to an audio signal.  The beat counting engine from red sound is really good.  

Anyways, thanks for the feedback and I'll keep plugging away


And it's interesting to compare phasor with train ...

i just use audio for all timing. sample tight sounds better to me. 

or you could use reaktor, which calculates the non audio path at signal rate so i hear...

other than that, rewire gives me best inter app communication

i just use audio for all timing. sample tight sounds better to me. 
or you could use reaktor, which calculates the non audio path at signal rate so i hear...
other than that, rewire gives me best inter app communication


Quote: david stevens wrote on Sat, 07 October 2006 03:39

> And it's interesting to compare phasor with train ...

Quote: david stevens wrote on Sat, 07 October 2006 03:39
----------------------------------------------------
> And it's interesting to compare phasor with train ...
>
> David
>

I posted 2 topics about problems with metro and tempo. I have seen at least 4 others in the past couple months. Why is such an essential object/series of objects flawed? I don't know of any other software including poor quality ones that go out of sync like this...

They should just completely recode it or rework the event scheduler somehow.

I posted 2 topics about problems with metro and tempo.  I have seen at least 4 others in the past couple months.  Why is such an essential object/series of objects flawed?  I don't know of any other software including poor quality ones that go out of sync like this...

They should just completely recode it or rework the event scheduler somehow.


maybe you should think less of MaxMSP in terms of being a piece of 

software than a programming language? If tempo/metro were to stay synced 

to audio it would have to be implemented in a similar way to control 

rate in Csound. That might put severe limitations on how much you could 

expect to do following one bang without getting audio stutter due to 

severe CPU spikes. Some of us might be quite dependent on the ability to 

have the metro running in a different scheduler to audio.

Several examples have been posted illustrating how to run an audio rate 

metro. If you want to use tempo/metro synced to audio, you are free to 

do so. If you spend a day making wrappers (abstraction) for setclock, 

metro, tempo, line, etc. you could easily set up setclock to be driven 

by audio, and then link all of your timed objects to that clock. Max 

provides you with a much higher degree of freedom than most audio/media 

software, but sometimes that comes at the expense of having to do a 

little extra work to tweak things to behave according to *your* needs 

> I posted 2 topics about problems with metro and tempo. I have seen at least 4 others in the past couple months. Why is such an essential object/series of objects flawed? I don't know of any other software including poor quality ones that go out of sync like this...

> They should just completely recode it or rework the event scheduler somehow.

maybe you should think less of MaxMSP in terms of being a piece of 
software than a programming language? If tempo/metro were to stay synced 
to audio it would have to be implemented in a similar way to control 
rate in Csound. That might put severe limitations on how much you could 
expect to do following one bang without getting audio stutter due to 
severe CPU spikes. Some of us might be quite dependent on the ability to 
have the metro running in a different scheduler to audio.

Several examples have been posted illustrating how to run an audio rate 
metro. If you want to use tempo/metro synced to audio, you are free to 
do so. If you spend a day making wrappers (abstraction) for setclock, 
metro, tempo, line, etc. you could easily set up setclock to be driven 
by audio, and then link all of your timed objects to that clock. Max 
provides you with a much higher degree of freedom than most audio/media 
software, but sometimes that comes at the expense of having to do a 
little extra work to tweak things to behave according to *your* needs 
and preferences.

Nicholas C. Raftis III wrote:
> I posted 2 topics about problems with metro and tempo.  I have seen at least 4 others in the past couple months.  Why is such an essential object/series of objects flawed?  I don't know of any other software including poor quality ones that go out of sync like this...
>
> They should just completely recode it or rework the event scheduler somehow.
>


Is 'Scheduler in Audio Interrupt' analogous to Reaktor or the Nord Modulars' 'audio-rate' control rates? If so, would it be useful to allow one of several divisions of that rate to conserve cycles, if desired?

Is 'Scheduler in Audio Interrupt' analogous to Reaktor or the Nord Modulars' 'audio-rate' control rates?  If so, would it be useful to allow one of several divisions of that rate to conserve cycles, if desired?


> unfortunately the reason I am trying to sync a phasor~ with bangs is

> because I want to sync it with an incoming midi time clock...

In this case you have to create an MSP signal out of your bangs.

Same issue, just the other way around. But it needs to be synced...

Look at sync~, whic is exactly made for that. The help file explains all...

Matthew Wilkens wrote:
> unfortunately the reason I am trying to sync a phasor~ with bangs is
> because I want to sync it with an incoming midi time clock...

In this case you have to create an MSP signal out of your bangs.
Same issue, just the other way around. But it needs to be synced...
Look at sync~, whic is exactly made for that. The help file explains all...

Trond, I tried those objects you mentioned, abstractions of audio rate tempo clock.. it crashes within minutes of running in my rather large sequencer patch. The regular metro runs fine but if I want to put the file I made into logic and sequence some stuff over it its a nightmare because its slightly off tempo. And for live shows, who knows if the tempo will stop in mid rocking out.

Im not just thinking of myself this is a problem for many people, thats what I was pointing out. And yeah its great to have freedom, thats why I use max/msp.. but at what cost? Im a clean programmer and I know all these problems aren't in my patches, and Its really disappointing because everything else works so well... 

Trond, I tried those objects you mentioned, abstractions of audio rate tempo clock.. it crashes within minutes of running in my rather large sequencer patch.  The regular metro runs fine but if I want to put the file I made into logic and sequence some stuff over it its a nightmare because its slightly off tempo.  And for live shows, who knows if the tempo will stop in mid rocking out.

Im not just thinking of myself this is a problem for many people, thats what I was pointing out.  And yeah its great to have freedom, thats why I use max/msp.. but at what cost?  Im a clean programmer and I know all these problems aren't in my patches, and Its really disappointing because everything else works so well... 


Is it correct that what you are trying to do is illustated in the patch below? I think it's true that you can't use metro this way. It is not meant to be used this way.

The threading system as I came to understand it:

Low-priority events, such as mouse-clicks from a user, are put at the end of the low priority queue and will be executed whenever the events before it have been executed first. This doesn't guarantee any exact timing. When too much events are in the queue, objects such as qmetro stop adding new events until there is room, resulting, for example, in a lower framerate.

Metro works on the scheduler system, which means there is no exact timing, only an 'as close as possible' timing. Every time the scheduler is 'served', it is allowed to execute its pending events. These servings don't occur on an exact time but on a specified interval. This interval is perfectly short enough (2 ms default), for processing 'realtime' events, but definitly not short enough to compare to sample-accurate timing.

When you put max in overdrive, the scheduler interrupts the execution of events in the low priority queue even if the latter hasn't finished processing all pending events. This matters only when your patch does 'as much as possible'-kind-of tasks, such as banging a movie with a qmetro (see above).

The dsp (MSP) thread processes 44100 samples every second, which one can rely on to be timed right. Of course for it to know when to process what (for example when to start adding the values of a sample buffer to the output), it relies on events that are sent to dsp objects. These events are in turn processed in the queue or the scheduler. When you play a sample with a phasor~, all timing (except for the phase 0 event) is done in the dsp thread.

The above, I believe, makes two things clear.

1) metro doesn't deliver sample-accurate timing. Its accuracy may vary up to 2 ms, which is more than enough to hear phasing effects.

2) you have to be aware of all this technological stuff to be able to use max effectively.

I for myself conclude (as Trond says): max is a programming language. If you want to use it, you'll have to learn about programming.

Is it correct that what you are trying to do is illustated in the patch below? I think it's true that you can't use metro this way. It is not meant to be used this way. 

The above, I believe, makes two things clear.
1) metro doesn't deliver sample-accurate timing. Its accuracy may vary up to 2 ms, which is more than enough to hear phasing effects.
2) you have to be aware of all this technological stuff to be able to use max effectively.

Quote: bin wrote on Sat, 07 October 2006 14:33

> i just use audio for all timing. sample tight sounds better to me. 

> or you could use reaktor, which calculates the non audio path at signal rate so i hear...

It's true that Reaktor does event-processing based on sampling (up to 3200 Hz, not signal rate). That system is incredibly crapp..ahum.. inferior to max's event handling and always gives me a headache when tring to actually program a new application in it. For example: what happens when your computer can't handle the amount of events for a short moment? Reaktor turns all cpu off! Or (as I experienced with reaktor 4, don't know about 5) events simply don't reach their destination, or (just as bad) it starts detecting event loops!

Quote: bin wrote on Sat, 07 October 2006 14:33
----------------------------------------------------
> i just use audio for all timing. sample tight sounds better to me. 
> or you could use reaktor, which calculates the non audio path at signal rate so i hear...

Quote: mattijs@samplemadness.nl wrote on Tue, 10 October 2006 19:44

Quote: mattijs@samplemadness.nl wrote on Tue, 10 October 2006 19:44
> Reaktor turns all cpu off! 

For more on the scheduler and event timing, please check out Joshua's article

https://cycling74.com/story/2005/5/2/133649/9742

So, for example, the (high priority) scheduler will run at the sample rate if the Signal Vector is 1 and the SIAI (Scheduler In Audio Interrupt) option is checked?

Wow, that article was very enlightening, I wish I would have seen that before.. but in the end it still told me that basically no options make the scheduler totally reliable in all situations... ugh.

> I posted 2 topics about problems with metro and tempo. I have seen

> at least 4 others in the past couple months. Why is such an

> essential object/series of objects flawed? I don't know of any other

> software including poor quality ones that go out of sync like this...

I think there where a lot more replies to it than 4. Did you understand 

those? You do have to sync if you want them synced, thats basically all...

If the scheduler tick is so much worse than lets say a quartz driven 

watch, it will help you to design your patches more solid. Realy, sync 

them instead of free running. It directly points to a possible flaw of 

In the last years we had probably hundreds of threads about it. (You 

could read them all and see how they answer the same questions all the 

time...) So I do see a problem here, but its more about how to teach 

newcomers to understand and finally do it to their satisfaction...

As cycling is now concentrating on Max 5, I am sure any constructive 

proposals are more than welcome. Complaints about "flaws" won't help 

though. If you have ideas how it should be done instead, I guess it will 

Also bug reports will be listened to if they follow the guidelines...

Nicholas C. Raftis III wrote:
> I posted 2 topics about problems with metro and tempo.  I have seen
> at least 4 others in the past couple months.  Why is such an
> essential object/series of objects flawed?  I don't know of any other
> software including poor quality ones that go out of sync like this...

I think there where a lot more replies to it than 4. Did you understand 
those? You do have to sync if you want them synced, thats basically all...

If the scheduler tick is so much worse than lets say a quartz driven 
watch, it will help you to design your patches more solid. Realy, sync 
them instead of free running. It directly points to a possible flaw of 
your patch design...

In the last years we had probably hundreds of threads about it. (You 
could read them all and see how they answer the same questions all the 
time...) So I do see a problem here, but its more about how to teach 
newcomers to understand and finally do it to their satisfaction...

As cycling is now concentrating on Max 5, I am sure any constructive 
proposals are more than welcome. Complaints about "flaws" won't help 
though. If you have ideas how it should be done instead, I guess it will 
at least be considered...

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 15:54

> So I do see a problem here, but its more about how to teach 

> newcomers to understand and finally do it to their satisfaction...

That's right, and honestly I believe there is some improvement possible there. New max users are aware that the learning curve is steep, but not that it so steep as that you actually have to be aware of pretty in-depth technical details.

I wouldn't know how to fix this though. I can imagine putting a big warning IF YOU'RE BAD AT MATH, GO AWAY! sign on the first page of the manual wouldn't encourage artists to get to work with max.

Perhaps some ducumentation/education talents can put together a 'learn this first' manual. I'd be quite a challenge though, it shouldn't be bigger than 5 pages and cover all basics of dsp and multi-threaded programming..

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 15:54
----------------------------------------------------
> So I do see a problem here, but its more about how to teach 
> newcomers to understand and finally do it to their satisfaction...

That's right, and honestly I believe there is some improvement possible there. New max users are aware that the learning curve is steep, but not that it so steep as that you actually have to be aware of pretty in-depth technical details. 

Im not a newcomer, and Ive tried every single possible performance adjustment, signal in audio interrupt, overdrive, performance options.. using abstractions. and I was saying ive read at least 4 other threads about this, and Im sure tons of post each thread. If your saying there have been hundreds.. shouldn't something get re-thought?

All Im saying is maybe the priority of the metro and tempo should be bumped up to the top, and/or a signal rate tempo~ or metro~ object should be included that is dependable.

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 07:54

> > I posted 2 topics about problems with metro and tempo. I have seen

> > at least 4 others in the past couple months. Why is such an

> > essential object/series of objects flawed? I don't know of any other

> > software including poor quality ones that go out of sync like this...

> I think there where a lot more replies to it than 4. Did you understand 

> those? You do have to sync if you want them synced, thats basically all...

> If the scheduler tick is so much worse than lets say a quartz driven 

> watch, it will help you to design your patches more solid. Realy, sync 

> them instead of free running. It directly points to a possible flaw of 

> In the last years we had probably hundreds of threads about it. (You 

> could read them all and see how they answer the same questions all the 

> time...) So I do see a problem here, but its more about how to teach 

> As cycling is now concentrating on Max 5, I am sure any constructive 

> proposals are more than welcome. Complaints about "flaws" won't help 

> though. If you have ideas how it should be done instead, I guess it will 

> Also bug reports will be listened to if they follow the guidelines...

Im not a newcomer, and Ive tried every single possible performance adjustment, signal in audio interrupt, overdrive, performance options.. using abstractions.  and I was saying ive read at least 4 other threads about this, and Im sure tons of post each thread.  If your saying there have been hundreds.. shouldn't something get re-thought?

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 07:54
----------------------------------------------------
> Nicholas C. Raftis III wrote:
> > I posted 2 topics about problems with metro and tempo.  I have seen
> > at least 4 others in the past couple months.  Why is such an
> > essential object/series of objects flawed?  I don't know of any other
> > software including poor quality ones that go out of sync like this...
>
> I think there where a lot more replies to it than 4. Did you understand 
> those? You do have to sync if you want them synced, thats basically all...
>
> If the scheduler tick is so much worse than lets say a quartz driven 
> watch, it will help you to design your patches more solid. Realy, sync 
> them instead of free running. It directly points to a possible flaw of 
> your patch design...
>
> In the last years we had probably hundreds of threads about it. (You 
> could read them all and see how they answer the same questions all the 
> time...) So I do see a problem here, but its more about how to teach 
> newcomers to understand and finally do it to their satisfaction...
>
> As cycling is now concentrating on Max 5, I am sure any constructive 
> proposals are more than welcome. Complaints about "flaws" won't help 
> though. If you have ideas how it should be done instead, I guess it will 
> at least be considered...
>
> Also bug reports will be listened to if they follow the guidelines...
>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>
----------------------------------------------------


Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04

But probably not a dsp programmer either.. from the internal architecture of max it's obvious that metro shouldn't work the way you expect it to. Of course, when you are not familiar with the architecture of max I wouldn't expect you to know this. What has to be changed is the help files or tutorials or any other documentation, but not max.

metro~: think this through.. what would it do? It would trigger an audio loop every so-much milliseconds.. hey, wait! That is actually the same functionality as phasor~!

Maybe it would be a good idea for you to post a specific idea you'd like to realize so that ppl can advise you which path to choose given the architecture of max.

Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04
----------------------------------------------------
> Im not a newcomer

Metro~ would output bangs at signal rate, so we wouldn't have to sit here with 10 different versions of phasor and train with edge and notice that they all are out of sync. At least when I ran that test patch above, they were all ms off, and they were reading that they were up to 2 ms off each metro beat.

> Maybe it would be a good idea for you to post a specific idea you'd like to realize so that ppl can advise you which path to choose given the architecture of max.

I think Ive said what it is I want a million times, but heres 1 million and one:

A trustworthy metro or tempo object that stays on exact beat so I can put it into logic and it will fit with anything else, and that I don't have to know how to program in C to use.

Quote: mattijs@samplemadness.nl wrote on Wed, 11 October 2006 10:25

> Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04

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

> But probably not a dsp programmer either.. from the internal architecture of max it's obvious that metro shouldn't work the way you expect it to. Of course, when you are not familiar with the architecture of max I wouldn't expect you to know this. What has to be changed is the help files or tutorials or any other documentation, but not max.

> metro~: think this through.. what would it do? It would trigger an audio loop every so-much milliseconds.. hey, wait! That is actually the same functionality as phasor~!

Metro~ would output bangs at signal rate, so we wouldn't have to sit here with 10 different versions of phasor and train with edge and notice that they all are out of sync.  At least when I ran that test patch above, they were all ms off, and they were reading that they were up to 2 ms off each metro beat.

Quote: mattijs@samplemadness.nl wrote on Wed, 11 October 2006 10:25
----------------------------------------------------
> Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04
> ----------------------------------------------------
> > Im not a newcomer
>
> But probably not a dsp programmer either.. from the internal architecture of max it's obvious that metro shouldn't work the way you expect it to. Of course, when you are not familiar with the architecture of max I wouldn't expect you to know this. What has to be changed is the help files or tutorials or any other documentation, but not max.
>
> metro~: think this through.. what would it do? It would trigger an audio loop every so-much milliseconds.. hey, wait! That is actually the same functionality as phasor~!
>

>
> Regards,
> Mattijs
----------------------------------------------------


It sounds like you are getting pretty frustrated. Perhaps you could try 

posting a patch that demonstrates what you are trying to accomplish so 

that the nice people on the forum can help you in a more effective way.

Saying that you want a perfect metro is a pretty vague request for help, 

considering that we have no clue what you are putting after your metro.

It sounds like you are getting pretty frustrated.  Perhaps you could try 
posting a patch that demonstrates what you are trying to accomplish so 
that the nice people on the forum can help you in a more effective way.

Saying that you want a perfect metro is a pretty vague request for help, 
considering that we have no clue what you are putting after your metro.

Well thats what I want. Funny how logic, reaktor, nord modular, live, fruityloops and every other software Ive ever used stays in perfect sync but not max. I love max, the flexibility, the infinite possibilites.. but why is it all objects preform flawlessly but (to me) the most essential one.

what am I putting after my metro? A very complex sequencer patch that has loads of 16 step sequencers and sampler modules and tons of things. but it doesn't matter if I just put a sine wave with an ADSR, the problem is still the same.. its off by a few ms no matter what settings I use.. and often after an hour of messing with my patch it ends up randomly stopping the metro and when I start it it will stop after about another minute...

The thing thats frustrating me is that people are acting like this problem is with me and not with the metro objects, and yet there sitting here saying they have the same problem.

Well thats what I want.  Funny how logic, reaktor, nord modular, live, fruityloops and every other software Ive ever used stays in perfect sync but not max.  I love max, the flexibility, the infinite possibilites.. but why is it all objects preform flawlessly but (to me) the most essential one.

what am I putting after my metro?  A very complex sequencer patch that has loads of 16 step sequencers and sampler modules and tons of things.  but it doesn't matter if I just put a sine wave with an ADSR, the problem is still the same.. its off by a few ms no matter what settings I use.. and often after an hour of messing with my patch it ends up randomly stopping the metro and when I start it it will stop after about another minute...

The thing thats frustrating me is that people are acting like this problem is with me and not with the metro objects, and yet there sitting here saying they have the same problem.


show us the ADSR simple patch that doesnt work.

On Oct 11, 2006, at 2:21 PM, Nicholas C. Raftis III wrote:

> Well thats what I want. Funny how logic, reaktor, nord modular, 

> live, fruityloops and every other software Ive ever used stays in 

> perfect sync but not max. I love max, the flexibility, the 

> infinite possibilites.. but why is it all objects preform 

> flawlessly but (to me) the most essential one.

issues with MSP timing