gmp

dcumpian
Loaded the Midi data into a new CWP with Ivory. Ivory did not respond to any of the pedal up events. In the PRV, the pedal up (CC64 = 0) is clearly after notes that should have already ended, but are still playing.
 
To hear it more clearly, I then moved two of the bass notes to another note (clashing) and raised the velocity. Still happened. Then I shortened one of those notes and it did respond to the pedal up, even though the note length displayed in the PRV was already not long enough to still play after the pedal up. Either there is some problem with Ivory and X3e, or the PRV is not accurately displaying note lengths, or pedal up positions properly. It's pretty crazy because after changing the notes, just a tiny bit, they did respond correctly.
 
I didn't have time to play around with the data beyond that...
 
Regards,
Dan
 

Thanks for verifying this bug. How long ago did you upgrade from X1 to X3? We both have Ivory and we both have Komplete. I haven't had Komplete that long, so I may try an old image file before I got Komplete and see if it happens there. Let me know if you have an theories on why this is happening

I just upgraded two weeks ago. So far, this is the only anomaly I've run into, and I still have a lot to learn about take lanes. I miss layers a little bit, lol...
 
Now, I haven't started actually mixing anything yet as I'm still in the tracking stage...
 
Regards,
Dan
 
 

dcumpian
I just had this happen to me yesterday with X3e and Ivory. Turned out that the pedal up was too close to the end of the notes. When I shortened the notes a bit in PRV, the problem went away. I didn't ever have this happen in X1d, so something has changed.
 
Regards,
Dan
 

I've had issues with the sustain pedal controllers before as well… when opening an older version project. It would seem like the "up/down" controllers got reversed so when it was supposed to be a down pedal it was seeing it as up and visa versa.  Adding a new control (up/down) event before the first existing event would get things back "on track"

gmp

rcrees

dcumpian
I just had this happen to me yesterday with X3e and Ivory. Turned out that the pedal up was too close to the end of the notes. When I shortened the notes a bit in PRV, the problem went away. I didn't ever have this happen in X1d, so something has changed.
 
Regards,
Dan
 

I've had issues with the sustain pedal controllers before as well… when opening an older version project. It would seem like the "up/down" controllers got reversed so when it was supposed to be a down pedal it was seeing it as up and visa versa.  Adding a new control (up/down) event before the first existing event would get things back "on track"

So are you referring to X3 when you say the "up/down" controllers got reversed?
In fact I think that if they were reversed in my example, it would create the same problem we're hearing. 
 
When you say Adding a new control (up/down) event before the first existing event would get things back "on track". Do you mean if the first event was a down, then you'd add one more down in front of it? I assume you mean the  first existing event that seemed to be reversed? Sounds like a valuable trick to know.


IN all the versions before the X series there was a display of overwrite and sound on sound. I'm disgusted they've removed that feature and refuse to add it back in. I finally gave up asking. I used to use sound on sound to fix sustain pedal problems that I created by auto-punching in and out. Since I can't tell visually what mode I'm in, I've decided to just use the piano roll view to fix the sus pedals

When I say "up/down" what I mean is the controller event for "off/on" for the sustain pedal.  I can't remember the controller number, but I believe the number is the same for on OR off… and I believe that the way it works in the midi file is that it reads the first instance as "pedal down" since it would be up to start with.  Then, when you release the pedal it inserts the same controller number, but interprets it as pedal up and so on until the end of the file.  So, if at the beginning of your track there is an extra OR missing controller event, they would be off…reversed… for the rest of the file.  It could possibly be that your piano track starts with the pedal down, but the controller, since it is at the very beginning might not be carried over when you copy and paste.  Try inserting a controller (again, I can't remember the number right now) somewhere near the beginning or maybe even a couple of measures in and see if that puts things back on track… that has helped me in the past.
 
Rob

brundlefly

rcrees
I believe the number is the same for on OR off… and I believe that the way it works in the midi file is that it reads the first instance as "pedal down" since it would be up to start with.  Then, when you release the pedal it inserts the same controller number, but interprets it as pedal up and so on until the end of the file.

Yes, the Continuous Controller number for sustain is always 64, but the value varies from 0 to 127. As I mentioned earlier, for a synth that only has on/off response to sustain, 0-63 is OFF (up), and 64-127 is ON (down), but most controllers only send 0 and 127. In any case, the differeing values mean that you can put sustain controllers of any value in any order, including multiple messages with the same value, and the synth should always "know" what behavior to exhibit at any given point in the sequence.
 
