Roald Baudoux

I am trying to use metro with the new time formats.

I might not use these formats correctly, nevertheless metro presents 

strange behaviour in several situations (please see pasted patcher to 

1. With time expressed as samples, the measured interval doesn't 

change when the patcher's sampling rate changes. It doesn't make 

2. When time is expressed in non-milliseconds formats and not using 

the @interval attribute, metro doesn't seem to understand. Normal?

3.Using the hh:mm:ss.m format with all values except ms zeroed shows 

4. Starting many metros simultaneously seem to make metros using 

metro-related timing behave strangely. Normal?

MacIntel Core 2 Duo - MacOS X 10.4.11- Max 5.0.2

I might not use these formats correctly, nevertheless metro presents  
strange behaviour in several situations (please see pasted patcher to  
see by yourself) :

1. With time expressed as samples, the measured interval doesn't  
change when the patcher's sampling rate changes. It doesn't make  
sense! Normal?
2. When time is expressed in non-milliseconds formats and not using  
the @interval attribute, metro doesn't seem to understand. Normal?
3.Using the hh:mm:ss.m format with all values except ms zeroed shows  
a weird beahaviour. Normal?
4. Starting many metros simultaneously seem to make metros using  
metro-related timing behave strangely. Normal?

metro-weirdnesses-with-new-time-formats-bugs-or-am-i-missing-something

Yes - there are some problems here - we'll have a look at them.

OK - it turns out that the problems are more to do with the docs than anything else.

We need to document the fact that only notevalues can be specified other than milliseconds as non-attribute arguments to a bunch of objects (metro, delay) that had legacy arguments we need to continue to support. So for example metro 10 samples should be interpreted as metro 10ms using the setclock object named samples.

The hh:mm:ss.ms issue will be fixed in the next update.

Once you get all the args to metro worked out, the problem with them misfiring on start should go away. Please let us know if this is not the case.

Yes. We know about it. Unfortunately it's a very tricky fix and it won't make it into 5.03.

I disagree about the auto turning off of a metro when audio goes off. I can easily think of a musical situation where I would not want that to happen. And I think you could patch this up yourself pretty easily.

metro weirdness(es) with new time formats - bug(s) or am I missing something?