New Tool (3.0): Midi Convert

:clownstep:/>

Midi Convert Tool

This tool will put “MIDI Export…” in the “Tools” menu.

Trotch on.

2 Likes

:yeah: got up to “track in pattern” a while ago but got distracted with ticky roll and others. From reading your other threads on this it seems this should be pretty comprehensive when finished.

Great Stuff!

Cheers Conner, will check out!

Sounds really usefull :)
It would be great to import and export tracks of a pattern to midi and vica versa.
Acctually it would be cool if I could drag and drop midi tracks in a song i’m working on.
Will it be something like this eventually??

just double click a .mid file in the disk-op

edit:

unfortunately you can’t open a .mid file into an existing track.

Right now the script only does Export.

My long term goal is to replace the Renoise Import procedure with this script, so that hackers can modify it without annoying the core developers.

So ideally before I die, yes it should be possible.

Is it possible now? No.

Ok. thanks.

PS: I’ll also add your name to “Authors” in the manifest. Didn’t do it out of laziness and forgetfullness. Will do it now and commit.

awesome stuff,cant wait to check it out

oh yes!!!
cna wait to try out, with my e-mu command station

+NICE NICE NICE+

Check the first post for a new version (0.3).

  
-- TODO:  
-- LBP procedure is flawed, for example:  
-- Note pos:1, LBP changed pos:3, LBP changed pos:5, Note pos:7  
-- Current algorithm only detects LBP on pos:5  
-- But, pos:3 will affect the timeline?  
  
-- TODO:  
-- Panning? Groove settings?  
  
-- TODO:  
-- NNA and a more realistic note duration could, in theory,  
-- be calculated with the length of the sample and the instrument  
-- ADSR properties.  
  
-- TODO:  
-- Import module.  
  

Patches welcome.

Remember LPB changes will only make any difference to notes play between that line and the next LPB change. If you had no notes between pos.3 and pos.5 in the above example then the change of LPB isn’t going to make any difference to output. Unfortunately you haven’t provided with an example including notes on lines etc…

If this is true, then the code should work, and I won’t need to change anything. Of course, test cases and plain old bugs are bound to happen. This is where I hand it off to the community; patches welcome! :)

As an aside, I write tempo changes to the tempo track like the MIDI specification states, but I use GarageBand to test and it doesn’t support multiple tempos, so I have no idea if it works.

EDIT: Sorry I’m going mad and getting myself confused between LPB and TPL settings. Been a long day!

Um… Changes to LPB will make a difference. If you export with your example above with and without the LPB change at pos.3 and the files come out exactly the same then I agree there is something fishy.

(Will leave my original rambling in anyway though…)


Well TPL does not change the length of a line does it, only how many of subdivisions it’s made of. Therefore it will only affect commands sent within the changed period and that rely on the old Tick system (Dx command for example.) Also automations and LFOs within Renoise but I’m not sure if you’ve even tackled that yet and MIDI would want to stay at the PPQ96 anyway (and as the Renoise file may only have two points saved you’d have to do the interpolation yourself so guessing this may be an omission.) Basically by changing TPL you are changing Renoise’s internal PPQ, your outputted MIDI file stays at a constant PPQ, thus you’ll only see a difference on commands that rely on Ticks for timing.

This is unless it was a typo for BPM.

Although you imply you wouldn’t be able to check if you’ve worked that correctly.

No, I will not be doing this.

A contraire, I’m implying that there’s 2000+ lines of code in there. I’ve obviously tested several files and am happy with the results. For every math snippet, there’s a hundred lines of other stuff.

At this point, baring any unforeseen bugs, this version is on par with the current PHP and .NET versions out there.

For me, that’s mission accomplished.

If you test it, and find it works worse than the PHP version, and can provide an example XRNS, i’ll probably look at it.

Otherwise, I’m more interested in patches in the form of code from this point on.

Just a bump in case you missed my edit above where I realised I was getting myself confused.

Very good work though mate! Something a lot of people have wanted a long time and you’ve put a lot of effort with seemingly good results so far :)

Yeah, I saw that. Thanks! I’m gonna leave it as a ??? for now.

I’m pretty sure there are problems, but I don’t know if anyone will encounter them in practical situations. Renoise to MIDI, from the get go, is conceptually imperfect since the two paradigms are sort of the anti of the other. Test cases and “I actually want this to work” will come into play, I think. I mean me personally I will never use this tool? it’s hard to test something you will never use. Know what I mean? I have to rely on proof of concepts and community help for the stuff I don’t personally care about.

Cheers.

Published v 0.3.1 to the Tools page.

http://tools.renoise.com/tools/midi-convert

Updated to version 0.32:

Fix delay calculations, added more yield() calls because I was having problems with some songs and it should also help with slower computers, don’t print to terminal unless dbug_mode is set to true.

http://tools.renoise.com/tools/midi-convert

good job!

it is work for me.
save and load back to cubase! nice! :yeah:

  • midi track names maybe the same like the renoise song track names. don’t you?

cant wait for some future updates…
thank yuo mate!!!

thanks conner , verry usefull