looking for a program to adjust midi file durations and note start times.

C

coolhotfun

New member
Using sony acid and there's midi processes and filters where you can scale the duration by a percentage but it doesn't do decimal points only like say 50% or 51% nothing in between. Then I'm stuck with having to choose one or the other and then cut up the midi file every few sections and move it left or right so it lines up with the beat measures. Some notes go long past where to chop in segments so its a real hassle. Need some other type of other program that can change the midi file duration and note length with more decimal point precision.
 
Many programmes don't do decimal points because midi timing isn't accurate enough to handle it. Remember midi is serial, so the smallest click it can manage is then delayed to be sent in the sequential system midi uses. If you record a midi sequence played out from a synth, internal or external, then you can time slip the audio far more gently than you ever can midi. MIDI is by modern standards, quite blunt when it comes to timing, hence why channel 10 always gets sent first, because drum timing is usually the most important.
 
well i got another thread going over here and reddit math.. check it out for more stuff going on.. these math guys are like getting decimal points from whole percentages. But it involves scaling more than once. D'ya think this would work or would it ruin the midi if you scale too many times. Check that out and see what ya think and reply here.

hydrogenaud.io/forums/index.php?showtopic=106016
looking for a program to adjust midi file durations and note start tim - Hydrogenaudio Forums

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

"When you scale by a percentage you are multiplying by a factor, e.g. 50% means multiplying by 0.5. If you scale a second time then you get the product of the two factors, 0.5 * 1.01 = 0.505 or 50.5%.

What you need is to write a program (or find someone to write one for you) that experimentally multiplies two percentages to get as close as possible to the scale that you want. This could be a program that you enter the desired scale and it reports the two percentages.

Or possibly write a program that, for each combination of two factors between 50% and 150%, calculates the resultant scale, then sorts the results and prints out 10,000 combinations (possibly deleting combinations that give the same result). You would then just look at the printout whenever you needed to scale something.

Let me know if you don't get any takers on writing this for you and perhaps I could take a shot at it. In fact it just occurred to me that this could easily be done as an Excel spreadsheet."

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

Ignoring the decimal and viewing the percentage as a whole number, if you can figure out the prime factorization, it's not too bad to do.

For example, suppose we want to get 67.014%. 67014 = 2*33*17*73

Multiplying 2%*27%*17%*73% = 0.067014%, so we need this shifted over by three decimal places. Since 400%*250%=1000%=10, we simply multiply it by 1000% three times, so

67.014% = 2%*27%*17%*73%*250%*250%*250%*400%*400%*400%

I'm not sure if there's a best way to handle your example of 67.234%, as not all of the prime factors of 67234 are less than 400. For that you'd probably be better off just going with 67.23%

----------------------------------
 
nevermind, solved it over there.. that dude sent me that epic spreadsheet.. able to get micro percentage from an acid slider that only does 2 digit percentage by running it twice. amazing. so thread closed, problem solved. Thanks for everyone who helped.
 
rob aylestone said:
Many programmes don't do decimal points because midi timing isn't accurate enough to handle it.
Click to expand...

Wrong, Rob. MIDI runs @ 31.2 kilobaud per second which is more than enough to 'do decimal points'. Why do you insist on chiming in on threads, then dispensing wrong or useless information? Leave the MIDI answers to those who REALLY know what they're talking about, because there's enough confusion about MIDI without you muddying the waters further!
 
ssscientist said:
MIDI runs @ 31.2 kilobaud per second which is more than enough to 'do decimal points'. Why do you insist on chiming in on threads, then dispensing wrong or useless information? Leave the MIDI answers to those who REALLY know what they're talking about, because there's enough confusion about MIDI without you muddying the waters further!
Click to expand...

The interface runs at 31.25 kbps, not the program controlling it.
Remember that the transmission is asynchronous, which means a byte (along with its accompanying start /stop bits) can commence at any moment that the program sends it.
Assuming we're not dealing with a 'log jam'. i.e. a surfeit of pitch bend commands.

