LMMS
MIDI import seems to loose tracks
I downloaded this midi: http://www.mediafire.com/download/pzdoigxv83bhiyr/Replacer+-+Song+for+an+Earth+Pony.mid and imported it into LMMS. It seemed to play fine (albeit with the drums playing as piano) on windows media player. However on LMMS it seems to be missing several tracks, which seem to not have been imported. I've tried importing other MIDI's, which all work, so I'm not sure why this midi doesn't import correctly. I'm using LMMS 1.0.2 on windows 7
EDIT: Link to the file via GitHub itself: Replacer - Song for an Earth Pony.zip
It plays perfectly in WMP, so I'm not sure why it doesn't import to LMMS correctly.
Lose instrument tracks or automation tracks? LMMS doesn't support newest MIDI files, but it should load all instruments, I think.
I think all the automation tracks are there but I can't tell. I'm not sure if any instruments are missing, as it's mostly squished onto one track, but there is a considerable amount of the song missing. Why doesn't LMMS support newer MIDI's?
Why doesn't LMMS support newer MIDI's?
AND all vsts AND import of new FLP AND export of midi A.. :dango: Becouze noone has implemented it , yet (sorry:) But i have heard of this midi-instrument problem before. It looked like the problem with the file was that the notes in the track was 'weird' -had some kind of properti that was not processed... How many different midi formats actually exists? I believe even some properitary formats uses the term 'midi'
I'll mark this as bug but I don't think there's much that can be done beyond that as of right now... someone's going to have to look at the midi import stuff at some point, but honestly I have no idea when that's going to be.
~~aplaymidi on my system says:
Replacer - Song for an Earth Pony.mid: invalid MIDI data (offset 0x9003)
and doesn't play one single note. So, it might very well be a broken file.~~
Looks like there was some slight hiccup in downloading, I tried again and it's actually "fine", as in "not broken". Looks like it's not a very nicely made MIDI file, though. 28 tracks, but everything on channels 1-3, and not one program change, so everything is a piano?
...but looking a bit deeper, there's room to improve the MIDI import. As of now, it looks like LMMS splits a MIDI file into tracks by channel, which is a perfectly valid strategy, but maybe not the best for all files. There are three dimensions in play here:
- Tracks, a MIDI file can contain an "unlimited" number of them.
- Channels, a track can contain events for several channels and a channel can be used in more than one track.
- Programs, i.e. instrument sounds, which can change on a channel at any time, and there's only one program in effect on the channel at any given time.
There are use cases for all kinds of splits: The file at hand now would've been handled better by splitting on tracks, and importing a file with a lot of program changes to be used with some other plugin than the SF2 player could benefit from a split on channel and program. (program changes are now handled through automation on the patch and bank dials in the SF2 player, if my reading of the code is correct)
@softrabbit was this issue fixed by your recent improvements of MIDI importing?
was this issue fixed by your recent improvements of MIDI importing?
@Umcaruje in win32x yes! -eg this & 2033 and related can be marked ok for win32x Closing is to early, because the other OS's need to be confirmed too -right?
There shouldn't be much OS dependent code in the MIDI import, but it never hurts to confirm on as many systems as possible.
And as for this particular problem file, I won't say anything. Very short notes were dropped previously, now they are imported. Maybe that's why "several tracks" were missing.
@softrabbit Agreed. I experienced the problem of missing tracks containing very short notes - especially drums tracks - for a long time. With the Midi import fix, the problem has been solved. I use Midi Import a lot with Midi type 0 and 1 for re-orchestration on files from various sources and never noticed a missing track since then so, I assume the problem is solved.
@PhysSong If you look at the midi-import fails, then one more fail need to be mentioned #4728 Eg LMMS cant import MIDI-files made by LMMS midi-export
There has been quite some MIDI related PRs by @Veratil in between. Is there a chance this got fixed in master?
Adding the MIDI file from the original description here so that it does not get lost: Replacer - Song for an Earth Pony.zip.
There has been quite some MIDI related PRs by @Veratil in between. Is there a chance this got fixed in master?
Unfortunately this is not fixed. REAPER import 27 tracks while LMMS from master only imports 3 instrument tracks and 3 automation tracks. Lots of tracks are missing.
Here's a screenshot of REAPER's import:
And here's LMMS' import:
For anyone interested in looking at this: set break points in MidiImport::readSMF and then import the attached file.
LMMS isn't failing to import anything here actually. The way LMMS loads a MIDI currently is that a track is a MIDI channel. Everything is loaded into the kontakt drums track since every MIDI track is set to channel 0 except for two it looks like.
It sucks, I know. 😞
Also, portsmf isn't the most active project out there but it has moved along a bit since it was added into lmms https://github.com/rbdannenberg/portsmf
Maybe it would be an idea to look into upgrading or submoduling it?
I have a complete rewrite of MIDI import working on a local branch, removes our need for portsmf or any external library. It can also load "invalid" MIDIs by ignoring some error points which I know my MIDI editor I use to test can't (and I think portsmf doesn't, I forget honestly).
Sounds good! Does it also create individual tracks instead of merging the information?
Sounds good! Does it also create individual tracks instead of merging the information?
It will load by channel, but we can change that to per track very easily. The reason I haven't created a draft PR yet is because I'm still working out the control channels, which I'm kind of stuck on trying to figure out the best way to do it. Also I'm not 100% certain where I want to organize the files to.
It will load by channel, but we can change that to per track very easily.
IMO the chance should be used to also fix this issue.
The reason I haven't created a draft PR yet is because I'm still working out the control channels, which I'm kind of stuck on trying to figure out the best way to do it.
Is it because LMMS' MidiClips do not seem to store this information?
Also I'm not 100% certain where I want to organize the files to.
Sound like something that should go into the core. The current implementation is a plugin which is kind of strange for a DAW that mainly deals with MIDI and audio.
It will load by channel, but we can change that to per track very easily.
IMO the chance should be used to also fix this issue.
That sounds fine to me, I'll work on changing it to be track based instead.
The reason I haven't created a draft PR yet is because I'm still working out the control channels, which I'm kind of stuck on trying to figure out the best way to do it.
Is it because LMMS'
MidiClips do not seem to store this information?
Yes and no, it's mainly there's not a good 1:1 correlation to MIDI CCs and LMMS stuff. At least not clear ones. Either way, discussion on that doesn't belong in this issue. 😁
Also I'm not 100% certain where I want to organize the files to.
Sound like something that should go into the core. The current implementation is a plugin which is kind of strange for a DAW that mainly deals with MIDI and audio.
Oh it's in core, I'm mainly meaning all the gears of the MIDI classes. 🙂
The reason I haven't created a draft PR yet is because I'm still working out the control channels, which I'm kind of stuck on trying to figure out the best way to do it.
Is it because LMMS'
MidiClips do not seem to store this information?Yes and no, it's mainly there's not a good 1:1 correlation to MIDI CCs and LMMS stuff. At least not clear ones. Either way, discussion on that doesn't belong in this issue. 😁
Sorry, I don't know where to discuss it elsewhere so I continue here. :wink: I think ideally LMMS should retain all the information in the MIDI clips and push it into the plugins via their APIs when the song is being played. However, if I understand correctly, one of the problems is that LMMS does not even itself have an API that's similar to VST, CLAP, etc. Which also seems to be the reason why it is hard to integrate third party plugins like they are integrated in other DAWs.
So it might be a good first step to retain all information in the MIDI clips and then to check later what to do with it.
Also I'm not 100% certain where I want to organize the files to.
Sound like something that should go into the core. The current implementation is a plugin which is kind of strange for a DAW that mainly deals with MIDI and audio.
Oh it's in core, I'm mainly meaning all the gears of the MIDI classes. 🙂
Can't you organize it under src/core/midi/ with the other stuff?