If a particular synth were to assume that the first CC64 message always represents pedal down and that the next message is always the opposite state, that would be very bad programming, but I've never seen one that makes that mistake.
 

Sorry.  Of course, you are absolutely right.  On is 127 and off is 0.  What I've experienced in the past is (and strangely enough, just recently) is a case where my sustain pedal gets switched.  I load in a new piano synth and without touching the pedal, it assumes that the pedal is already in the "down" position… and the first press of the pedal sends a "0" or "off" message.  When I release the pedal it sends a "127" or "on".  Very strange behavior that happens very rarely.  But I believe it is my Keystation, or the pedal.  When I reboot my system (including the Keystation) all goes back to "normal".  I don't think it is a SONAR issue...
 
Best,
Rob

I just recorded a piano track with lots of sustain pedal. Upon playback at bar 49 I noticed the sus pedal was stuck in the down position. It was clearly not doing that when I recorded the track. I played bar 49 a couple of times and it was bad each time. So I cloned the track and then found out both the original track and the clone track were fixed - no sus problem. I hit undo and sure enough the original track had the sus problem again. I hit redo and it was gone.

Hit undo where the problem was and copied the midi data. I then cloned a new piano track this time without copying the data and pasted the midi data in this new track. It was fine  - no sus problem.

WHen I originally tried to capture this problem a week ago, I thought I noticed cloning of the track fixed the problem, so back then I opened the TTS-1 piano and copied the midi data into it's midi track and the problem was there and I used this as my example. This has got to be the strangest bug. I guess when you clone, something gets reset.

I opened piano roll view and hit undo until I had the problem and saw the sus pedal events, which looked fine, but weren't working right. I then hit redo and kept the piano roll open and so no change in the piano roll, yet the problem was fixed. In the event list nothing changes from when I have the problem and when it's fixed.

By the way WHERE IS CAKEWALK? I've gotten no response at all from this thread, no suggestions, nothing. I sent in an email tech support issue about resetting VST Scan on 4/22 (10 days ago) and have gotten no response except the initial automated email. I've emailed them 2x asking if they could respond - nothing. I know phone support is better, and I may have to resort to that.

When you are cloning, are you cloning just a MIDI track or a Simple Instrument track? And are you leaving both tracks active so that all notes and controllers are are being doubled, or do you mute the original? If dupe events are being sent to the synth, I can imagine that would alter the rendering process just enough to fix an intermittent problem.
 
And are you still using TTS-1 for testing or is all of this with Ivory?
 
 
 
 

I have to replace TTS-1 because I don't have the 32-bit DX installed. I seriously doubt if any of these machinations are going to reproduce the symptoms on my machine given that I've never seen it, but if you want to upload a project with 64-bit TruePianos (either the Cakewalk or Full version), I'll be happy to give it a go. To minimize the amount of fiddling needed to make it audible, remove all buses from the project, and set the output of the synth track directly to Main Outs 1/2.
 
 

brundlefly
I have to replace TTS-1 because I don't have the 32-bit DX installed. I seriously doubt if any of these machinations are going to reproduce the symptoms on my machine given that I've never seen it, but if you want to upload a project with 64-bit TruePianos (either the Cakewalk or Full version), I'll be happy to give it a go. To minimize the amount of fiddling needed to make it audible, remove all buses from the project, and set the output of the synth track directly to Main Outs 1/2.
 
 

I reinstalled Win 7 from scratch. installed my Layla 24 audio, did all Win Updates+optional, motherboard updates, Nvidia updates, installed MOTU midi interface, installed X3 64 bit only. Opened the normal template played the piano and recorded it, had a few sus pedal problems.
 
Opened my bun file, loaded True Pianos, copied the midi data from TSS-1 midi track to True Pianos midi track. Played it and the sus problem was gone for that mdii track only. Then I went to the TSS-1 midi track and used Truepiano as the input and there was the sus problem.
 
I saved to a new cwp file, recorded the audio of the good Truepianos track and also the bad one, then saved it as a bun file. So you can try the CWP first if you like. I have a feeling it will show up this time. For some strange reason something gets reset when you copy midi data or clone the track like I did the other day. Cloning also gets rid of the problem.
 