The program takes its timing from the computer's internal clock and matches it to the Ticks per Quarter Note that the DAW software has been set to.
480 TPQN used to be standard in the somewhat recent past (which is overly slow for slow music, e.g. at 60 bpm), but these days it's more often 960 or even 1920 TPQN.
That setting is then stored in the file's Header Chunk.

That then combines with the MIDI Meta Data that sets the tempo, which is defined in microseconds per quarter note (or "24ths of a microsecond per MIDI clock") according to the MMA specification. So quite tight internal timing is available, far tighter than the transmit rate.
And remember Tempo is not a fixed value. The necessary Meta Data can be input many times per measure or even beat, if you wish.

Again, according to the spec., this allows a four minute piece at 120 bpm to be accurate, at then end, to within 500 microseconds (i.e. half a millisecond).
Generally speaking musicians aren't quite that accurate, although the Stones were a very 'tight' sounding band in their day.
So MIDI is not "crude" at all, in its timing, far from it, it is almost (or can be when correctly set up) unbelievably precise.

It's generally our misunderstanding of how MIDI can be used that limits what we can achieve, that and the limitations of the software we use.
In the latter case we just use a hexadecimal editor and hack the MIDI file. No problemo!

This ain't rocket science! ;) (Believe me I know. I used to write and deliver courses about the technology of Inmarsat.
You've all heard about Inmarsat and flight MH370 and calculating the plane's position from 'pings'.
Now that is rocket science, sort of.

Just some random jottings!
Have fun,
John.
 
Last edited:
Unpleasant slap down read and smiled at. Is a scaling of just one percent actually noticeable?

While I'm happy with the concept of the timing being accurate, it doesn't get over the issue of sequential transmission. Clearly, in a sequential system you cannot have simultaneous events. The first one can be very accurate, as has been explained, but each event is separated in time. A note on message is around 1ms, so a 10 event situation is starting to be the kind of delay that if it was latency in an audio card, some people might be starting to notice. This is the point I'm making (perhaps badly, I don't know) We can improve the accuracy of the various stages in the process by the sequencer or other software having better internal timing, but if each message has to be separated in time by a millisecond per byte, attempting to adjust timing very precisely is a bit pointless if it gets stacked up ready to send.

Have I got this wrong? Has the MIDI spec changed in design? With the best system available, ten drums sounding at exactly the same time, described in the software with as many decimal places as you like, will sound one at a time, and you have no control over that. Running status helps of course, but loading up 10 note on messages on each of the 16 channels is a fair bit of delay, isn't it?
 
Last edited:
rob aylestone said:
Unpleasant slap down read and smiled at. Is a scaling of just one percent actually noticeable?

While I'm happy with the concept of the timing being accurate, it doesn't get over the issue of sequential transmission. Clearly, in a sequential system you cannot have simultaneous events. The first one can be very accurate, as has been explained, but each event is separated in time. A note on message is around 1ms, so a 10 event situation is starting to be the kind of delay that if it was latency in an audio card, some people might be starting to notice. This is the point I'm making (perhaps badly, I don't know) We can improve the accuracy of the various stages in the process by the sequencer or other software having better internal timing, but if each message has to be separated in time by a millisecond per byte, attempting to adjust timing very precisely is a bit pointless if it gets stacked up ready to send.

Have I got this wrong? Has the MIDI spec changed in design? With the best system available, ten drums sounding at exactly the same time, described in the software with as many decimal places as you like, will sound one at a time, and you have no control over that. Running status helps of course, but loading up 10 note on messages on each of the 16 channels is a fair bit of delay, isn't it?
Click to expand...

The thing I'm not happy about is ten drums all sounding simultaneously.
I've never heard a human drummer that can get just two hits exactly on the same millisecond.
Nor, I think, would I want to. ;)
If you choose which hits need to be exactly on the beat, which might benefit from being fractionally early, and which slightly late, you'll have (IMHO) a much better sounding track. But it is just my old-fashioned opinion.

