A technical support community for Apple Logic Pro users.

 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sat Apr 24, 2021 1:04 pm

as to a general solution to this bug or design flaw...how can you work around it? If it were me, and I knew that one DAW was occasionally going to insert several tempo events on the same midi tick during export, I would write a script that can filter them out using the midicsv tool. It would be a pretty easy little script with awk, perl, python, or pick your favorite..that would detect those and just let the last one through...then convert it back to a real midifile using csvmidi. The resulting midifile would be santized of the non-sensical scenario and then LogicPro should import it fine.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sat Apr 24, 2021 2:28 pm

and yea the more I think about it, the actual internal timestamp that midi files use are so called "delta times", which means each item has a time showing the amount of time since the previous event. In other words...midifiles by definition are in order, and the order is deterministic that way.

So I have to say, this is a quirk of LogicPro, where it inserts imported midi into its own internal event list structure in some way where the order isn't taken into consideration, only the timestamp.

Note that not all DAW's consider it universally important to respect the order of midi events within a single tick. LogicPro, for example, doesn't really let you re-order events in the event list, without changing their timestamp. If you put several events on the same timestamp, there is no way to specify what exact order to play those events. The assumption is that the timestamp itself is the finest level of granularity and so it will play them in whatever order it feels like. They are most likely stored in some particular order, and played in the order they are stored....we just don't have any ability to control what order that is

LogicPro is not alone in that. Cubase and other DAW's also do not really provide a way to change the order that events in their event list will play, when they are on the same timestamp.

The interesting thing is that if you record a midi stream to a region...in LogicPro for sure, but probably in other DAW's also, then it will record the events in exactly the order they came in...even if somehow they came in on the same timestamp! They are actually stored in eternally sample accurately..using a much higher precision then the PPQN. The PPQN is just generally for the pianoroll, event list editor and other things to present a more useful grid for us to use while editing things, but internally, they are timestamped with much finer granularity.

So you can determine the exact order within a single timestamp by how they are actually stored. But still, Apple and other devs aren't really officially recognizing that ordering..its just a convenient fact of midi being serial that they were stored in the desired order within a single timestamp.

In LogicPro it is definitely possible to effect the play order when midi Plugins are used. When we make a script that inserts a keyswitch in front of a note...on the same timestamp...then that ordering is respected by the AU framework and the events happen in the specified order...within the same timestamp. ArticulationSet's also are able to insert keyswitches dynamically as the notes are playback...in the same timestamp and in the desired order. So clearly..the ordering can be relevant....like in the case for keyswitching for example.... and the midi stream being a serial protocol that it is...that ordering can be necessary at times.

Unfortunately many DAW's happen to ignore this fact in certain areas like how we are allowed to effect the way they are stored in the internal event list structure. They don't provide any way for us to set or adjust that order. We can only adjust the PPQN timestamp of each note if we want to change the order. Ordering within a single timestamp...is not really acknowledged officially as significant or desirable, and no way provided to do so other then dynamically during playback. Whatever order the events are stored internally..that's the order they will be played back from the sequencer.

So anyway, getting back to the topic...when LogicPro imports midifiles it appears to be ignoring that order within a midifile timestamp. It assumes that order doesn't matter, and just inserts those three tempo changes into the event list in a non-deterministic order..but using the same timestamp. Whatever order they get stored, that's the order they get played back. Which may or may not match the order they were in the midifile.

And I would argue that a midifile does have an inference that the order in the midifile matters since it uses a system based on delta times, not absolute timestamps. So I would definitely call this a design flaw in LogicPro.

This caused a problem where when Cubase exported nonsensically, three tempo changes on a single timestamp.

But there could be other scenarios that are perfectly sensical which this problem would also come up. Let's say you had a midifile with notes and keyswitches...and the keyswitches are intentionally placed on the same timestamp as the note they are switching....in the correct order so that they will do what they need to do. We can do that with Scripter during playback...so why not in a midifile? its a serial protocol. However, according to what we are finding here, LogicPro will import those events in a non-deterministic order..which means..in some cases the notes would end up being stored in the event list in the incorrect order...note first, keyswitch second....

In the case of the non-sensical tempo events....you have no guarantee which one will be the last one after its imported...and the last one wins. In my view LogicPro should respect midifile ordering, including when several events are on the same timestamp. That appears what some other DAW imports are doing.

