<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[The 1-Bit Forum — A Python script to convert XM modules into something]]></title>
		<link>http://randomflux.info/1bit/viewtopic.php?id=120</link>
		<atom:link href="https://randomflux.info/1bit/extern.php?action=feed&amp;tid=120&amp;type=rss" rel="self" type="application/rss+xml" />
		<description><![CDATA[The most recent posts in A Python script to convert XM modules into something.]]></description>
		<lastBuildDate>Thu, 09 Feb 2017 11:10:10 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: A Python script to convert XM modules into something]]></title>
			<link>http://randomflux.info/1bit/viewtopic.php?pid=1133#p1133</link>
			<description><![CDATA[<p>Thanks a lot, I wouldn&#039;t even think that the bottleneck is the array allocation. I changed the script a bit, replaced multi-dimensional list with one-dimensional, and now it takes just a second to convert a module, which is good enough, I think.</p><p>The improved version re-attached to the first post.</p>]]></description>
			<author><![CDATA[null@example.com (Shiru)]]></author>
			<pubDate>Thu, 09 Feb 2017 11:10:10 +0000</pubDate>
			<guid>http://randomflux.info/1bit/viewtopic.php?pid=1133#p1133</guid>
		</item>
		<item>
			<title><![CDATA[Re: A Python script to convert XM modules into something]]></title>
			<link>http://randomflux.info/1bit/viewtopic.php?pid=1132#p1132</link>
			<description><![CDATA[<p>Ah, excellent. I&#039;ve been using my own (C++) lib for quick prototyping of XM converters since a while so I have no acute need for this, but mine is very badly designed so I can&#039;t publish it as a stand-alone library. So it&#039;s nice to have a clean and well-designed backup plan.</p><p>I&#039;m surprised it&#039;s so slow, though. I mean Python is not exactly fast, but it shouldn&#039;t take that long. I took the liberty of running the script through cProfile and this is what I got:</p><div class="codebox"><pre><code>         5450 function calls in 7.201 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.021    0.021    7.201    7.201 convert_octode.py:3(&lt;module&gt;)
        1    0.000    0.000    0.000    0.000 genericpath.py:55(getsize)
        1    7.138    7.138    7.138    7.138 xmlib.py:10(XM)
        4    0.000    0.000    0.000    0.000 xmlib.py:133(get_order)
        2    0.000    0.000    0.000    0.000 xmlib.py:140(get_pattern_length)
     1024    0.002    0.000    0.002    0.000 xmlib.py:148(get_note)
     1024    0.002    0.000    0.002    0.000 xmlib.py:153(get_instrument)
     1024    0.002    0.000    0.002    0.000 xmlib.py:158(get_volume)
     1040    0.002    0.000    0.002    0.000 xmlib.py:163(get_effect)
     1025    0.004    0.000    0.004    0.000 xmlib.py:168(get_parameter)
       15    0.000    0.000    0.000    0.000 xmlib.py:26(read_word)
        3    0.000    0.000    0.000    0.000 xmlib.py:29(read_dword)
        1    0.029    0.029    0.029    0.029 xmlib.py:32(load)
        1    0.000    0.000    7.138    7.138 xmlib.py:4(&lt;module&gt;)
        1    0.000    0.000    0.000    0.000 {len}
        2    0.000    0.000    0.000    0.000 {method &#039;append&#039; of &#039;array.array&#039; objects}
        1    0.000    0.000    0.000    0.000 {method &#039;close&#039; of &#039;file&#039; objects}
        1    0.000    0.000    0.000    0.000 {method &#039;disable&#039; of &#039;_lsprof.Profiler&#039; objects}
        1    0.000    0.000    0.000    0.000 {method &#039;fromfile&#039; of &#039;array.array&#039; objects}
        1    0.000    0.000    0.000    0.000 {open}
        1    0.000    0.000    0.000    0.000 {posix.stat}
      276    0.001    0.000    0.001    0.000 {range}</code></pre></div><p>I think the main bottleneck happens with setting up the arrays on constructing XM class object. I tried with XMs of varying complexity, there is almost no change in execution time. So the conversion functions aren&#039;t the problem, in any case. Not sure how that can be rectified. One could of course read the song parameters first and only set up the necessary amount of arrays afterwards, but I have a feeling that that doesn&#039;t tackle the problem at its root. </p><p>Hmm, <a href="https://stackoverflow.com/questions/36778568/why-are-pythons-arrays-slow">this</a> looks interesting, especially the last answer. I&#039;m not a Python coder at all though.</p>]]></description>
			<author><![CDATA[null@example.com (utz)]]></author>
			<pubDate>Thu, 09 Feb 2017 09:34:12 +0000</pubDate>
			<guid>http://randomflux.info/1bit/viewtopic.php?pid=1132#p1132</guid>
		</item>
		<item>
			<title><![CDATA[A Python script to convert XM modules into something]]></title>
			<link>http://randomflux.info/1bit/viewtopic.php?pid=1131#p1131</link>
			<description><![CDATA[<p>A little project I just made - a small Python library to parse XM modules and extract song data from them easily. Comes with two example scripts. One of them just prints out notes, the other is a straight port of the xm2octode converter that yields identical output.</p><p>Good: once you have Python installed in your system, you can easily edit, develop, modify the conversion scripts without need of having a compiler around, using popular modern scripting language. Handy for quick prototyping. Also cross-platform.</p><p>Bad: it is (edit: was) really slow, a large Octode module takes a few seconds to convert even on a quad core i5.</p><br /><p>Sure, that&#039;s not a game changer or anything special, but yet another way of doing things.</p><br /><br /><p>Note: I&#039;m personally not a big fan of Python, but use it occasionally. So I have no idea how good Python code should look like. I did it so it just works, not pretty.</p>]]></description>
			<author><![CDATA[null@example.com (Shiru)]]></author>
			<pubDate>Wed, 08 Feb 2017 21:44:18 +0000</pubDate>
			<guid>http://randomflux.info/1bit/viewtopic.php?pid=1131#p1131</guid>
		</item>
	</channel>
</rss>
