Jump to content

Question About Midi Resolution


Dewdman42
 Share

Recommended Posts

The new features in S10 state that it now has sample accurate midi vst timing.

What does that mean exactly? In most DAW's one can specify a midi resolution to use(for example, 960ppqn). This is often the resolution used while capturing performance from a midi controller....and while quantizing that would be the highest level of resolution by which notes can be moved around, etc..

I think I can guess this means that I can position a midi note exactly where I want, down to the sample resolution, which is far more precise than say 960ppqn, and samplitude will make sure the VST plugin is given that sample accurate timestamp for the midi event to take place. Fine so far?

What happens during midi performance capture? How are the timestamps handled? Does Samplitude use the souncard as the midi tick generator based on the sample count? If so, what about midi interfaces or low level midi drivers that provide midi timestamps? Are they converted accurately to a sample based timestamp? What if I want to constrain the input midi so that incoming midi events are stamped according to a certain PPQN resolution such as 960 or 1536? I see there is a field I can specify this value, but how is that used exactly? Are midi events always stored in the midi object with sample based timestamps regardless of this PPQN setting?

Would it be possible for me to quantize midi events in a track or midi object to a PPQN resolution I specify?

Thanks

Link to comment
Share on other sites

I think I can guess this means that I can position a midi note exactly where I want, down to the sample resolution, which is far more precise than say 960ppqn, and samplitude will make sure the VST plugin is given that sample accurate timestamp for the midi event to take place. Fine so far?

Yes, exactly.

> What happens during midi performance capture? How are the timestamps handled?

We use the timestamp (1 ms resolution, more is not possible with MIDI hardware spec) from the MIDI driver / Windows system.

> What if I want to constrain the input midi so that incoming midi events are stamped according to a certain PPQN resolution such as 960 or 1536? I see there is a field I can specify this value, but how is that used exactly?

The finest resolution to quantize is a 64th note at this time.

> Are midi events always stored in the midi object with sample based timestamps regardless of this PPQN setting?

Midi events have a BeatPosition and a sample position. The Beatposition is important so that for example a note on a full beat stays on the full beat even if the sample position of that full beat isn't a whole number, but a fraction. (Can happen with non 120 BPM tempos :P )

> Would it be possible for me to quantize midi events in a track or midi object to a PPQN resolution I specify?

No, not yet. The finest resolution is a 64th Note (16 PPQ). But you can use a quantize window to catch only notes 1% around a 64th, if your concern is to keep full beat notes on full beat.

Do you want to do listening tests if a 1600 PPQ quantized MIDI piece sounds "more human" than a 384 PPQ quantized piece or so?

What would you use the PPQ-Quantization for? Thinning out Controller data density?

Greetings,

Frank

Link to comment
Share on other sites

Thanks so much for responding to my questions and so quickly! I know I may sound a little nuts asking some of these things, but I have been involved in some long discussions related to midi timing, so I'm just trying to get to the bottom of what samp could or could not do for me over the other DAW's (which are flawed in this area).

> What happens during midi performance capture? How are the timestamps handled?

We use the timestamp (1 ms resolution, more is not possible with MIDI hardware spec) from the MIDI driver / Windows system.

Sure, I realize that 1ms is the windows timer and that is perfectly reasonable and what most other sequencers do as well, though some are able to utilize the DirectMusic timestamp instead of using the one they generate in the sequencer, which may or may not be perhaps lower level and more accurate depending on who you talk to. A few very lucky souls are able to use hardware midi timestamps with the right setup, but unfortunately the industry never standardized on that. In those cases, some sequencers can ignore their own timestamp and use the one provided by the driver.

But my question is rather this. Approximately every 1ms, Samplitude will go see what midi events are waiting and assign a timestamp for those midi events in the track. Will that timestamp be whatever the current sample count is at that resolution, or will it be something based on M:B:T? The reason I ask is because the math that happens during this operation will have to round to the nearest M:B:T if that is used, and at this point I'm not sure how large that resolution is. I know in Sonar its hard coded to round to 960ppqn always, regardless of what the midi tick resolution is set to. However, if the calculation is done to a sample count resolution, then there will be less rounding error. NOBODY else does that. If samplitude does, will be impressed. Does it? If it does, then can i assume that any timestamps generated by a lower level driver as I explained earlier are ignored by Samplitude?

> What if I want to constrain the input midi so that incoming midi events are stamped according to a certain PPQN resolution such as 960 or 1536? I see there is a field I can specify this value, but how is that used exactly?

The finest resolution to quantize is a 64th note at this time.

What is the "PPQ" entry field in Samplitude project options designed for? What does it do? What is the max value I can put there? What is the effect of using this related to how the midi event time calculations are performed at the time the events come in every ~1ms and what is stored internally in the track and what do I have access to to change. I see that the example project has this value set to 384. What is the significance of that? Can I set it higher?

