New Tool (3.0): Midi Convert

There is a bug with consequent notes of the same pitch creating randomly notes of zero length, I described it here:

https://forum.renoise.com/t/export-to-midi-file/38248

consequent notes of the same pitch

Wow, it seems almost unlikely that such a bug crept through.

Thanks for reporting :slight_smile:

As maintainer of the renoise-team tools, I will attempt to come up with a fix - unless of course Conner steps in before me :slight_smile:

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 :slight_smile:

As maintainer of the renoise-team tools, I will attempt to come up with a fix - unless of course Conner steps in before me :slight_smile:

It’s all yours! :wink:

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 :badteethslayer:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

I’m not sure that this amendment to the script:Is going to quite do what you want with the lua sort function danoise :slight_smile:

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 :slight_smile:

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.

A boolean is really the only allowed return value for the sort method, in case of the “plain” compare it’s evaluating the expressiona[1] < b[1].When they are the same, the result would simply be false.

But really, you should be able to implement as complicated a comparison as you would want - as long as there is a boolean result, even a “wrong” sorting algorithm should not result in nil entries, just that the entries would end up having the wrong order.

This is what confuses me. Hmm, maybe I should pop a question on the lua mailing list and see what the gurus have to say.

Technically if I was looking at it from the Lua point of view, if both ‘a’ and ‘b’ are the same then ignore (irrespective of what boolean the user returns from the compare function.) No swap would need to occur.

Again I agree that you should be able to implement as complex a sort method as you like. But alas Lua doesn’t play ball. Trouble is I think it has made things much more awkward for you :frowning:

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?

Actually… I was mistaken. I was using ver 0.9 on my 32bit computer. I uninstalled the latest version (ver 0.92 was it?) from my 64bit system and installed ver0.9 on it… and voila.

Works as a charm

Hi…

Just thought I’d let you know I’m getting the same error as above too…

"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!"

I’m running Win 7 Pro 64 Bit with Renoise 64Bit - V3.0.1 (Built Oct 13 2014) and Midi Convert v0.91.

I’ve gone back to v0.9 and that’s working fine. :guitar:

Hmm, first of all this page -> http://www.renoise.com/tools/midi-convert shows midi convert v0.91. However I click on that to download and it gives me v0.92. v0.92 of this tool won’t work due to the way Lua works its custom sort function. (Just as a side note I don’t think danoises quick fix would’ve completely fixed the problem anyway even if Lua would’ve accepted his sort function…but don’t tell danoise that :wink: )

Let me just clarify for you what the problem (that you could run into) is here with Midi Convert…(I’ll assume you’re using another version rather than 0.92.)

If you have this simple situation…(my best module I’ve ever written :D)

Attachment 5435 not found.

If you ask Midi Convert to export that and you then reload the resulting midi file back into Renoise you’ll probably get something along the lines of:

Attachment 5436 not found.

That tripped Midi Convert up. Cut notes because…well unfortunately just dumping all the columns/tracks notes and note offs into a table and then sorting that table isn’t quite a good enough solution. It will kinda work about 80-90% of the time, but not quite all of the time :slight_smile: