Problems with MIDI Sustain Pedal while recording

[Steve@ZooWest]

I hope MidiMerge is indeed the issue (I'll be checking it out too), easier to work around an issue if you know the root.

Thanks Chris ~

[ChrisSimon]

Yeah, let us know, if it´s on every system the same bug.... If, believe me, AVID will get posts from me as never before...

Isn´t it amazing, how nice the program appears, if you know how to handle that bug...Kind of inspiration...)

No, but serious... Write, if that´s really the problem everywhere, so they can really get rid of that!!!!! - in one of the next updates...


Best


Chris

[DigiTechSupt]

Originally Posted by jeremyroberts

And since I work almost exclusively with midimerge disabled, I have never experienced this.

I only use midimerge mode when actually doing something that requires the function, such as a true merged overdub, or adding keyswitches or controller data. Then [9] right away.

IS IT REMOTELY POSSIBLE that a track you were recording had a #64 on at some point, and since you wee in [9] mode, the new #64 on was zapped by the old #64 off? Is there the slightest remote possibility of an operator error?

Considering that I have NEVER EVER experienced this, even when [9] is enabled, the fact that others had [9] enabled by default leads me to the possibility that a #64 off could have ben in the track, and since [9] mode doesn't overwrite, you get what you get.

Just thinking out loud, since random midi events simply make no logical sense.

That's exactly what I would think would happen - I've been investigating this for a long time and have always been able to solve it for any case I can get in front of. MIDI Merge on with sustain in the 'pre-merged' part could certainly be a factor here.

I'm very interested to hear what others experience with this. Maybe we have our 'ultimate' culprit and can find a way to engineer this so it works gracefully even with merge enabled..

[jeremyroberts]

Originally Posted by DigiTechSupt

Maybe we have our 'ultimate' culprit and can find a way to engineer this so it works gracefully even with merge enabled..

AATS: if you guys really want to engineer a better mousetrap: if you were able to code the pedal handling for midi punchins similar to how automation is written with a control surface, that would be a productivity boost. But the problem is that the pedal state is only on/off, and it's only 1-way. The pedal does not know the state the track is in. Is it possible for the software to be smarter than the pedal?

i.e. IF the track already has a pedal-on, and the next incoming event is a pedal-on, the redundant on-event is ignored (not written). ???

This way, the track does not get an extra pedal-on event written.

Same for pedal-off... some smart-guy look at "pedal logic" and how musicians use pedals and controllers while recording and overdubbing, in both midi-merge and destructive midi modes, would be a welcome improvement for a future update.

Thanks for keeping this on your radar.

J

[tonwurm]

Originally Posted by jeremyroberts

And since I work almost exclusively with midimerge disabled, I have never experienced this.

I only use midimerge mode when actually doing something that requires the function, such as a true merged overdub, or adding keyswitches or controller data. Then [9] right away.

IS IT REMOTELY POSSIBLE that a track you were recording had a #64 on at some point, and since you wee in [9] mode, the new #64 on was zapped by the old #64 off? Is there the slightest remote possibility of an operator error?

Considering that I have NEVER EVER experienced this, even when [9] is enabled, the fact that others had [9] enabled by default leads me to the possibility that a #64 off could have ben in the track, and since [9] mode doesn't overwrite, you get what you get.

Just thinking out loud, since random midi events simply make no logical sense.

it happens with newly recorded tracks, too - so it´s actually not a merge-thing, though this mode is active

[ChrisSimon]

Do you still have the problems, that sustain sometimes get´s off.... at new recorded tracks, when "merge" is off while recording?

[tonwurm]

Originally Posted by ChrisSimon

Do you still have the problems, that sustain sometimes get´s off.... at new recorded tracks, when "merge" is off while recording?

no - if I de-activate midi-merge, all is fine

my post was a response to jeremys thought, it could be an 'old' cc64 event from an earlier recording pass that switches sustain off, since merge mode does not erase any events - but as I answered to him, if midi-merge is activated, this issue occurs on newly recorded tracks too

[ChrisSimon]

Originally Posted by tonwurm

no - if I de-activate midi-merge, all is fine

my post was a response to jeremys thought, it could be an 'old' cc64 event from an earlier recording pass that switches sustain off, since merge mode does not erase any events - but as I answered to him, if midi-merge is activated, this issue occurs on newly recorded tracks too

Well at least, that new tracks can be recorded without reediting sustains...
Nice to hear...

[tonwurm]

Originally Posted by ChrisSimon

Well at least, that new tracks can be recorded without reediting sustains...
Nice to hear...

perfect

[Hanswurstlsepp]

Originally Posted by DigiTechSupt

I'm very interested to hear what others experience with this. Maybe we have our 'ultimate' culprit and can find a way to engineer this so it works gracefully even with merge enabled..

Hi,

I can confirm that the sustain pedal problem doesn't happen if MidiMerge is off.

To be more precise, what just happened here during my tests is, that *sometimes* a CC#64 with val 0/127 is not processed by MidiThru.
This means, that the CC64 event(s) were recorded correct but at the moment while playing the piano-sequence into PT, the event was not sent thru to the VI or the ext. MidiDevice.

I always have a tracklane open showing the sustain-events.

This is 100% reproducable now after Chris Simon found this out - great Chris

But I have to do more investigations, cause if i remember correct, it also happened that the CC64 events weren't even recorded into PT (this was weeks ago or so)....but I might not remember it correct and so I will continue to make this bug as isolated as possible