Good luck getting Apple to fix this though...
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
User avatar
tusitala
Topic Author
Posts: 126
Joined: Tue Aug 04, 2009 6:52 pm

Re: MIDI file opened in Logic is different (wrong) than other programs

Sat Apr 24, 2021 4:09 pm

Dewdman42 wrote:

You can also try dragging the midifile onto the logicpro app icon which will create a brand new project while importing the midi and that is more likely to be a more pure result from the midifile


That's what I've done actually. Right click the midi file itself and "Open with Logic"
Mac Pro 2013 6-core
64 GB ram
Motu M4
OSX 10.15.7
Logic Pro 10.6.1
 
User avatar
tusitala
Topic Author
Posts: 126
Joined: Tue Aug 04, 2009 6:52 pm

Re: MIDI file opened in Logic is different (wrong) than other programs

Sat Apr 24, 2021 4:10 pm

Dewdman42 wrote:

You can also try dragging the midifile onto the logicpro app icon which will create a brand new project while importing the midi and that is more likely to be a more pure result from the midifile


That's what I've done actually. Right click the midi file itself and "Open with Logic"
Mac Pro 2013 6-core
64 GB ram
Motu M4
OSX 10.15.7
Logic Pro 10.6.1
 
ValliSoftware
Posts: 1008
Joined: Mon May 19, 2014 10:46 am

Re: MIDI file opened in Logic is different (wrong) than other programs

Sat Apr 24, 2021 4:14 pm

tusitala wrote:
Of course, and I agree.
I reported this because it's a fairly serious issue as it can really mess up a project and create headaches, especially if the tempo difference is less noticeable that 114 to 120.
Since other DAWs can interpret the file correctly I imagined this was a Logic bug that might get fixed in the future

Can you file it as a bug with Sibelius Ultimate.
If it's not a bug with Sibelius Ultimate they'll give you a technical reason why the have 3 MIDI events and why 120 was stuck in the middle with all 3 having the same timestamp.
If they can't give you a technical reason, they'll let you know it's a bug.
MacBook Pro 10.8.5 2.2 GHz Intel Core 2 Duo 6GB Ram - Logic Pro X (10.2)
MacMini 10.13.6 2GHz Intel Core i7 16GB Ram - GarageBand 10.4.5 Logic Pro X (10.4.8)
iPad Mini iOS 12 - iOS GarageBand 2.0.1
Qosimo X70-A 10.13.6 Intel® Core™ i7-4700MQ Processor 32GB DDR3L 1600MHz memory, 2-500GB 7200rpm hard drives - Logic Pro X (10.4.8)
MacMini M1 11.4 Apple M1 16GB Ram 1TB SSD Logic Pro X (10.6.2) Rosetta 2 not installed
 
gacki
Posts: 173
Joined: Fri Jul 17, 2020 3:18 am

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 1:08 am

Let's go down that rabbit hole even a bit deeper. I completely agree with your analysis.

Dewdman42 wrote:
So you can determine the exact order within a single timestamp by how they are actually stored. But still, Apple and other devs aren't really officially recognizing that ordering..its just a convenient fact of midi being serial that they were stored in the desired order within a single timestamp.


MIDI is being serial; however the tempo changes in the MIDI file are not (at least not in the same sense): They are information for the software playing the MIDI file - but they are not transmitted over MIDI itself. Of course the fact that everything else is serial would imply to treat them as serial as well; and I agree that the current way to handle this is akin to a design flaw or an oversight.

I can recall that back in the day it was almost a science how MIDI data gets prioritized to improve timing and so on. When having multiple commands on the same timestamp - what gets sent first? Usually note events were prioritized over controllers and program changes were prioritized over note events (this makes sense: when a program change and a note appear at the same time it's safe to assume the note should use the "new" sound - but it's bad practice anyway since the receiving device probably would need time to change the sound). On the other hand: Ctrl. #7 going down from 127 to 10 immediately after the note was played is also not a good idea so maybe this should get sent before the note, too. When having notes on multiple channels on different tracks: Which one gets prioritized? Top to bottom in the track layout? Top to bottom channel-wise? Or Channel #10 first (because drums are very timing-critical)?
I have a very foggy memory of having read a test report on this but I might be wrong.

Perhaps the behavior in Logic is a remnant of this past. But I also think it should be fixed.

In the meantime I re-checked with Finale and it actually imports all the tempo data; playback is correct (with 114 from that point onward). So we can add this to the list of programs that treat the tempo list in a linear fashion.
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 1:29 am

gacki wrote:
MIDI is being serial; however the tempo changes in the MIDI file are not (at least not in the same sense): They are information for the software playing the MIDI file - but they are not transmitted over MIDI itself. Of course the fact that everything else is serial would imply to treat them as serial as well; and I agree that the current way to handle this is akin to a design flaw or an oversight.


Regardless of the fact that no midi cable is being used, the protocol is still serial in nature. That is why, for example, VST and AU plugins process midi events in a "queue" which is serial in nature. A midi cable, or a midi queue, will have midi events only one at a time...in some order. Even LogicPro has an event list...which is a serialized list of midi events...and they will play in that order too! You just can't rearrange the order of two events in the event list if they have the same time stamp, LogicPro doesn't provide a way to do so.

Doesn't matter if you have 10 events in a row with the same timestamp, they are still processed one event at a time, in the order they are presented in the midi stream or queue...(or midi cable). that is not always how all software chooses to process the queue, but they usually cause problems for someone when they don't, because of the assumption about it being a serial queue. There are lots of computer processes that are serial in nature. How files are read and written, for example. Etc, etc. etc. Midi is no exception. If they make assumptions that they can ignore the order established by a sender, then they break the sender's intention.

I can recall that back in the day it was almost a science how MIDI data gets prioritized to improve timing and so on. When having multiple commands on the same timestamp - what gets sent first? Usually note events were prioritized over controllers and program changes were prioritized over note events


really are you sure about that? I don't think so. Especially back in the day. It could be that some merging boxes or something may have prioritized notes over CC's while merging, but once merged...serial protocol....one after the other in the order they come.

Now, how various software programs have decided to handle events on the same timestamp..that is another matter in many situations, but what I can say is that midi cables, midi interfaces, midi drivers...midi buffers...midi queues...VST/AU....they all process midi in a serial stream. Per this thread....midifiles are also serialized using delta times. They don't contain absolute timestamps. They are fundamentally serial in nature.

If some app chooses to ignore that ordering, then they will have problems like LogicPro is having now with this particular midi file...while some of the other apps aren't having a problem with it because they are respecting the serial ordering.

(this makes sense: when a program change and a note appear at the same time it's safe to assume the note should use the "new" sound - but it's bad practice anyway since the receiving device probably would need time to change the sound). On the other hand: Ctrl. #7 going down from 127 to 10 immediately after the note was played is also not a good idea so maybe this should get sent before the note, too. When having notes on multiple channels on different tracks: Which one gets prioritized? Top to bottom in the track layout? Top to bottom channel-wise? Or Channel #10 first (because drums are very timing-critical)?


All that you are describing has always been the responsibility of musicians to ensure that we put the events in the order we want them to be.

Perhaps the behavior in Logic is a remnant of this past. But I also think it should be fixed.


Steinberg has also been ignoring the serial nature of midi, Apple is not alone in this. The VST3 spec, for example, does not respect midi ordering at all...and is actually very unsuitable for certain types of midi plugins. Their response is that VST is not meant to be for midi...they don't care about it and don't want to acknowledge it, but I can tell you that on the VST dev forums there are plenty of people begging them to respect midi ordering, but they don't care...people have been complaining about it for 10 years, they don't care.

Kontakt also has a problem here. For example if you use CC switches to drive an instrument in kontakt...and if you have, say, a chord with different articulations on different notes of the chord...all on the same timestamp. Guess what happens? First, kontakt processes all the CC's before processing any of the notes..then it processes the notes. But in that case only the last CC is seen by the instrument. For example if you you needed CC58=1 for the articulation of the bottom note, and CC58=2 for the top note of the chord... which ever CC58 that was the last one, ends up being the articulation played by both notes.

Numerous people doing that kind of music will have various problems using Cubase Expression maps and LogicPro articulation sets when they try to use CC switches with Kontakt...often times they can't figure out what is going on and just complain that its all broken, but I can tell you the main problem is that Kontakt chooses to process all the CC's within a process block (which is actually much more then one timestamp, its a time range representing your audio buffer size). So all the CC's within that audio buffer span are processed before processing notes...and there are numerous situations where this failure to recognize the serial order of midi events that was sent to it, results in erroneous results and confusion to the musician.

VST3 has similar problems related to non-note events also, as those events are not passed to the plugin as a serial buffer, as was the case with VST2, AU, etc..
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
gacki
Posts: 173
Joined: Fri Jul 17, 2020 3:18 am

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 4:24 am

We are hitting here on one of the main problems (and differences) of MIDI and MIDI files.
MIDI connections are by design serial. Computers and MIDI files are not. A computer and a MIDI file can have dozens of events on the same timestamp. Those have to be sent via MIDI in a serial fashion; and that's where worlds collide and where prioritizing has to start.
Take a very simple example: a four-note chord, hard quantization. How is it sent? Top to bottom? Bottom to top? Random? Probably not the latter because we want repeatability. So the software will have to make decisions how to treat (send) data that occurs on the same timestamp.
Yes, ideally you would delegate the responsibility to handle the order to the user. But let's be real here (and again: think of the four-note chord). People will usually not use the PPQ resolution of the sequencer to make their own decision in which order the chord notes are played. But there will be an order; and this order will be sequencer-specific.

Let's stick with the above four-note chord example on a single channel. If you create such a four note chord in Logic it will be played bottom to top - but the Note Off events will come top to bottom.
The exported MIDI file has the Note On commands on the same timestamp bottom to top and the Note Off commands on the same timestamp bottom to top.

Ableton Live sends the Note Ons bottom to top and the Note Offs also bottom to top.

Let's re-import the MIDI file into Logic: Same behavior as originally. So this seems to be like a very specific decision how to handle Note Offs on the same timestamp.

Cubase Elements 10: bottom to top and bottom to top.

Sibelius 6: bottom to top and bottom to top. However the (real) Note Off commands have been changed into Note On with velocity 0 instead.

Finale 2012: bottom to top and bottom to top. However the (real) Note Off commands have been changed into Note On with velocity 0 instead.

Now let's spice up things a bit. We take the original situation and add another MIDI track on channel 10 with 2 notes.

Logic output: Note on on Channel 1, 10, 1, 10, 1, 1 (bottom to top) , Note Off on Channel 1, 1, 1, 10, 1, 10, top to bottom.

Switching the order of the tracks changes this to Note On 10, 1, 10, 1, 1, 1 and the Note Offs accordingly.

What's clearly visible is that we (probably) have a top-to-bottom situation with the tracks and within those a round-robin situation for different channels; and within the channels a bottom-to-top order for Note On.

I'm exporting both versions as MIDI file; both ARE different. Re-importing them into Logic puts the tracks in the order they were exported.

Cubase Elements 10 imports both versions in the right order; the topmost track is always played first after import. This order is interestingly kept when swapping the tracks.

Ableton Live 10 behaves strangely. Tracks get imported in the right order but then things get weird. MIDI channels are lost and have to be re-assigned. I can't make sense on how tracks are prioritized here. Example: upper track is channel 1, lower track is channel 10. Channel 10 gets sent first. I swap both tracks: channel 10 gets still sent first.
Now for the weird part: If I set the channel INPUT for either tracks to a different value: Channel 1 gets sent first.

I think even this short and really unscientific test shows what a can of worms we open when we have multiple MIDI events on the same timestamp (either in a sequencer or in a MIDI file). Obviously developers have different ideas how to tackle this problem (as have users). I can recall that it was common to put MIDI drum tracks at the top of the track list (because obviously some sequencers work top-down) to improve their timing.
Logic seems to take a somewhat "democratic" approach here by cycling through all tracks. Obviously there are advantages and drawbacks to this, too.
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 10:39 am

No you are still missing it. Midi is processed one note at a time, even in logicpro. In whatever order the events are stored in a buffer. That is serial! But the event list editor doesn’t provide low enough granularity to allow us to set or change that order within the confines of a single PPQN tick. And it’s midifile importer also is too stupid to maintain the same order while inserting the events, but once they are inserted in whatever order they are inserted, logicpro does play them back in that order, because it is a serial protocol!!!