I got rid of all the buses and pluggins to keep it simple. Hopefully Truepianos will load automatically. Here's where the CWP and BUN are
https://onedrive.live.com/?gologin=1#cid=C256E2DAE26B22A5&id=C256E2DAE26B22A5!105
I deleted the old files, so there's only those 2 files there.
 
Thanks for your help,

rebel007
Interesting thread. I am not very versed in midi and thought that I was doing something wrong when recording. I get mixed sustain messages when recording in True Pianos, Dim Pro and Rapture. It seems like some times the sustain pedal works as intended, and some times it carries on for a lot longer than when I am telling it to stop. I also record the audio from my keyboard (Ensonique KT76) at the same time as the midi, and the sustain in the audio track works exactly as intended.
I can't remember having this issue before I updated to X3 and thought that maybe I'd changed setting. As I said, I'm not that savvy with midi and I hope that this is the problem being discussed and I haven't misread the entire thread. I'll keep an eye on this thread and hope I can pick up some pointers.

You described the problem perfectly. You have it also. Your Ensonique KT76 is an external synth and it doesn't happen with any external synths like you reported, it only happens with the softsynths like Truepianos. It doesn't happen with X1, something changed with X3.
 
I recorded a punchy rhythmic piano the other day at a very brisk tempo - 237. I didn't even use the suspedal at all.  I had to stop several times and autopunch back in. Backed up about 4 bars. When I heard my recorded piano, I played along like I always do and every time I tried to autopunch I got all sorts of sustaining notes before the punch in point, until it punched in and then the notes died out. SO what this indicated is that X3 is not recording all of the note offs.
 
If you hit a note on your piano. It first sends a "note on" message out of your midi cable to X3, and as soon as you lift you finger off the note it sends a "note off" message. Both messages are recorded, but in the event list all we see are the note on messages. So it's possible this bug is more of a note off problem than a sus pedal problem. Both problems sound very similar with sustaining notes.
 
I turned in a bug report on this and they said it's not a bug, but more of a unique problem with my computer. Since then I've found one other person in this thread that reported the problem, you make the 2nd. So I can get this back on the bug list and fixed, would you download my newer bun and cwp file and see if you notice the sustaining problem?
 
There are 2 Truepianos midi tracks. One is named "bad". All you need to do is play one midi track and then mute that track and unmute the other midi track and play it to see if you hear the sustaining problem. If you open the bun file instead of the cwp, you'll hear the audio versions - one bad Truepianos, one good.
 
 Hopefully Truepianos will load automatically. If it doesn't play, you may have to go to my midi track and click on "input" and make sure Truepianos is selected. IF Truepianos wasn't automatically loaded, you'll have to load it manually in the SynthRack, don't choose "simple instrument" instead choose a separate midi track and audio track and then go back to my midi track and changed the input to Truepianos.
 
Don't use copy and paste to paste the mdidi data into the Truepianos midi track, if you do somehow it resets the midi track and the problem goes away.
 
Here's where the CWP and BUN are
https://onedrive.live.com/?gologin=1#cid=C256E2DAE26B22A5&id=C256E2DAE26B22A5!105

brundlefly
Gerry, good news, sort of... 
 
I am able to reproduce the problem with the first of the two new bundle files you posted. And more interestingly, when I dragged the MIDI clips out of the project and imported them into a new one started on my machine, the problem persisted with the "bad" clip.
 
I've now edited them down to a point right after the second pedal up where the bad clip continues to sustain notes that end both before and after the pedal up, while the good one stops sounding at the last note off after the sustain up. And this persisted after I applied trimming, and even after bouncing to clips.
 
Where it got really weird, though, is when I exported/imported the "good" and "bad" bounced clips a second time; now they both misbehave on playback, and neither the first nor second pedal up are honored.
 
And finally, if I open the clip as MIDI in X1 or 8.5 and insert a synth, it plays properly. But If I do this in either X3 or X2, the pedal ups are not honored. So for me, whatever this is is goes back to X2 in terms of playback.
 
I'll be comparing preferences between my SONAR versions and experimenting other clip modifications to see if I can nail this down a little better for a Problem Report to the Bakers.

