Glueing MIDI items makes them "unquantized" (NO BUG)

[The-Zeronaut]

This is killing me because it totally destroys my drum to midi editing.

- Dynamic split track and create chromatic midi
- Midi is NEVER perfect to the split...


- Split every single midi note
- Use script MPL quantize tool 1.8 to quantize every drum hit item to every Midi note item
- They are PERFECTLY quantized to each other TO THE SAMPLE.


- Glue midi items aaaaand...they are totally out of time/unquantized.



i´ve been trying EVERYTHING for weeks and nothing works...


Right now im using Reaper 5.18 in Win7 64bits
but i discovered this issue a couple of versions ago.

[ELP]

One is sample based the other tick based...!

Glue show you after gluing simply the right integer MIDI Tick timeline position..
This is not a bug.

And that´s why I never use sample based quant time tools for MIDI.
Those tools display only quant positions but depends on BPM|ppq|hz
this would be not the true Integer tick/sample vs time position...

I do not know if you understand, but I give you one simple example.

BPM 60|960 ppq|44.1kHz

1 MIDI tick in micro-ticks(microseconds) would be 1.041,6667
1 Sample in micros would be 22,6757

The difference between both would be 1.018,9909 micros
In Samples:
1 MIDI Tick would be
= 1.041,6667 : 22,6757
= 45,9375 (Integer 46 Samples)

So if this 60BPM/960ppq/44100 at the relevant quant. position would be true:

Glue would show you after gluing one difference of ~46 Samples at timeline..
Project timeline rounding behavior >=x.5=1|<x.5=0
This result in a range of ~-23 to ~+23 samples
And this is not a bug it simply the right integer MIDI Tick vs Sample Position at timeline..

You can simply display X,YYY Samples and X,YYY MIDI Tick positions
but could you also play and save it within *.wav or whatever or Midi files?
No, never.. This need integer.

[EvilDragon]

Solution - increase PPQ resolution in Reaper?

[ivansc]

... (as I have just said in another threads) just use the standard way of editing MIDI. Select copy paste.
Surely you aren`t trying to split and move bits of a whole track including both MIDI and audio, are you?

[ELP]

yes of course ED but MIDI Ticks refers also at BPM and not only at Pulse per Quarter

If you would virtually use 60BPM|44100ppq|44.1kHz
there would be no sample vs tick difference... but of course only at 60BPM ^^

-
within DAWs or I say better REAPER
I like to work with 15360 pulse per quarter(like rewire do)
and for exporting to standard MIDI files I reduce
this to 768/384/960/480ppq... except I would import this into one other DAW

15360 is really one exzellent virtually resolution within DAWs
and it is integer divisible by 960/480/768/384 ...means all of it.

---
Thats the problem ivansc which seems to be many people today have:
the difference between
Displaying the positions and true integer positions at project timeline

Otherwise people wont move MIDI items without x/y snap or sample based
or whatever at arrange timeline. anymore..

[ivansc]

Sometimes I am very glad I came to the audio side of things after many years of MIDI sequencing. Gives you a proper grounding in the actual base differences between a MIDI edit and a sample edit.

FWIW it took my quite a long time to "get" that people didnt understand the fundamental difference.

[ELP]

^^^^
how true it is!

[The-Zeronaut]

Originally Posted by ivansc

... (as I have just said in another threads) just use the standard way of editing MIDI. Select copy paste.
Surely you aren`t trying to split and move bits of a whole track including both MIDI and audio, are you?

My entire workflow goes like this:

1º. Dynamic split track and create chromatic midi.
(maybe the bug is in dynamic split itself because the midi note is NEVER on the same spot as the audio split)
2º Split every single midi note (could be hundreds of notes for each drum)
3º Use the script MPL quantize tool 1.8 to quantize the midi notes splitted to the audio track on top so they are perfectly aligned to the sample as it is the only way apart from doing it note for note manually of getting perfect sample alignment.
4º Last step would be to glue the midi items but as i said the glueing destroys the previous quantization...

[ELP]

"quantize the midi notes ... they are perfectly aligned to the sample as it .....getting perfect sample alignment.

(maybe the bug is in dynamic split itself because the midi note is NEVER on the same spot as the audio split)"

oh oh
Your problem begins already due the fact, that you work with MIDI events & MIDI items like you work with Audio Samples & Audio Items.
Both are complete different- let me say systems.

Do you understand something I wrote about the very basic fundamental difference
from one Midi tick and one sample length in ms, microseconds or whatever?
If you really one of those people who mean they must/it must be always possible to
quantize/move/split or whatever
1 MIDI tick to 1 sample
then you should work the other way around..
quantize/move/ the Sample splits to the MIDI Tick timeline positions
and not Tick to Sample

Or also somewhat possible: an option for
"Always Show me MIDI Notes(Tick) to Sample alignment Display Fakes"