One idea I have for a midifile sanitizer is to take the midifile, multiply the PPQN in the midifile by say, four. Then do the same to all the delta times except when it encounters non note events on the same delta time then bump each repeated delta time by 1. Basically you’d end up with a midifile that has a PPQN of several thousand instead of 480 or 960. Then the events would be stored Internally in logicpro in the correct order and when viewed in logicpro at 960 they would appear to be in the same midi tick and order maintained. Maybe I’ll try to whip together a python script for this, I have some other midifile sanitizer tasks I would like to address also

I have already done experiments and found that PPQN can go very high over 30,000 and logicpro will read it and understand it. There is an exact number which I will find out later at my desk. But that is one midi tick per 2 samples or less worth of resolution. I guess 960 can’t be multiplied by 4, only three but it should still work. A midifile at 480, which is actually more common, could easily be multiplied by four or more. Anyway I will probably try to script this eventually as tempo map import is important to me also.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 12:12 pm

quick follow up, max PPQN allowable in midifile is 32,767

That comes from the fact that any value in hex 0x8000 and above is considered a SMPTE frame rate based timing rather then beat clock based, but nobody really supports that mode anyway, another topic. But bottom line the midifile spec can handle PPQN up to 32,767 ticks per quarter note. I have tested this by the way and successfully imported midi files into LogicPro with PPQN set that high in the midifile. The import seemed to work, though I haven't ever actually looked closely to make sure the values were respected.

At 120BPM, that resolution is higher then the sample rate, by the way.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
gacki
Posts: 173
Joined: Fri Jul 17, 2020 3:18 am

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 12:19 pm

Dewdman42 wrote:
No you are still missing it.


I doubt you're qualified to judge that.

I've shown above that different applications interpret identical data (from a Standard MIDI file) differently as far as prioritizing goes. This (probably and hopefully) has something to do with different philosophies and approaches on how to prioritize data.
You can't have events with delta time zero in a MIDI connection but you definitely can and will have them in a MIDI file or in a sequencer application. The order in which events on the same timestamp appear can be the order in which the original application plays them - or sometimes not. Again, see my examples; or here's another one:

Logic gives (on the same timestamp) Program Changes a higher priority than Controllers - except Controller 0 and 32 (naturally). When exporting this as a MIDI file it's written in that "order" on the same delta time.
Cubase plays it back in exactly that order (except the track prioritizing).
Ableton plays back first the Controllers (except 0), then Controller 0 (and adds a Controller 32 that is not in the MIDI file), then the Program Change.

Down into madness: Ableton 10 then exports this as a MIDI file starting with the Program Change, followed by the Bank select (this time without the additional Ctr. 32) and the other controllers. Is this stupid? It sure is. But then Ableton isn't able (heh, heh!) to import a MIDI file that contains no notes; so for example taking a tempo map from Finale won't work anyway.

Cubase plays back this MIDI file exactly as Ableton exported it, with Bank select AFTER the Program Change? Good idea? No.

Logic on the other hand quietly reorders the data into the Logic hierarchy: first Bank Select, then Program Change, then the other Controllers. It's not the order in which Ableton exported it but it certainly makes more sense.

Usually the order will have some meaning (like in the example that started this thread); and the safest approach would probably be to maintain that order in most cases - no argument there. But that applications will sometimes re-order events that appear on the same timestamp (or simply impose their own order) is a fact; and in some cases they will have good reason for this.
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 12:26 pm

If and when LogicPro or any other DAW reorders any midi events anywhere in an order different then that provided by the musician, then it is fundamentally breaking expected behavior of midi. Sorry you are just wrong. Especially when it comes to instrument plugins...they are processing midi buffers in serial order. This is becoming a stupid conversation. Have a nice day.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
gacki
Posts: 173
Joined: Fri Jul 17, 2020 3:18 am

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 12:30 pm

Dewdman42 wrote:
This is becoming a stupid conversation.


No argument here.
 
User avatar
tusitala
Topic Author
Posts: 126
Joined: Tue Aug 04, 2009 6:52 pm

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 3:26 pm

ValliSoftware wrote:
tusitala wrote:
Of course, and I agree.
I reported this because it's a fairly serious issue as it can really mess up a project and create headaches, especially if the tempo difference is less noticeable that 114 to 120.
Since other DAWs can interpret the file correctly I imagined this was a Logic bug that might get fixed in the future

Can you file it as a bug with Sibelius Ultimate.
If it's not a bug with Sibelius Ultimate they'll give you a technical reason why the have 3 MIDI events and why 120 was stuck in the middle with all 3 having the same timestamp.
If they can't give you a technical reason, they'll let you know it's a bug.


