<?xml version="1.0" encoding="UTF-8"?>
	<rss version="2.0"
		xmlns:content="http://purl.org/rss/1.0/modules/content/"
		xmlns:wfw="http://wellformedweb.org/CommentAPI/"
		xmlns:dc="http://purl.org/dc/elements/1.1/"
		xmlns:atom="http://www.w3.org/2005/Atom"

			>

	<channel>
		<title>Cycling 74  &#187;  Topic: metro vs. phasor~ for timing</title>
		<atom:link href="http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/feed" rel="self" type="application/rss+xml" />
		<link>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/feed</link>
		<description></description>
		<pubDate>Wed, 19 Jun 2013 04:13:17 +0000</pubDate>
		<generator>http://bbpress.org/?v=2.2.4</generator>
		<language></language>

		
														
					
				<item>
					<guid>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-47653</guid>
					<title><![CDATA[metro vs. phasor~ for timing]]></title>
					<link>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-47653</link>
					<pubDate>Fri, 08 Jan 2010 20:14:37 +0000</pubDate>
					<dc:creator>nonagon</dc:creator>

					<description>
						<![CDATA[
						<p>I&#8217;m fairly new to the Max world, and am currently developing strictly in Max for Live.</p>
<p>In my explorations of others&#8217; work, I&#8217;ve noticed that a lot of people seem to use a quantized phasor~ coupled with an edge detector to generate timed bangs instead of using a metro object.  Is there some advantage to this?  In theory I suppose an audio-rate edge detector could be 44 times more accurate at 44.1KHz than a metro refreshing every 1ms, but being off by at most 1 ms doesn&#8217;t seem all that bad to me, so I feel like I might be missing something.</p>
<p>Can anyone offer any insight into best practices for generating a solid timing signal?  Thanks!</p>
						]]>
					</description>

					
					
				</item>

			
				<item>
					<guid>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171339</guid>
					<title><![CDATA[Re: metro vs. phasor~ for timing]]></title>
					<link>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171339</link>
					<pubDate>Sat, 09 Jan 2010 00:55:12 +0000</pubDate>
					<dc:creator>seejayjames</dc:creator>

					<description>
						<![CDATA[
						<p>The refresh rate of objects like [metro] (scheduler-based objects) allow for slop in order to keep other things (like GUI refresh) working nicely. If you use phasor~ and have Overdrive on, the timing should be rock-solid, at the occasional expense of drawing etc. So it&#8217;s not just 44 times as accurate, it also doesn&#8217;t drift&#8230; you can at first be off by 1 msec, but eventually you could be off by a lot more, by design.</p>
<p>Definitely use the audio objects for timing if your needs are precise.</p>
						]]>
					</description>

					
					
				</item>

			
				<item>
					<guid>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171340</guid>
					<title><![CDATA[Re: metro vs. phasor~ for timing]]></title>
					<link>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171340</link>
					<pubDate>Sat, 09 Jan 2010 02:27:28 +0000</pubDate>
					<dc:creator>nonagon</dc:creator>

					<description>
						<![CDATA[
						<p>Thanks for the reply, that makes a lot of sense.  phasor~ it is, then!</p>
						]]>
					</description>

					
					
				</item>

			
				<item>
					<guid>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171341</guid>
					<title><![CDATA[Re: metro vs. phasor~ for timing]]></title>
					<link>http://cycling74.com/forums/topic/metro-vs-phasor-for-timing/#post-171341</link>
					<pubDate>Sat, 09 Jan 2010 09:16:09 +0000</pubDate>
					<dc:creator>pid</dc:creator>

					<description>
						<![CDATA[
						<p>remember that in m4l &#8216;overdrive&#8217; is effectively always on, as is AII, as is audio, so in that respect very different to max, so it is a no brainer to use the phasor~. but of course transport locks to live transport rock solid if that is what you need too.</p>
						]]>
					</description>

					
					
				</item>

					
		
	</channel>
	</rss>

