<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: a glance toward audio</title>
	<atom:link href="http://philosophy.modern-carpentry.com/2010/01/a-glance-toward-audio/feed/" rel="self" type="application/rss+xml" />
	<link>http://philosophy.modern-carpentry.com/2010/01/a-glance-toward-audio/</link>
	<description>investigations into the intersections of software, language, randomness, and thought</description>
	<lastBuildDate>Sat, 19 Nov 2011 02:29:13 -0800</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Experiments with audio, part VII</title>
		<link>http://philosophy.modern-carpentry.com/2010/01/a-glance-toward-audio/comment-page-1/#comment-51</link>
		<dc:creator>Experiments with audio, part VII</dc:creator>
		<pubDate>Mon, 11 Jan 2010 20:30:21 +0000</pubDate>
		<guid isPermaLink="false">http://philosophy.modern-carpentry.com/?p=192#comment-51</guid>
		<description>[...] Previously I linked to a video of a demo made by Corban Brook, in which he uses JavaScript to calculate an FFT, and then visualizes the resulting spectrum data.  After this test we wanted to see how expensive these calculations were in script, so I ported his code to C++ and stuck it into the audio element&#8217;s decode loop.  A number of people have expressed concern over the idea of doing this in JavaScript and the cost in terms of speed and time you could spend on other work (e.g., complex real-time graphics).  Therefore, I wanted to have a good way to compare speeds.  I&#8217;ve already received feedback in the bug that native FFT calculations probably aren&#8217;t warranted, and we should optimize the JavaScript case.  I anticipated this, and having been involved with as much 3D in the browser as we have, I know that JavaScript is up to the challenge of doing very fast calculations.  As soon as I convert over to the faster WebGL arrays I&#8217;ll do some tests comparing JS-FFT and Native-FFT so we have better numbers.  In the mean time, the C++ FFT is working really well, and a number of new visualizations have been done with it, including this one by Thomas Saunders. [...]</description>
		<content:encoded><![CDATA[<p>[...] Previously I linked to a video of a demo made by Corban Brook, in which he uses JavaScript to calculate an FFT, and then visualizes the resulting spectrum data.  After this test we wanted to see how expensive these calculations were in script, so I ported his code to C++ and stuck it into the audio element&#8217;s decode loop.  A number of people have expressed concern over the idea of doing this in JavaScript and the cost in terms of speed and time you could spend on other work (e.g., complex real-time graphics).  Therefore, I wanted to have a good way to compare speeds.  I&#8217;ve already received feedback in the bug that native FFT calculations probably aren&#8217;t warranted, and we should optimize the JavaScript case.  I anticipated this, and having been involved with as much 3D in the browser as we have, I know that JavaScript is up to the challenge of doing very fast calculations.  As soon as I convert over to the faster WebGL arrays I&#8217;ll do some tests comparing JS-FFT and Native-FFT so we have better numbers.  In the mean time, the C++ FFT is working really well, and a number of new visualizations have been done with it, including this one by Thomas Saunders. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Humphrey</title>
		<link>http://philosophy.modern-carpentry.com/2010/01/a-glance-toward-audio/comment-page-1/#comment-47</link>
		<dc:creator>David Humphrey</dc:creator>
		<pubDate>Mon, 11 Jan 2010 12:55:08 +0000</pubDate>
		<guid isPermaLink="false">http://philosophy.modern-carpentry.com/?p=192#comment-47</guid>
		<description>This is really cool, thanks for putting it up!  One thing...performance will be really bad with a debug build like you&#039;re running.  You should try doing a release build, and you&#039;ll see a huge difference.</description>
		<content:encoded><![CDATA[<p>This is really cool, thanks for putting it up!  One thing&#8230;performance will be really bad with a debug build like you&#8217;re running.  You should try doing a release build, and you&#8217;ll see a huge difference.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