> Are midi events always stored in the midi object with sample based timestamps regardless of this PPQN setting?

Midi events have a BeatPosition and a sample position. The Beatposition is important so that for example a note on a full beat stays on the full beat even if the sample position of that full beat isn't a whole number, but a fraction. (Can happen with non 120 BPM tempos :P )

You lost me a little bit there. I assume you mean that a note is stored on the track as M:B:? where the "?" is a sample position offset from the beat? But now that I think about it, that gets a little wierd with changing tempos. When using traditional M:B:T ticks, the time value of a tick changes with the tempo.

> Would it be possible for me to quantize midi events in a track or midi object to a PPQN resolution I specify?

No, not yet. The finest resolution is a 64th Note (16 PPQ). But you can use a quantize window to catch only notes 1% around a 64th, if your concern is to keep full beat notes on full beat.

Ok. thanks. Are there any plans to increase the resolution options for quantizing?

Do you want to do listening tests if a 1600 PPQ quantized MIDI piece sounds "more human" than a 384 PPQ quantized piece or so?

Heh heh. Well let's not start a debate about who can hear what. No, I don't personally think 384 is enough resolution for a lot of reasons that I won't bore you with here, though I agree that many people will probably be happier using 384 since it will impose a sort of automatic tightening of their material in a way that makes metrical sense. 960ppqn actually does not make metrical sense, I'd almost rather use 768, for this reason. 384 has the same attribute though more course. 1536 would be the ultimate for me. I have created a diagram at one point showing the rounding errors that happen during 960 compared to 768 if you are interested in it, PM me. A phd somewhere actually ended up using it in one of his lectures.

Anyway, the point is, Sonar is hard coded to 960 which is a pet peeve of mine. Internally it always rounds events to 960. Are you saying Samplitude always rounds events to 384? I'm not sure if I would prefer 384 over 960, maybe yes, maybe no, but 768 or 1536 would really be my preference if a sequencer supported it.

What would you use the PPQ-Quantization for? Thinning out Controller data density?

No. If the tick resolution is 384, then a certain form of quantization is happening to all incoming midi notes. They get rounded out to the nearest tick. 384 divides better into 3/4 and 4/4 meters than say 480. Even though 480 is higher resolution, it would round all notes to oddball places in terms of musical meter. Obviously 960 is better than 480, but its debateable whether its better then 384 and definitely may not be better than 768. 768 or 1536 generally speaking may assign notes to the track in locations that are in better musical places metrically. PM me if you want and I will send you that diagram. I don't really want to start a big discussion about it here, just trying to find out what Samplitude does. You caught my attention with the statement about it being sample accurate into VSTi's, but I just want to understand exactly what that means.

Thanks again!!!

Link to comment
Share on other sites

Some points to clarify:

- we always use the timestamp from the MIDI driver, but this timestamp data format has a resolution of 1 ms (its a long integer in millisecond units).

- If you record MIDI with external gear, a MIDI command (3 Midi Bytes) needs about 1 ms to be transferred through the MIDI cable. Therefore a finer resolution is typically not urgently required - it is just to avoid jitter. External hardware MIDI gear usually has a latency about 1-7 ms, sometimes even more. At least this "problem" is solved by using VSTi software synths which have sample accurate time stamps for playback.

- the PPQ setting for MIDI projects is only used for MIDI file export. Internally, the MIDI events are at least sample accurate, and musically exact at the same time (double float musical position is saved, too).

But now that I think about it, that gets a little wierd with changing tempos.

;):P yes, this scheeme maybe very tricky when dealing with object movement if a tempo map is present, for example ;)

depending on the operation and settings if objects/markers should be adapted musically or keep their original time, either the sample position or the beat position is used for calculation and then the other metric system positions are adapted. And we have a special method to avoid jitter on these operations.

But my question is rather this. Approximately every 1ms, Samplitude will go see what midi events are waiting and assign a timestamp for those midi events in the track.

No, samplitude is called back from the MIDI driver whenever MIDI data has been input. This MIDI data contains a time stamp for every event.

So realtime MIDI thru is dependent from the callback speed on your computer system (typically 1-6 milliseconds with good MIDI interface gear, there are applications which can measure the MIDI thru jitter on your system).

The MIDI recording is more accurate than the MIDI thru, because here we use the time stamp of incoming MIDI data. Even if the callback is delayed, the data will be recorded as you played it, as long as the MIDI driver prints the correct time stamp. 1 ms resolution, as I stated above.

If the tick resolution is 384, then a certain form of quantization is happening to all incoming midi notes.

