metro weirdness(es) with new time formats - bug(s) or am I missing something?
Hello,
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
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?
MacIntel Core 2 Duo - MacOS X 10.4.11- Max 5.0.2
Roald Baudoux
Thanks for the patch.
Yes - there are some problems here - we'll have a look at them.
-A
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.
-A
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.
-A