What's the relationship between the processEvents(); MIDI noteOn 'deltaFrames' and the processReplacing(); 'sampleFrames'.
To get the correct timing in my poly synth, if a noteOn has a deltaFrame of eg: 100
does that mean I should play that note when sampleFrames = 100.
Kirsty
deltaFrames and sampleFrames ?
-
- KVRist
- Topic Starter
- 486 posts since 21 Nov, 2012 from Sitting in front of my PC
-
- KVRAF
- 3080 posts since 17 Apr, 2005 from S.E. TN
I believe that deltaframes are the number of sampleframes offset into THE NEXT AUDIO BUFFER TO PROCESS. I believe it also works that way in audio units though the terminology may be different. So far as I recall it is/was also very similar in DXi softsynths.
The way I would control softsynths, as best I recall-- Maybe there are other ways it is done--
First calculate which midi events should be rendered in the next audio buffer, the next time slice, according to tempo and whatever else matters. Maybe the next rendered buffer will be small or maybe larger, depending on the computer and program audio settings.
Determine the sample offset of each midi event that needs rendering in the next audio buffer, the sample offsets referenced against my playtime of sample[0] in the next buffer.
Send the midi events to the soft synth.
Tell the soft synth to render the next buffer.
Mix that rendered buffer and send it to a computer audio output or to a rendered disk file.
Dunno if it is safe to send midi events with offsets big enough to need rendering in some buffer past the very next one. I never tried that because it seemed like begging something to go wrong.
IOW, if I want a note to start at the beginning of the next buffer, the deltaframe is 0. If I want a note to start 1 ms after the beginning of the next buffer, at a samprate of 44.1 k, the deltaframe would be 44.
The way I would control softsynths, as best I recall-- Maybe there are other ways it is done--
First calculate which midi events should be rendered in the next audio buffer, the next time slice, according to tempo and whatever else matters. Maybe the next rendered buffer will be small or maybe larger, depending on the computer and program audio settings.
Determine the sample offset of each midi event that needs rendering in the next audio buffer, the sample offsets referenced against my playtime of sample[0] in the next buffer.
Send the midi events to the soft synth.
Tell the soft synth to render the next buffer.
Mix that rendered buffer and send it to a computer audio output or to a rendered disk file.
Dunno if it is safe to send midi events with offsets big enough to need rendering in some buffer past the very next one. I never tried that because it seemed like begging something to go wrong.
IOW, if I want a note to start at the beginning of the next buffer, the deltaframe is 0. If I want a note to start 1 ms after the beginning of the next buffer, at a samprate of 44.1 k, the deltaframe would be 44.
-
- KVRist
- Topic Starter
- 486 posts since 21 Nov, 2012 from Sitting in front of my PC
Thats the setup I'm currently using.
However, I wonder if a host ever sets deltaFrames > sampleFrames? as I'm still getting some slight timing errors.
I'm beginning to suspect that the noteOff events should be treated in the same way as I think the errors are inaccurate sustain lengths.
Kirsty
However, I wonder if a host ever sets deltaFrames > sampleFrames? as I'm still getting some slight timing errors.
I'm beginning to suspect that the noteOff events should be treated in the same way as I think the errors are inaccurate sustain lengths.
Kirsty
-
- KVRAF
- 3080 posts since 17 Apr, 2005 from S.E. TN
Hi kirsty, dunno.
Can't even recall what mechanisms may have been available in the different plugin specs for sending note duration info, because my hosting was trying to handle DXi, VST, AU and hardwire MIDI with as similar code possible. Which was done that way for my convenience so that the sequencer could use the same underlying "strategy" regardless what destination the MIDI was routed to.
I always sent discrete note-off events, indexed into whatever buffer they needed to be sent in order to turn the notes off at the proper time. So far as I recall, which may be wrong. Usually the note-off events were note-on events with velocity of zero, unless needing specifically to send note-off with recorded velocity.
I also made sure to deliver to softsynths MIDI info in deltaframe order. IOW, if midi happened to be coming from one or more tracks and also merged with live MIDI THRU, I would sort the different streams so that there could never be a big deltaframe followed by a smaller deltaframe. I did not know if time-scrambled deltaframes might confuse some synths, so made sure that this never happened.
Can't even recall what mechanisms may have been available in the different plugin specs for sending note duration info, because my hosting was trying to handle DXi, VST, AU and hardwire MIDI with as similar code possible. Which was done that way for my convenience so that the sequencer could use the same underlying "strategy" regardless what destination the MIDI was routed to.
I always sent discrete note-off events, indexed into whatever buffer they needed to be sent in order to turn the notes off at the proper time. So far as I recall, which may be wrong. Usually the note-off events were note-on events with velocity of zero, unless needing specifically to send note-off with recorded velocity.
I also made sure to deliver to softsynths MIDI info in deltaframe order. IOW, if midi happened to be coming from one or more tracks and also merged with live MIDI THRU, I would sort the different streams so that there could never be a big deltaframe followed by a smaller deltaframe. I did not know if time-scrambled deltaframes might confuse some synths, so made sure that this never happened.
