after often wondering why some notes in tracktion won't be played and why export doesn't work as expected, and....blablabla mentioned often enough,
i have had a look at the midifiles tracktion generates on export with a smal tool called midi2hex.
it shows me that what tracktion does while editing midi is a total desaster!! sometimes the same note is triggered 5 times at a time. or a midioff accures at the same time with a midi on or writes a total unknown midicommand (FD). now i know why heavy midiprocessing sometimes brings the cpu to it's knees. i think it's a littlebit unfair to pay for T2 just to have a normal working midi handling.
why pay for bad midi in T1
-
- KVRAF
- 25015 posts since 12 Jul, 2003 from West Caprazumia
a lot of things Tracktion does are catastrophes 
- I'm glad that finally someone else than me notices/mentions that Tracktion's cpu-consumption is sometimes strangely high. (usually everyone pretends it's rather low)
- I'm glad that finally someone else than me notices/mentions that Tracktion's cpu-consumption is sometimes strangely high. (usually everyone pretends it's rather low)
-
- KVRist
- 47 posts since 19 May, 2004 from Muenchen
@aldi: I recommend that you have a look at one of those many tools available that do not look at a midi file, but which monitor a direct midi input. This will enable you to see what your midi input device is feeding into Tracktion before recording and editing start. I can assure you that you will be surprised!
You will probably see lots of strange sysex messages, for a start, and don't expect them all to be terminated properly (this is probably where your FD comes from). You might also see funny things like a note on with value 0 and a real note off message following each other. You will probably not see all 127 possible velocities, no matter how hard you try (due to the latter issue, I even wrote my own little graphic midi monitor before going shopping for a new master keyboard). And so on...
Bottom line: You should check the input going to Tracktion, and compare it with the output. If you find an inconsistency, it is a good idea to write a bug report to Jules, containing steps to reproduce the problem (the 5-time triggering of the same note which you mentioned might be such an issue). Just looking at the final result is not enough if you want to blame a single component within the chain.
Myself, I haven't noticed any midi bugs in the current Tracktion version.
malamut
You will probably see lots of strange sysex messages, for a start, and don't expect them all to be terminated properly (this is probably where your FD comes from). You might also see funny things like a note on with value 0 and a real note off message following each other. You will probably not see all 127 possible velocities, no matter how hard you try (due to the latter issue, I even wrote my own little graphic midi monitor before going shopping for a new master keyboard). And so on...
Bottom line: You should check the input going to Tracktion, and compare it with the output. If you find an inconsistency, it is a good idea to write a bug report to Jules, containing steps to reproduce the problem (the 5-time triggering of the same note which you mentioned might be such an issue). Just looking at the final result is not enough if you want to blame a single component within the chain.
Myself, I haven't noticed any midi bugs in the current Tracktion version.
malamut
-
- KVRAF
- 1974 posts since 21 Jun, 2002 from Earth
I took an old T project... exported some midi files, then loaded 'em up in a hexeditor. Here is what I've found thus far. To my knowledge, FD is not a spec midi command. F0 and F7 are sysex commands, and FF are meta events. (edit: FD occurs in single or multiple tracks on export)
Results..
(1) when reimporting the single exported track.. everything is fine... everything looks as it should be... (edit: they still have the fd stuff)
(2) when reimporting the file that was composed from multiple tracks, the midi file is wrong. It imports as a single midi file... but the notes are wrong in certain places, and that fd thing occurs in mid2hex (however, fd might be a thing jules uses??? the spec is s'posed to ignore unknown commands.. so I dunno).
From this I gather that midi export has a bug when exporting multiple tracks to a single midi file. when exporting a single track it seems to work as it should (I didn't test sysex stuff or loads of cc data).
so I'm kinda curious, were you exporting single tracks (as in the checkbox marked for render selected tracks), or were you rendering multiple tracks?
In any case, I think it's kinda premature to conclude that this is the reason for consuming processor with midi heavy projects... an export bug doesn't necessarily have anything to do with playback issues. In stepchild... it can playback notes that extend beyond a 1/16th.. but it can only render notes in 1/16th's on export. I'm using this as a example of how the playback and actual export can have little to do with each other. To me it sounds like you've found a export bug.
BTW, I don't have cpu issues like what is being described... but then again, I guess I'm just "pretending"...
afterall I'm 10 minutes from hollywood so I like being fake. 
Results..
(1) when reimporting the single exported track.. everything is fine... everything looks as it should be... (edit: they still have the fd stuff)
(2) when reimporting the file that was composed from multiple tracks, the midi file is wrong. It imports as a single midi file... but the notes are wrong in certain places, and that fd thing occurs in mid2hex (however, fd might be a thing jules uses??? the spec is s'posed to ignore unknown commands.. so I dunno).
From this I gather that midi export has a bug when exporting multiple tracks to a single midi file. when exporting a single track it seems to work as it should (I didn't test sysex stuff or loads of cc data).
so I'm kinda curious, were you exporting single tracks (as in the checkbox marked for render selected tracks), or were you rendering multiple tracks?
In any case, I think it's kinda premature to conclude that this is the reason for consuming processor with midi heavy projects... an export bug doesn't necessarily have anything to do with playback issues. In stepchild... it can playback notes that extend beyond a 1/16th.. but it can only render notes in 1/16th's on export. I'm using this as a example of how the playback and actual export can have little to do with each other. To me it sounds like you've found a export bug.
BTW, I don't have cpu issues like what is being described... but then again, I guess I'm just "pretending"...
afterall I'm 10 minutes from hollywood so I like being fake.
Last edited by ModuLR on Sun Aug 01, 2004 6:48 pm, edited 1 time in total.
ModuLR / Radio
-
- KVRist
- 47 posts since 19 May, 2004 from Muenchen
I have never exported multiple tracks into a single midi file, so that might explain why I never had any midi problems.
As for the processor load: I think that aldi's '5 notes at a time' problem is a good candidate for that. If you let your soft synths play each note 5 or 10 times, they will of course eat up your CPU.
I have never had any CPU load problems with Tracktion myself.
malamut
As for the processor load: I think that aldi's '5 notes at a time' problem is a good candidate for that. If you let your soft synths play each note 5 or 10 times, they will of course eat up your CPU.
I have never had any CPU load problems with Tracktion myself.
malamut
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Why pay for working MIDI?
I say you shouldn't. But that's just one man's opinion. Without any changes to the editor itself, any bug-fixes should be taken care of and a final release of T1 made.
As for me, I rarely use MIDI in the first place, so what I've actually paid for (and received in droves) is quality and easy audio multitracking.
Greg
I say you shouldn't. But that's just one man's opinion. Without any changes to the editor itself, any bug-fixes should be taken care of and a final release of T1 made.
As for me, I rarely use MIDI in the first place, so what I've actually paid for (and received in droves) is quality and easy audio multitracking.
Greg
-
- KVRAF
- 1974 posts since 21 Jun, 2002 from Earth
yeah, but one would think that if it was truely playing back 5 notes at once... it would be extremely loud or simply *very* obvious that something is wrong. Not that your cpu just happens to seem a bit higher... it just doesn't add up...malamut wrote:As for the processor load: I think that aldi's '5 notes at a time' problem is a good candidate for that. If you let your soft synths play each note 5 or 10 times, they will of course eat up your CPU.
ModuLR / Radio
-
- KVRian
- Topic Starter
- 830 posts since 13 Oct, 2003
hmm, could be only an export problem, but i bet it's also somewhere in the midiplayback because i get these cpu peaks at the specific times.
i wrote a little tool today that cleansup every midifile. it just lefts the note on and offs, removes doubletriggered noteons and removes overlapping, also it adds noteoffs to hanging notes (notes without noteoff).
the installer adds an entry to your rightklick SENDTO menu. you can use it (if you like) on multiple files at once. IT DOESEN'T OVERWRITE YOUR FILES, it simply adds the cleaned files to the same directory. if the sourcefile was a multiple track file the resulting is ONE Track. i use it for some drum midifiles or messedup midifiles. you can download it here. because it also removes the TEMPO information, there won't be a new tempo if you import the midifiles zo tracktion
http://www.aldi.privat.t-online.de/truncmidi.exe
i wrote a little tool today that cleansup every midifile. it just lefts the note on and offs, removes doubletriggered noteons and removes overlapping, also it adds noteoffs to hanging notes (notes without noteoff).
the installer adds an entry to your rightklick SENDTO menu. you can use it (if you like) on multiple files at once. IT DOESEN'T OVERWRITE YOUR FILES, it simply adds the cleaned files to the same directory. if the sourcefile was a multiple track file the resulting is ONE Track. i use it for some drum midifiles or messedup midifiles. you can download it here. because it also removes the TEMPO information, there won't be a new tempo if you import the midifiles zo tracktion
http://www.aldi.privat.t-online.de/truncmidi.exe
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Which isn't so bad, because you're usually aware of the tempo of your own songs!
Thanks for the tool.
Greg
Thanks for the tool.
Greg
thanks!-
- KVRian
- 696 posts since 21 Nov, 2000 from somewhere over the rainbow
Is aldi corrupt? Never realized that...rpc9943 wrote:So is this information accurate? Is the midi editor really corrupt, or is it just aldi?
RonC
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
I don't think I would use the word "corrupt". I've been using it quite a lot lately, and although there have been a few "quirks" along the way, it's still been usable.
Doesn't mean I'm not looking forward to the update.
Greg
Doesn't mean I'm not looking forward to the update.
Greg