Being creative, I go to PRV and adjust my drum hits back and forth listening carefully until they 'sound' right and tight.
Never had any issues with MIDI timing (bar pitch bend overload, and too many simultaneous SysExes ) with more than twenty years experience of it.
I started on an Atari ST.

We always have to work within the limitations of the technology we have available. Not ask the impossible.
I did with 4 track, then 8, lastly 24. Many more problems with head alignment, tape slip, bleed through, motors, hum, demagnetising, ... !
Not to mention the sheer bulk of hundreds of 2 inch tapes.

MIDI was made to be cheap to implement physically and easy to understand, never to be a professional studio standard, although it has become that.
And it's lasted 30 years, so it can't be SO bad, can it?

But you're quite right about it being sequential. Each three byte (typically) message takes approximately 1 msec.
Each byte is ten bits through the interface (start bit, data byte, stop bit). Thirty bits at 31.25kbps. Q.E.D.

Using VSTi's I spread my orchestra across several virtual MIDI ports, four is not unusual, and thereby I can get parallel 4x31.25kbps.
Try running multiple copies of the VSTi across several MIDI ports, that may solve the problem.
I'm not even sure that there is an 'internal' limit in some DAW s/w is there??

Some random jottings.
Regards,
John.
 
Last edited:
Something else we can do to help ease the concentration of messages around the instant of beats in rigidly quantised music is to shorten the notes a little so that Note-Off messages don't add to the queue. I find 85% works well. You may think that is a bit short, but as a pianist I have to say it's about right for non-legato playing and for notes not followed by rests (I believe notes that end due to a rest rather than the need to move fingers to the next note should sound their full duration).

Some perspective: sound travels at 1000 feet per second, or one foot per millisecond. If you consider how perceptible (or in-perceptible) the delay is when standing 10 feet from a guitar cab, that will give you on idea of what 10 ms feels like.
 
Mmmmqac said:
Something else we can do to help ease the concentration of messages around the instant of beats in rigidly quantised music is to shorten the notes a little so that Note-Off messages don't add to the queue. I find 85% works well. You may think that is a bit short, but as a pianist I have to say it's about right for non-legato playing and for notes not followed by rests (I believe notes that end due to a rest rather than the need to move fingers to the next note should sound their full duration).

Some perspective: sound travels at 1000 feet per second, or one foot per millisecond. If you consider how perceptible (or in-perceptible) the delay is when standing 10 feet from a guitar cab, that will give you on idea of what 10 ms feels like.
Click to expand...

I'm not sure how moving the relative position of Note Off messages is going to affect the attempt at simultaneous transmission of Note On messages.

However, talking piano yes, normal non legato should definitely not be full length.
They should probably vary between say 80 to 90 per cent.
Legato, around 95 or so.
But with strings, brass and woodwind, legato notes should overlap the following note in a phrase, i.e. be 101% or so.
With the legato controller cc#68 (cc#64 for some VST instruments) turned on after the commencement of the 1st note, and off again after the commencement of the last note of a slur.
 
SysExJohn said:
I'm not sure how moving the relative position of Note Off messages is going to affect the attempt at simultaneous transmission of Note On messages.
Click to expand...

If notes end at the same tick that other notes start, the MIDI messages for the new notes wait within the MIDI output's message queue until the note-off messages have been sent. We can eliminate that delay by having notes end a few ticks earlier so that the queue is empty when it is time to send the new note-on messages. We still have messages queuing up if there is a chord to be played, or several channels hitting at the same time, but the queue is shorter.
 
Ah!
I'm with you now.

But surely nobody inputs notes that are all 100%, do they?
Common sense would tell one that no human can play that way even if they tried.

[rant]
It's like having all notes at the same velocity. So often I see them all at 64 or 100, or much, much worse, all at 127.
With the Channel Volume (cc#7) turned all the way up.
One might as well pound on the keyboard with one's fists and heels!
This isn't music by anyone's definition.
[/rant]

Sorry, got carried away! ;)

John.
 
You must log in or register to reply here.
Back
Top