Actually this is good news. I think i'll upload my new bun file to Cakewalk and let them know 4 people have now verified this bug. I renamed my download files. The CWP file was misnamed bun in the name, not the extension. I think you turning in a bug report will be good also, you may find more insight into this than I've found.


I'm looking into a related issue, but this one so far only applies to Ivory piano. I recorded a punchy rhythmic piano the other day at a very brisk tempo - 237. I didn't even use the sus pedal at all.  I had to stop several times and autopunch back in.
 
Backed up about 4 bars. When I heard my recorded piano, I played along like I always do and every time I tried autopunch I got all sorts of sustaining notes before the punchin point, until it punched in and then the notes died out. SO what this indicated is that X3 is not playing back all of the note offs.
 
After recording when I play back the track it sounds fine. All the note offs are correct. It just very annoying to have a rumble of sustained notes happening right before it autopunches in and then persists for a few more seconds until the hung notes die out. This happens with 64 bit and 32 bit X3. When I use Truepianos instead of Ivory, it works fine, so I hope this Ivory problem goes away after they fix this bug.
 

b rock

If you hit a note on your piano. It first sends a "note on" message out of your midi cable to X3, and as soon as you lift you finger off the note it sends a "note off" message. Both messages are recorded, but in the event list all we see are the note on messages. So it's possible this bug is more of a note off problem than a sus pedal problem. Both problems sound very similar with sustaining notes.

 
Interesting thread.  Forgive me if I missed this (I've been following from time to time, but not every detail).  What model of MIDI controller or keyboard are you using for input?  The reason that I ask is that I've always had more similar problems - over many Sonar versions - with controllers that transmit true Note Offs.  This opposed to the "legal" Note On with a velocity of 0 as a Note Off substitute.
 
I've always suspected that keyboards with a Note Off variable release value tend to muck up the works in Sonar.  Never proven.  I have a number of KBs and MIDI controllers here, and by far the instances of "stuck notes" happen more often in the true Note Off devices.

I use a Yamaha P200 88 key Piano as a controller that I've used for 15 years and I have 2 midi interfaces I can use - MidiSport 2x2 and MOTU FastLane. I've had every Cakewalk version since DOS and X2, this is the first time I've had a severe problem. Maybe some intermittent ones in the past.

b rock

I use a Yamaha P200 88 key Piano as a controller

Well, there goes my theory.  Transmits 9nH v=0 as Note Off.

I appreciate you putting forth any theories. At this point I'm grasping at straws. This is baffling.
 
Have you tried to load my CWP or BUN file to see if it's happening with you? If you find that you do have the problem and then try it in X1 or 8.5 you'll see the problem goes away.


 
Here they are
https://onedrive.live.com/?gologin=1#cid=C256E2DAE26B22A5&id=C256E2DAE26B22A5!105

Yes, Cakewalk TruePianos loaded right up, and the project was pretty much ready to play except that the output of the synth track was set to None rather than defaulting to Main Outs 1/2, and the audio tracks were set to Out 3/4 instead of 1/2. SONAR warns that the synth track is assigned to a "silent bus" so its not a problem and doesn't affect the ability to reproduce the issue.
 
Incidentally, I would not slip-edit the clips down because they will want to see the whole thing, and might be inclined to suspect that the slip-editing is causing the problem otherwise.

In thinking back, I may have seen this once. But it only affected one note in a ~4-minute performance, and when I moved the pedal up a few ticks earlier the problem went away and I promptly forgot about it. I think I haven't encountered it more often because the "piano" sound I work with most often is from layered hardware synths that aren't affected by this soft synth buffering issue.

lstorrow
Has this bug been addressed?  I'm seeing it in X3 when entering pedals by hand and playing through Dimension Pro.  Some pedal ups are ignored, and I can't always fix it by adding another pedal up before the last note off.
 
 

Cakewalk is aware of the bug. I worked with Tech support on the phone for a good while twice and he acknowledged it was a bug. I've used Cakewalk products since the DOS days and the X series is the first one that had show stopper bugs that were not addressed and fixed.  X1 and X3 have had show stopper bugs, so I'm still using 8.53.
 
There's no way I'll have a client in my studio and play a perfect piano part only to find there are sus pedal errors that I have to fix and waste studio time. I just hope it's fixed in X4. I'll use their trial version first, since I've lost my trust in their integrity.