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

That's not my file nor am I the author of this topic...

Opps, sorry about that. I need to make sure to also read who posts replies as well.

Sibelius 6 interprets the MIDI file correctly (although it looks like a mess and the values right of the decimal point of the tempo are slightly different from ValliSoftware's list).

Ableton Live 10 basically chokes on it and messes up everything after around measure 45 or so.

 

Finale 25 and Musescore 3 seem to have problems, too.

 

Interestingly all programs open the file in a completely different way:

 

Sibelius doesn't create a single staff by itself, however after adding one all tempo and time signature changes become visible.

Ableton needs you to drag the MIDI file into the arrangement. Tempo and time signature changes are there up to a certain measure; after this things get really weird.

Finale 25 creates a full staff list with all time signature but does not seem to have imported tempo information (despite having been told to do so).

Musescore creates an empty document without a single staff. When adding a single staff a single measure without time signature gets added. No other time signatures or tempo changes are visible throughout.

This is a good post and I'll mention something else about this.

The MIDI file is a valid MIDI file as it follows the MIDI specification.

 

However as you can see, each application interprets the MIDI file differently.

Since we don't have access to the source code to Logic or Sibelius, we need to see if either program can be adjusted within to get our desired results.

If not, then the next step is to see if modifying the MIDI file can be done.

 

I did mention one solution, but there's another solution as well.

The MIDI file is coming from 62 and going to 114.

If there was a time gap of 4 seconds, then we'd be going gradully from 62 to 114, this is great no problem, a user perference.

Now let's say at 2 seconds, I want to go to 120, then to 114.

Again, great, no problem, another user perference.

 

What make no sense is, we're coming from 62, going to 114 with no time span, still okay, but Sibelius decides to stick in a 120 tempo, and all this with no time span, why?

So another solution would be to just delete the 120 MIDI event entry from the MIDI file.

 

Again, this is a totally valid MIDI file which I've seen many, but I've also seen many that do this kind of thing where, even though it's a valid MIDI file, certian entries make no sense to even put in.

 

This is why I've created MIDI tools where I can clean up MIDI files so, in my case, to get imported to my taste in Logic.

Yes, file bug reports, but don't expect a fast turn around time for a release.

Be prepared for implementing work-a-rounds.

If you want to get to the bottom of this: Try to change the 114 BPM in Sibelius to something higher than 120 and export it again. If Logic then recognizes the new (higher) tempo it means that Logic sorts the events by value if they appear at the same timestamp.

(That wouldn't be a solution, though; it's merely to find out what exactly is going wrong here.)

 

Thanks so much everyone for your input.

Gacki, I've tried your suggestion. I put a metronome mark of 135 in that spot and exported the midi then. No chance! Logic still sees that as 120!

And the thing is Digital Performer, Reaper, Studio One, all open it correctly.

 

Once in Studio One, I exported the (correct) midi from there, and opened that in Logic. Now Logic sees it correctly

I'd probably just delete the erroneous 120 BPM tempo in Logic and be done with it....

 

 

That one's part of the MIDI file and it certainly shouldn't be there because it can cause problems.

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

It’s not necessarily a bug. The midifile spec is kind of loosey goosey. Its not very strict protocol and many products take liberties in how they save or interpret midi files. I recently spent a lot of time trying to figure out how to properly export tempo maps between different daws and there are a lot of them doing things slightly differently with markers also for example also. I tried to export a tempo map from dp into dorico and an extra tempo point got inserted into dorico that was not even in the midifile itself it was just something dorico felt it needed to insert while interpreting the midifile.

 

There are smpte frame rate based options in the midifile spec and not a single daw that I tried handled that properly at all.

 

If you want to see what’s in the actual midifile an easy tool to see the guts is midicsv, which will convert the midifile to a text form, then you see exactly what is being exported. Perhaps you may be able to figure out why logic ends up with that extra 120bpm event. That is like the default tempo so I’m rather suspicious that is not in the midi-file, but the way logicpro reads the midifile and overlays it into your project could perhaps leave an existing tempo point in place?

 

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

Perhaps you may be able to figure out why logic ends up with that extra 120bpm event. That is like the default tempo so I’m rather suspicious that is not in the midi-file, but the way logicpro reads the midifile and overlays it into your project could perhaps leave an existing tempo point in place?

 

It is in the MIDI file. When I import it into Sibelius 6 there's that 120 BPM event as well.

Yea.. here is midicsv output from the midifile posted earlier....

 

.
.
1, 280320, Tempo, 962264
1, 280320, Tempo, 500000
1, 280320, Tempo, 526315
1, 280320, Time_signature, 7, 2, 24, 8
.
.

 

I know it doesn't look like it, but if you divide 280320 by 960, you get beat 292, which is where you have the tempo change. the large integer number also, is basically just a midi file's representation of tempo, which is not BPM, its expressed as microseconds per beat. To convert to BPM use 60,000,000 divided by the large number in the midifile, for example 60,000,000 / 526315 = 114

 

So anyway yea...there are three tempo events at exactly the same time location. In my view that is a bug in the export, and how to import that is up to each product to do it different ways..I hear you that some other DAW's are interpreting that non-sensical situation in a way that works better for you then how LogicPro is interpreting it, but how you can LogicPro interpret three tempo events at the same time location? Probably it ought to use the last one...in the order its found in the midifile, but there is no specification that says anywhere that that rule should be followed. The other DAW's you mentioned seem to take 114, which is the last one to win. For whatever the reason LogicPro uses the second one, who knows why...but I would say its simply an error on the part of Cubase to export a midifile with three different tempos from the same point in time. its a non-sensical situation that Logic doesn't seem to handle as sensibly as some others, but its still non-sensical none the less.

 

My guess is that the Cubase project allows those three tempo events to be in sequential order with sample accuracy...but when exported at 960 PPQN, they end up on the same tick... But again, why would you even have three radical tempo changes on a single PPQN tick or even if sample accurately...spread across that tick in some way...it doesn't even make sense to have that situation to begin with.

and the other thing...this I will point a finger at LogicPro as a bug you can report... looking at your earlier post..it looks to me like LogicPro interprets those three tempo events in a non-deterministic order. In other words, it does not assume that their order in the midifile is relevant. It only assumes the timestamp is relevant...and whatever algorithm it uses to insert those events into its own event list...loses the midifile order...because all three events have the same timestamp...its non-deterministic which order they will end up in LogicPro.

 

That actually MIGHT be specified in the midifile spec, that the order in the midifile does matter, but I'm not sure, you have to check the midifile specification. In that case, I would definitely call that a design flaw as it should in my mind be the obvious choice, that if and when there are repeat events on the same timestamp, insert them into the event list in the same order they appear in the midifile...that's obvious to me..and perhaps obvious in some other products too..but apparently it was not obvious to the devs who made LogicPro's import feature..

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.

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...

 

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"

 

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"

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.

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

 

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.

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..

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.

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.

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.

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.

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.

This is becoming a stupid conversation.

 

No argument here.

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

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.

Edited April 26, 2021 by Dewdman42

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.