brundlefly
512 should be more than enough; in fact you might want to lower it. I think the default is 64, and I run my desktop at 128. My laptop is at 512 because it has a slow drive.

I used 256 for years and then started using 512, because I tend to get some unexplained dropouts out of the blue, for no apparent reason. Do you think these numbers have any effect on the lost note offs?

Probably not; I just wanted to eliminate possible setup differences between versions that might account for the change.

MIDI note overlaps: synths or DAWs ought to cancel any note in progress when a new note-on of the same note number comes in. In this case, you are playing live while playing back. Possibly, the synth receives two note-ons without an intervening note off. It should cancel what it is doing for that note and start a new attack. Is this something you can easily test? In other words, record a long note. Then rewind and record a very short note, same note number, while the long note is playing. How does the synth respond?
 

bvideo
MIDI note overlaps: synths or DAWs ought to cancel any note in progress when a new note-on of the same note number comes in.

That depends on the patch/instrument programming. Many instruments in the real world can be retriggered without - or only partially - interrupting/muting the evolution of the sound from the previous pluck/hit/hammer blow/etc. A piano with the sustain held down is a perfect example, and I'm sure Ivory is designed to use additional voices to simulate the effect of "re-hammering" an open string, letting multiple hits ring on until the damper comes down.
 
EDIT: In fact, IIRC, you can see the effect of this in TruePianos; the CPU load will increase as you hold sustain and re-key the same note repeatedly because it's having to generate multiple voices. TruePianos uses physical modeling as well as sample playback so the effect is significant.

Yeah, it should interrupt/mute/restart at least, if not cancel. But from a real keyboard, there would be a note-off before the next note-on for any note number; the sustain pedal does not prevent an incoming note-off from a keyboard. The keyboard has no idea what the synth is supposed to do about the sustain pedal. That depends on the synth's patch. In the synth it just extends the sustain phase if the patch parameters so dictate. The synth should remember that note-off was sent. Otherwise, it wouldn't know whether or not to extend the note when the sustain pedal is lifted.
 
We had this discussion once before ...
 
According to OP, there is no sustain involved anyway. In this case, with a DAW (Sonar's original recorded track) and keyboard both sending (albeit filtered by Sonar), is there a parity of note-offs with note-ons? Do they arrive in a strict sequence? Does Ivory depend on that in some way? And the question behind this question is what is Ivory doing wrong that Truepiano is doing right, and what is the exact circumstance that generates this unexpected behavior? That's why I am wondering about the flow of note-ons & -offs.
 
Interesting about truepianos. I know it has one piano that models soundboard resonance with just a pedal down, but I didn't know about modeling resonance build-up from multiple keystrikes, if that's what it is.
 

I figured you understood all of this quite well, and had just mis-stated. The synth should only advance the envelope for a given voice to the release stage if a corresponding note-off has been received (and the pedal is up), not just on receiving another note on. If the sustain pedal isn't down, you might not normally expect to have more than one voice being used at a time, but the potential for more than one still exists if a second note on is received while the first voice is still in its release stage. And with or without sustain, it's up to the synth to keep track of what note ons and offs have been received, and to advance the envelopes for each voice in the order that they were originally triggered accordingly.
 
At least, that's the hardware synth model; things may be a little different in the soft synth world where the host architecture has a bearing on how MIDI and audio are buffered into and out of the plugin. There's definitely potential for interoperability issues there, depending on how a given synth renders audio.
 
Regarding TruePianos modeling, I was't necessarily referring to resonance modeling, specifically, but just that Forefront advertised it as a modeling synth even before they released that one patch that included resonance modeling. It's not so much that other patches model resonance but just that multiple voices can be playing the same note number/pitch at the same time and evolving the timbre of each independently according to whatever other modeling rules exist.
 
 
 

Synthogy tech support said they'd get in touch with Noel about all of this and try to figure out why this is happening in X3 and Platinum, but not in 8.5 and before. Am I the only Ivory user that uses autopunch? I'm beginning to wonder.

Good news Noel verified the bug, which turns out not to be a bug, but a feature. But a fix is in the works.
 
Noel said:
The issue is that Ivory allocates a voice for each note on even if it is the same note and counts the note offs. Most other synths will turn off the note on receipt of the FIRST note off which is why you don't see the problem with other synths.
 
This started happening because we added explicit note on management in X2 to address stuck notes with the matrix. It works fine in all cases except when you have duplicate notes which is what happens when you do punch in recording. I am looking into a fix. I doubt it will make it into the upcoming update but I will send you the build to verify on your end.
 

gmp
Good news Noel verified the bug, which turns out not to be a bug, but a feature. But a fix is in the works.

Noel said:
The issue is that Ivory allocates a voice for each note on even if it is the same note and counts the note offs. Most other synths will turn off the note on receipt of the FIRST note off which is why you don't see the problem with other synths.

This started happening because we added explicit note on management in X2 to address stuck notes with the matrix. It works fine in all cases except when you have duplicate notes which is what happens when you do punch in recording. I am looking into a fix. I doubt it will make it into the upcoming update but I will send you the build to verify on your end.

This explains something I ran into over the weekend in X3 with EastWest Quantum Leap Orchestra. I had a double note that I couldn't see in the PRV and the note wouldn't stop playing. Was a bugger to find it.
 
Regards,
Dan

dcumpian

gmp
Good news Noel verified the bug, which turns out not to be a bug, but a feature. But a fix is in the works.

Noel said:
The issue is that Ivory allocates a voice for each note on even if it is the same note and counts the note offs. Most other synths will turn off the note on receipt of the FIRST note off which is why you don't see the problem with other synths.

This started happening because we added explicit note on management in X2 to address stuck notes with the matrix. It works fine in all cases except when you have duplicate notes which is what happens when you do punch in recording. I am looking into a fix. I doubt it will make it into the upcoming update but I will send you the build to verify on your end.

This explains something I ran into over the weekend in X3 with EastWest Quantum Leap Orchestra. I had a double note that I couldn't see in the PRV and the note wouldn't stop playing. Was a bugger to find it.
 
Regards,
Dan

 
X3 has 2 bugs, one which involves the sus pedal and punching in, which has been fixed in Platinum. The other bug involves the lost note offs and this is the one in this thread. I'm not sure which one was affecting you recently and you're right it may have been the bug I reported, because I bet you didn't use the sus pedal for an orchestra sound.
 
I'm surprised more Ivory users haven't chimed in on this thread. Of course if they don't use autopunch or have an engineer manually punching them in, then they would not be affected at all. But any Ivory users that use a punchin method should have noticed this.
 
 Of course many times when something goes a little haywire, many of us tend to think maybe we did something wrong, like picking a bad punchin spot, so maybe some users may have been suffering in silence with this issue, not realizing it's a bug. Or if they're new to Sonar and had not used X1 or 8.5 before, they may think this is the way it's supposed to work.
 
Well, regardless, help is on the way with this bug/feature.