We should distinguish between internal resolution and quantization, although the internal resolution can be regarded as a kind of quantization... Let's call it the resolution-quantization.

But I think it is clear now: in samplitude, there is no PPQ resolution-quantization, because here we are sample accurate - but incoming MIDI data itself has a resolution of 1 ms (this is microsoft windows MIDI SDK and MIDI driver, we cannot do anything about this).

But if you would move MIDI notes manually to match a percussive audio reference recording, for example, you can do this with sample accuracy!

(In future, we will have groove quantize with the possibility to extract the groove from audio, we already have the transient detection for audio quantize.. then the sample accurate MIDI resolution really becomes useful - especially if a VSTi is used for playback - sample accurate MIDI drum retriggering/replacing is possible this way, for example).

The other benefit is you have a effective PPQ resolution of 22050 PPQ at 120 BPM at 44,1 kHz. (The effective PPQ is dependent from tempo and sample rate if you use sample timestamps). The MIDI data resolution guaranties that you a never more away than half of a sample from the full quantized beat position. Important for some dance music styles, if you work with strictly technoid quantized stuff only.

Now why do we state that VSTi MIDI is sample accurate only since the last version? MIDI output in windows has only 1 ms resolution due to thread scheduling etc. So the MIDI output processing for external gear (and therefore VSTi) has been using a 1 ms resolution. Now we changed internal MIDI output resolution to sample accurate timing, so softsynth/VST(i) can now fully benefit from Samplitude's internal MIDI resolution which can be even finer than one sample, as stated above (floatint point beat position). I used to think to use this as selling argument is a bit over the top, but since exactly this statement has catched your attention, it might have been the right decision to promote this feature.

384 divides better into 3/4 and 4/4 meters than say 480. Even though 480 is higher resolution, it would round all notes to oddball places in terms of musical meter. Obviously 960 is better than 480, but its debateable whether its better then 384 and definitely may not be better than 768.

With Samplitude you don't need to think about this anymore. The internal resolution is so to speak double float (64 bit word length) beat position, which always fits exactly on muscial meter fractions. But for MIDI (VSTi) output, thís resolution gets resolution-quantized down to 1 sample, due to VST protocoll and the audio engine itself of course. For internal MIDI editing operations, everything musical related (quantization, moving, adjusting to tempo maps) is done with the double float musical beat positions. This retains the original feel/groove of the MIDI data as precise as possible (ok, 128 bit float would be even more precise, but this would be ultra ridiculous, since this would be several millions times finer than sample resolution, and already 64 bit float is much finer than sample resolution - no one can play so accurate ;) )

But as we see in this discussion, what "MIDI sample resolution accuracy" really means in practice is not so simple to explain/understand, due to the situation that MIDI recording is limited by WINDOWS to 1 ms resolution resp. due to the MIDI protocoll transfer speed which is 1 ms for one MIDI command (3 bytes, in running state 2 bytes + startbit and stopbit for each byte. Phyical MIDI words are therefore 10 bits long).

Hope this all makes sense for you.

Greetings,

Frank

Link to comment
Share on other sites

(In future, we will have groove quantize with the possibility to extract the groove from audio, we already have the transient detection for audio quantize.. then the sample accurate MIDI resolution really becomes useful - especially if a VSTi is used for playback - sample accurate MIDI drum retriggering/replacing is possible this way, for example).

Greetings,

Frank

-------------------

Ah, sounds good. In which version? Frank, a commitment please (written in blood :P )

Lacroix

Link to comment
Share on other sites

Frank,

I love you. :P ...Err....thanks for the "soon to come" Groove Quantize. I have quite a bit of ideas that Ill post. Just to kill time later today. ;)

Link to comment
Share on other sites

Frank,

Thanks for such a nice explanation. I do indeed like the direction you guys are going with the double float precision internal timestamps. And the ability to lock midi events to exact sample points is great, with the future possibility of extracting sample accurate midi events from, for example, a recorded audio drum track...and be able to use the EXACT same groove as the audio, sample accurate without any jitter introduced by virtue of some lower PPQ that would resolution-quantize the material. I like it!!

With time you may even be able to come up with a collection of groove templates that ship with the product that everyone can use, that just groove way better than any old midi based groove templates, because of the finer resolution.

Another question, what about when it comes time to export that midi track as a Standard Midi File? What values will be used for each midi event?

You lost me about about what exactly that 64bit beat position is you are talking about. I know in my case I deal with crazy tempo maps that change all over the place and I am constantly having to tweak them(for film scoring). I would need to be able to change the tempo at any time or place and have the midi data adjust in a way that makes musical sense, not adhere to a realtime factor. For example, if I record a midi event that is 12000 samples after a beat, then I change the tempo....the value should not remain 12000, it needs to move the event in some way makes sense musically for the tempo change. Traditionally, in most sequencers, a midi event is at a certain M:B:T in the track. The size of T changes with the tempo so that the events are always at the right distance from the beat relatively speaking as you change the tempo. You mentioned that things can get a little tricky related to this, can you please clarify?