But ok maybe you understand the visual solution about I explain.

Look at the MIDI Notes Beat/tick positions within List and look at the Arrange Timeline Sample position
All these Notes has the same Timeline Tick Positions
but the Sample timeline Positions are
+22 Sample | +-0 Sample | -22 Sample


and now with +-23 Sample (46 Sample)



There is no bug involved with gluing, splitting......
If you glueing your prev. "perfect" Sample aliment MIDI Notes Splits all together, the result show you simply the real tick positions.

You can of course also use higher PPQ
Depends on BPM/ppq/Hz the difference between Tick vs Sample would be smaller.

I thing the modern sample guys need really always fake display positions SRY

" ivansc: FWIW it took my quite a long time to "get" that people didnt understand the fundamental difference"
^^^^

Greetings

[ELP]

Another simple image example ticks vs samples

track 1 perfect samples workflow aligned "Display" MIDI Note ^^
Track 2 the re-import from track 1 exported MIDI



I hope you understand the difference..
this is the same what glue or split/moving etc. pp MIDI Items/events per sample would do

Greetings

[The-Zeronaut]

I´m sorry, ELP.
I read your post 10 times and I swear I´m trying really hard to understand it. (English its not my native tongue)

What I´m getting is that you say i should make my PPQ 15360 to make it a little more accurate ¿?
Someone on a very old reaper thread said:
-"You can make Reapers midi sample accurate by setting its "Ticks per quarter note...' to your sample rate. eg. at 44.1kHz set it to 44100."
http://forum.cockos.com/archive/index.php/t-118211.html

Am i to understand from your photo example that my "perfectly aligned" midi is only aligned visually but would not trigger my drum sampler accurately but with -+22 samples off?

[The-Zeronaut]

I made a little test with 10 secs of drums hits

I tried putting my PPQ at 44100 (before it was 960)
at it makes a lot of difference (i can glue the items!!!) and they are
mostly 99.9999999% perfect

so...its 44100 overkill? or should i do 15360 as you (ELP) said?

I have to test it on longer audio files for audio to midi conversion
but it seems to have mostly solve a lot of problems

edit: even the midi files out of dynamic split are much better...maybe i dont even need to use the MPL quantize tool script anymore

[ELP]

one midi tick in samples depends on PPQ, the actual Tempo at Timeline position
and the used Sample-Rate

60.000 : Tempo : ppq : (1.000 : hz)
Example
60.000 : 100 : 960 : (1000 : 44100)= 27,5625 integer 28; +-14 samples at timeline

And yes 15360 ppq is exzellent/the best choice during editing. Meaning within a DAW..
15360 is also the standard ppq for rewire Midi

60.000 : 100 : 15.360 : (1000 : 44100)= 1,72265625 integer 2; +-1 sample at timeline
with a used tempo of 200 this would be already lower as 1 sample
= 0,861328125 integer 1

But please only for editing..... for MIDI Hardware; SMF etc. pp this makes not really sense due the fact that one channel event already needs ~1ms. And that´s why
960ppq is normally the maximal ppq standard for SMF...

But as i already wrote, i work normally with 15360.
Only if I export to SMF which I don´t use for MIDI library pattern etc. pp,
I reduce REAPERs ppq to standard ppq like 384/768/480 or 960 before I export..

Don´t forget..
"Your problem begins already due the fact, that you work with MIDI events & MIDI items like you work with Audio Samples & Audio Items.
Both are complete different- let me say systems."

Such an workflow is not really a good idea.
MIDI is MIDI Audio is Audio .. So simple

Greetings

[The-Zeronaut]

Originally Posted by ELP

And yes 15360 ppq is exzellent/the best choice during editing. Meaning within a DAW..

But please only for editing..... for MIDI Hardware; SMF etc. pp this makes not really sense due the fact that one channel event already needs ~1ms. And that´s why 960ppq is normally the maximal ppq standard for SMF...

But as i already wrote, i work normally with 15360.
Only if I export to SMF which I don´t use for MIDI library pattern etc. pp,
I reduce REAPERs ppq to standard ppq like 384/768/480 or 960 before I export..

I don't use any midi hardware at all. This is all for editing within the daw or for using vsti later(kontakt/toontrack/synths)

[The-Zeronaut]

Also thanks to everyone on this thread

You helped me a lot and solved a problem i was struggling with for weeks.

[Klangfarben]

Is there a reason there isn't a "MIDI only" or MIDI item specific glue or merge action? This is a gigantic buzzkill trying to glue midi items. I get the explanation, but I need to glue/merge midi items and everything stay in the EXACT same position it was on the grid before it was merged. Messing around with PPQ is a horrible way to try and deal with this problem and it gets even worse when you are trying to glue items containing CC data.

[MikComposer]

What's the benefit of placing midi notes sample accurately? How does it differ from standard grid?