Conner fixed the bugs mentioned above (V0.9).
http://www.renoise.com/tools/midi-convert
As long as I tested, now the midi file could be imported normally to DAWs which had a trouble before (Reason, FL, MuLab, energyXT, etc).
Thanks for the effort, Conner!! 
Two small suggestions:
an export option on each individual track (to be exported on midi channel 1 or custom channel)
export every track individually (on midi channel 1 or custom channel)
Of course the midi can be split up in most hosts onto individual tracks but they will still be on the different midi channels which makes for lots of copying and pasting in hosts that don’t allow arbitrary switching of midi channel numbers.
Any chance to get export of pitch bends?
Another question: What do we do to export songs that match up with music timing? IE: Each module Pattern = a measure. As is, when i export, the patterns do not line up with measures.
I’m not actively maintaining this script at this time.
There is no chance of pitch bends in the near future. Or anything else that isn’t a show stopper. Sorry.
Patches welcome.
There is a bug with consequent notes of the same pitch creating randomly notes of zero length, I described it here:
consequent notes of the same pitch
Wow, it seems almost unlikely that such a bug crept through.
Thanks for reporting 
As maintainer of the renoise-team tools, I will attempt to come up with a fix - unless of course Conner steps in before me
Yeah I was a bit amazed that nobody reported this already, since it makes the exported files nearly unuseable.
I’m importing them in Reaper, I don’t know if some other software has some intelligent filter to reverse cases like these, since it’s pretty evident zero-length notes must be an accident?
Anyway, I would love to see this fixed, now I’ve been exporting MIDs via the EnergyXT VST plug, which is slooow…
Wow, it seems almost unlikely that such a bug crept through.
Thanks for reporting
As maintainer of the renoise-team tools, I will attempt to come up with a fix - unless of course Conner steps in before me
It’s all yours! 
Thx. I’ll look into it
I believe I have fixed the bug, it would be great if someone could confirm this is true.
Technically, I just made the note-sorting take note-on/off into consideration.
Oh, and nice code to step in and fix. Props to Conner 
Wow, thanks! One comment, current code has
DBUG_MODE = true
COROUTINE_MODE = false
It should be reversed for release.
It should be reversed for release.
OK, a few downloads later…,I’ll release it then
PS: how about your git repository?
https://github.com/connerbw/xrnx/tree/master/com.renoise.MidiConvert.xrnx
PS: how about your git repository?
https://github.com/connerbw/xrnx/tree/master/com.renoise.MidiConvert.xrnx
I suggest:
Fork & pull
The_fork & pull model_lets anyone fork an existing repository and push changes to their personal fork without requiring access be granted to the source repository. The changes must then be pulled into the source repository by the project maintainer. This model reduces the amount of friction for new contributors and is popular with open source projects because it allows people to work independently without upfront coordination.
More info: https://help.github.com/articles/using-pull-requests/
Hey guys
Still getting that same error message as above:
‘C:\Users\Mikael\AppData\Roaming\Renoise\V3.0.1\Scripts\Tools\com.renoise.MidiConvert.xrnx\main.lua’ failed in one of its notifiers.
The notifier will be disabled to prevent further errors.
Please contact the author (Dac Chartrand, Marvin Tjon) for assistance…
Unknown Lua interpreter error occurred!
Never had any problems until switching to a 64bit system.
Any sollutions on the horizon?!
I think this is quite an important tool, and would be happy to fix any bugs… but:
Still getting that same error message as above:
I’m a bit confused here - which error message areyou pointing to?
The bug report at the top of the page was fixed a couple of years ago
If would be great if you could somehow reproduce the bug, describe exactly what steps you take to trigger it.
Although, I’m pretty sure running a 64bit system shouldn’t affect things (but who knows ^_^)
Hey
Well
I have two computers, both with latest versions of Renoise and this very clever little tool installed. Only difference is that when I “export song to midi”, I get
the error message I posted on my 64bit system. I’ve tried several tracks, and there is no problem when converting on the 32bit system.
I get this message:
‘C:\Users\Mikael\AppData\Roaming\Renoise\V3.0.1\Scripts\Tools\com.renoise.MidiConvert.xrnx\main.lua’ failed in one of its notifiers.
The notifier will be disabled to prevent further errors.
Please contact the author (Dac Chartrand, Marvin Tjon) for assistance…
Unknown Lua interpreter error occurred!
and that’s it.
Just out of curiosity, has anyone tried the simple xrns file that satobox posted? I’ll attach the file I’m talking about here. With the danoise amendment to the function ‘export_compare’ I get an error message along the lines of: ./export.lua:66 attempt to index local ‘a’ (a nil value) blah blah… This is on a Linux 64-bit system
Edit: Looking a tiny bit closer, I’m not sure that this amendment to the script:
-- Used to sort a table in export_midi()
function export_compare(a, b)
if (a[1] == b[1]) then -- this line
return (string.sub(a[2],0,2)~="On") and true or false -- and this
else
return a[1] < b[1]
end
end
Is going to quite do what you want with the lua sort function danoise
I’m not sure that this amendment to the script:Is going to quite do what you want with the lua sort function danoise
The sort algorithm is quite simple: boolean value determines if item should bubble up or not.
I just modified it so that in the case that two events arrive on the same line, a note-off event will take precedence.
But then it becomes really strange, because now it seems that in this particular case the table will now contain a “nil” entry.
This simply shouldn’t happen. The source table never contains a nil value, and the sort method always return a boolean.
Very strange, but at least it gives us a particular spot to start investigating…
Oh, and the behavior seems consistent across 64 and 32bit systems according to my quick test (both Renoise 3.0.1 runningon Win7).
@Mikael: are you sure you are using the same song data, and the same version of the tool?
But then it becomes really strange, because now it seems that in this particular case the table will now contain a “nil” entry.
This simply shouldn’t happen. The source table never contains a nil value, and the sort method always return a boolean.
Very strange, but at least it gives us a particular spot to start investigating…
Yup, I agree sir that a ‘nil’ does not appear in the ‘sort_me’ table. However (I’m just speculating here BTW)…I think you may find that you can’t put your ‘equal if’ test in the comapre sort function. Lua doesn’t like it. It seems to fall off the end of the table when it goes through its sort algorithim, hence the funny nil result. Now I’m not a Lua expert or anything but I think that Lua doesn’t like the situation when ‘a’ and ‘b’ are the same. One way of looking at it is that becuase you are returning a boolean (either true or false) in that situation it can confuse Lua. By the looks of it it doesn’t know what to do. You might be saying ‘IF ‘a’ and ‘b’ are the same THEN ‘a’ comes before ‘b’ AND ‘b’ comes before ‘a’’!
Silly I know, but we didn’t implement the sort function in Lua