I would think that it might be an option to have midi events be locked to an actual point in real time instead of a traditional M:B:T. But that seems like the exception more than the rule to me. Otherwise, we are forced to pretty much figure out the exact tempos ahead of time and then record the midi data and don't change the tempo ever if we want the midi track to continue to sound good.

Regarding the 1ms OS limitations, I totally hear you, there is a lot of slop in both the midi hardware as well as the windows OS, probably well more than 1ms for most people. So the reality is that there is currently no way to really capture sub-millisecond timing nuances from a midi controller into a sequencer of any kind unless you have hardware timestamps available, which nobody on Windows does. However the DirectMusic driver does use a sub-ms timer, FYI.

Lots of times it will mean editing the midi data, either with quantizing, or manually, to move midi events to better musical locations, and I gather that Samplitude has much finer precision than anyone else for doing this...providing that the beat position is based on a musical position, not a realtime position after each beat.

I guess what I am saying, is that I'm not sure I want samplitude to capture those 1ms timestamps exactly as is. I want Samplitude to be able to round the values out to a PPQ grid resolution of my own choosing. This would be the equivelant of having an input-quantize that is set to 1536ppq for example. And I still don't understand the purpose of the PPQ field in the Samplitude project options. If everything is being stored as 64bit beat position, then how is the PPQ value used?

let me relate to Sonar operation just so you can understand my questions better perhaps. In Sonar, you set a PPQ resolution for the project. It has a max of 960, with maybe about 10 preset resolutions. You can't type in any random value like you can in Samplitude. I found out from Cakewalk that the purpose of the PPQ is only to effect how midi events are displayed in the PRV and event list. But that internally they always use a resolution of 960 to store the midi events for the track. If I then change the project PPQ setting to say 480, the midi events retain their original 960ppq resolution in their storage, but the actual display of those events is rounded out to a 480ppq grid. If you move events around, then they will be on the 480 grid, but if you don't move them, then if you change the project PPQ setting back to 960 you see the original 960 resolution timestamp. In other words, the underlying storage resolution did not get resolution-quantized to 480ppqn unless the midi event was moved or changed according to that lower PPQ setting.

I actually don't like that aspect of Sonar. If I set the PPQ to 768, then I want the data quantized to that grid. I actually do see value in material being quantized to musically sensible grids like 768 or 1536 instead of 960....... While I like the idea of the 64bit precision beat position you guys have introduced, I like it for the groove matching possibilities you mentioned, that is exciting. But I think if input midi data is resolution-quantized to 1ms grid, that is not any better than the 960 grid imposed by Sonar. Its a non-musical random quantization. On the other hand, if it were possible to have input notes rounded out to 768 or 1536ppq, then the final calculated timestamp that is stored would be in a more musically metrical location in the track....

Here is a diagram to explain what I'm talking about...

PPQN_Jitter_map.jpg

The interesting thing is that this shows a traditional sequencer's PPQ grid, at several resolutions. Across the bottom are 1ms gaps, but the interesting thing is that the 1ms intervals are not usually going to be lined up with the PPQ grid. They will be offset by some random amount. But during any 1ms period of time, one or more midi events come in, they get timestamped by the trailing edge of that 1ms gap, and then in a traditional sequencer, they would further get rounded to a PPQ resolution. Notice how 960ppq has hardly any ticks that line up in metrically musical spots, but under 384, 768 and 1536 the locations are more musical (at a very fine level)?

Anyway, Sorry to get off on such a technical tangent... I have been following Samplitude for a while now for many reasons. I really really really love the PRV and staff view which I think is the best in the world right now. Midi timing issues are crucial to me. I'm not too happy with Sonar's options either to be honest. I plan to try to put Samp10 demo through some intensive sessions to see if it will work for me, if for no other reason, the PRV/staff view which I think is pure brilliant.

Thanks again for the clarifications.

Link to comment
Share on other sites

I want to uderstand what you are saying as applies to the real world. Could you reference a file handled various ways so that we can actually hear what you are talking about? I see a lot of theoretical realities that are practical irrelevancies (to most of the world) when applied in the real world being argued to death on the net all the time.

Personally, I started using MIDI since the DOS days of Sequencer Plus and the C-MU Midi Tool Kit....but I have not used it in years. When I did, I converted the MIDI to audio ASAP and handled it from there. It appears as though I'll be re-introducing MIDi to my rig sometime soon. So I guess I want to 'catch up'.

Bill

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...