I know there are quite some guys out there that could be upset by this request, so please if you’re one of them => Don’t read ! (or back off:)
Fact is, with implementation of such sweets as VSTi support, and now the mighty Piano Roll, Renoise is becoming more and more an all-in-one solution. I recently had a lot of fun making little tunes using only the GM bank of my soundblaster, via Renoise. I was suprised by the results I could achieve this way. This sounded incredibly good compared to what I’d have done if I used Sonar (soft I usually use to create midi files).
But Renoise, is a far more effective tool and it’s really easier and faster to input notes, midi controllers and messages with it… The tunes I made this way with it basically contain nothing more that would do their .mid equivalents. I only used that kind of simple midi data, which is supported by RNS.
So it comes to me as a next logical step, for people like me who have to produce massive amounts of midi files a week (that’s my work), it would be really great and useful to export Midi files with Renoise.
That feature is very important to me, and I’m sure lots of people will find an interest into it.
I think this is kinda going with the “file format” thread. Sorry
Have a nice day, and as everyone says => Thanks for making the best tracker around
Epoq: yes that’s right ! And I’m one of those people also
Go into the Instr.settings pannel, on the “Midi Properties” pannel, turn it ON by clicking “ON”. Chose you midi device (there must be at least one if your sound card has a GM bank, and most have one). Then just browse through the bank as you would do in any other software by touching the “Channel” and “Program button”. That’s the magic of renoise
Let’s have a little brainstorming here. Midi files and renoise songs have different limitations, so the difficult part of this is what to include when converting and how to map the different events between the formats. So if you all can try to explain how you would like this to work by answering the questions below and commenting if there’s any more on your mind, this will be easier and turn out better.
First I list up some of the most important feature differences:
Renoise has 64 tracks, each with a limited polyphony of 10 notes.
Each track can use any mixed combination of instruments.
Midi files type 0 has 16 channels with no polyphony limit, each with only one instrument selected at a time.
Midi files type 1 has any number of tracks, each track having 16 channels like a type 0 file.
(There’s also a type 2, but I think this can be ignored).
Which parts of a renoise song should be exported?
Only notes with velocity?
Track commands -> CC?
Envelopes -> CC?
How should too many tracks in renoise be handled?
How should multiple instruments in one track be handled?
Should speed commands:
be exported as tempo changes
(a fixed number of lines is one beat)
be part of the rythm of notes
(a fixed number of player ticks is one beat)
Which parts of a midi file should be imported?
Only notes with velocity?
CC -> Track commands?
CC -> Envelopes?
How should too many notes in one channel be handled?
(splitting over several renoise tracks probably)
notes with all available Renoise-Midi-Effects - CC’s too
i think one midi-channel with it’s poly-notes should imported in one track … the columns will created automatically … if the max. number of 10 columns is reached … the next track will be used and so on … or the max. column number in Renoise must modified ( i think for all stuff 10 note poly is enough … except classical music … but …)
at the moment i don’t use bank/preset changes but is there no pattern-command for this in renoise? … simply some new commands must be added!
don’t know … i think … MED Soundstudio export it as normal tempo changes …
all in Renoise supported midi-commands and controller-changes … and envelopes-values must be assigned to every note that needs the value …
i highly recommend to download MED soundstudio … and test it’s midi in/export feature … not the very best solution for im / export … but good enough for every normal standart pop/rock-midi file
and Martinal … don’t forget Sysex messages … maybe a sysex-editor (or e.g. a sysex-storage-device for Renoise) must be addet - and every sysex-message must be able to transmitted via a pattern command! … please take a look at MED for inspiration
Selectable, with default being notes, volumes, commands, envelopes, the lot. You should also be able to select which instruments are exported and which are not, with one instrument becoming one track in the midi file.
Create type 1 midi files. One instrument in Renoise -> one track in midi file. There’s no limitation.
This problem doesn’t exist if we create one midi track per one Renoise instrument.
Probably exported as tempo changes.
Should be selectable, with default being everything.
This was for export. For instance when using several drum sounds on one track, should the instruments on one track be splitted over several midi channels or just use the same channel? I guess if I use midifile type 1 I can do as WeeTee said and then use the 16 channels for this. So the limitation will then be 16 instruments per track (at a time).
The problem with this approach is that it can result in a lot of midi tracks/channels. But that’s up to the user how he makes his songs.
I think I’ll do this. It’s the way the pianoroll will treat them (ie it ignores speedchanges) so this is consistent with current behaviour.
I think I’ll wait with sysex in the first implementation.
One thing at a time. How should sysex be imported anyway?
If a midiSysExDevice is created, they could be used somehow I guess.
I guess I’ll have to make a selection screen where the user can choose mappings each time, with reasonable defaults. Example:
CC 0 - [Ignore]
CC 1 - [Ignore]
CC 7 - [Track volume]
CC 10 - [Track panning]
And the other way around for exporting.
And of course RPN and NRPN should be mappable as well.
i understand … don’t know … i never use more than 16 instruments (I’m a VSTi and Midi user - so i see the export less complicated … every instrument needs a midi-channel … with more then 16 instruments - don’t know
i think it’s important as well … e.g. there are so much XG-midi-songs with data-dumps in songs. or my own old songs with a lot of Yamaha MU80 or KORG Wavestation dumps … and a simple storagedevice for sysex-data isn’t so much complicated.
another suggestion is e.g. a pattern-action-editor … designed like the pattern-automation-editor … with some default actions like pattern-jump or pattern-repeat and also some midi-actions like sysex-send from a sysex-storage-device … i know this actions may also pattern-commands … but a visualisation of some important pattern-commands could make it more intuitive …
a little off topic idea: a midiSysExDevice could make automation available for parameters normally accessible only through sysEx messages. How? By letting the user enter the message something like this:
f0 a0 b0 c0 …whatever… XX … f7
where XX is a value inserted from the varying automation value.
But nevertheless, I’ll wait with sysEx in midi im/export until 1) it works fine without it and 2) renoise eventually can use sysEx messages.
The solution is you work with a number of messages saved for each song (“Msg #” field). I’m not sure this is the best way, but it worked pretty well in OctaMED and I used it pretty much on the Amiga. It’s simple but works. A midiSysExDevice wouldn’t work well imo as it’s not really an effect.
I guess you could live without “Insert New” but the other features are more or less what you would need.
I just realized that the picture shows the MIDI file load settings as well, which might be of interest
Problem with this solution is that many sysex messages uses a checksum on the end. Of course it could be done but adds another problem regarding programming and especially the user interface. Also there might be times when you need two fields to be automated (?).
the sysexEd is simple … it’s possible to receive a message from a synth and with the pattern-command 10 (+ the message-number) it can transmitted while playing the song …
there is an auto-terminate option for reveicing sysex-messages - F7 is the normal EndSysEx-byte … but this works only on some synths … e.g. the Yamaha MU80 sends a lot of F7’s within a dump coz the MU80 dump have a lot of single dump-sequences …
that’s all …
ok Martinal … first the im/export … than the additional stuff for MIDI-files
just some words from little me:
I realy, realy need sysex-import/export in a future version The possibility to save several sysex-banks in one song that can be transmited on song-load. In this way you can store all synth-sounds and adjustment in the song (in the similar way you can store VST-adjustments today)… today you have to store and load all this by using another program, and store them in a separate file, and that is alittle longwinded
i checked ModPlugTracker midi-import and i see that it can reproduce length of pattern (I’ve exported some MED songs as midi …) … can’t understand this? midi-files includes pattern-lenght-information!!! is this possible???
if not - maybe it’s possible to include a intelligent midi-import-function - maybe this way: the importer checks the notes and positions in the song and if a big part of notes repeats on another position a new pattern will created?! is this possible?!!?!?!?! only an idea?!
I think there is some sort of marker message you can write to the file. This could be written between patterns when exporting, and used as pattern change marks when importing eventually. If you’re talking about exporting and then importing again a midifile in the same program it might write some sysex messages that only the program itself will interpret.
I won’t bother with pattern matching. Everything is possible, but it’s too complicated compared to the gain. An I don’t have a clue as to how it can be done efficitently
Some of my (6 years old!) sourcecodes are bad coded, the sysex messages are hardcoded, was for General MIDI only and are in Pascal. But there’s maybe some usefull stuff that may help, like sysex-checksum. It took me weeks to find out that documentation. But its very simple.
I would gladly help Martinal so that we can see sysex support in the near future, but I think he knows more about MIDI than I.
And what do you mean by “that documentation”? Checksums are calculated differently by different companies, so it’s not just one algorithm… Making a good sysex handling implementation capable of handling all synths from only the few biggest companies will not be an easy task. But a “dumb” sysex-reciever/storer/sender which doesn’t try to interpret the sysex data is another thing and might not be a big deal.
Anyway, this is not something that will happen very soon. Not until after the release of 1.3, and even then only after reviewing the WIP votes.