I could but I imagine it would be very unlikely that they treated it as a bug since other DAWs open it correctly and Logic doesn't. But I could try that as well. Thanks
Mac Pro 2013 6-core
64 GB ram
Motu M4
OSX 10.15.7
Logic Pro 10.6.1
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 6:18 pm

tusitala wrote:
Here's the midi file. I deleted all the notes in Sibelius before exporting, so that now only the tempo track is present.
And again I can confirm that Logic thinks bar 62 is at 120 bpm when it is not, it's 114.


alright..here is a little midifile sanitizer script I just wrote, called midisane; it runs on the command line. Proof of concept.

This script will take an input midifile, and will filter out redundant Tempo and Time Signature changes when they occur on the same delta time. Only the last one will be included in the output midifile. The output goes to stdout, so once you have it installed you execute it like this on the command line

midisane input.mid > output.mid


The new saved midifile should load into LogicPro without the problems you have been running into

Install Instructions

  1. Install midicsv using the following instructions: http://macappstore.org/midicsv/

  2. copy the following script into a text file and save it either in your PATH (if you know what that is), or else just save it to the same folder where you have midi files to sanitize).

    #!/bin/sh
    #=======================================
    # midicsv + awk to massage midi file
    #=======================================

    midicsv $1 |\

    awk 'BEGIN {FS=", "; OFS=", "}
    {
       if( $2 != lastTime || $1 != lastTrack) {
           lastTime = $2
           lastTrack = $1

           if(last["Tempo"] != NULL) {
               print last["Tempo"]
               last["Tempo"] = NULL
           }
           if(last["Time_signature"] != NULL) {
               print last["Time_signature"]
               last["Time_signature"] = NULL
           }
           if($3 == "Tempo" || $3 == "Time_signature") {
               last[$3] = $0
               next
           }
           else {
               print
           }
       }
       else {
            if($3 == "Tempo" || $3 == "Time_signature") {
               last[$3] = $0
               next
           }
           else {
               print
           }
       }
    }' | csvmidi


  3. You need to give the saved script file execute permissions before you can run it. Open up CMD terminal and cd to the folder where you have saved the above script, then use the following command line to give it execute perms, assuming you have named it as midisane like I have:

    chmod +x midisane


  4. Its ready to use. In order to run it, use a line like I mentioned above, the output is to STDOUT..which means binary gibberish will be sent to your terminal window unless you redirect output to the file where you want it saved:

    midisane input.mid > output.mid

Please let me know if this sanitizes your midi file to work correctly in LogicPro.
Last edited by Dewdman42 on Sun Apr 25, 2021 6:41 pm, edited 4 times in total.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram
 
User avatar
Dewdman42
Posts: 3280
Joined: Tue Sep 09, 2014 3:01 pm
Location: Salt Lake City, UT

Re: MIDI file opened in Logic is different (wrong) than other programs

Sun Apr 25, 2021 6:29 pm

ps - to make this easier to use, I just want to say, once you find it useful its not that hard to wrap this inside an AppleScript bundle or Keyboard Maestro thing, so that you can drag and drop midi files onto it, etc..stuff like that.... this is just a quick proof of concept, but you do have to be a little nerdy in the command line to use it for now.

I have some other midifile sanitation tasks I want to add and possibly put into a large app or something that is easy to use but will take care of a few things

for example

  • LogicPro can't handle midi files that have markers saved as "cue points". DP, for example, saves locked markers as so called "cue points", which are part of the midifile spec, but I found that LogicPro ignores them. So, I'd like the optional ability to convert cue pointes to "text point" markers..which LogicPro will import properly.
  • There can be issue if a midi file has keyswitches on the same delta time as the notes they are switching. Similar as above, the import order would be non-deterministic. An option to bump each note on the same timestamp up by one midi tick...would make sure the import will play as expected..though it won't be sample accurate anymore after that. One midi tick is less then 1ms usually, so I don't see this as being a problem if and when this need arises.

will probably think of more stuff later that needs massaging in order to get into LogicPro from other places.
OSX 10.15 (Catalina) on OpenCore - Logic Pro 10.6.1, VePro7, Mainstage3
5,1 MacPro 3.46ghz x 12 96gb ram