bvideo

Now that I've tried it, apparently "time base" applies only to the start time of the clip. So each note would have to be its own clip for this method to work. So I went and tried it, splitting my original clip into individual clips per note. Then I drew a tempo curve. Then I selected all the note-clips and set the time base to absolute and also set the clip lock to "pos". Then when I reset the tempo curve, it seemed to work OK. After that, all those notes could be bounced to a clip. One thing, though: it did not lengthen the notes to match the changing speed. OK for percussion, but not for tones.

I'm thinking once you've created a clip like this it can be copied and manipulated, e.g. reversed, stretched, delete some notes ... Somebody went to a lot of trouble making this work in Reaper, graphics and all. It must have tremendous musical value.

You might be able to get mathematical precision by jiggling with the clip time base as follows: enter a clip with all the notes you want in the decel/accel sequence, evenly distributed, starting where you want them. change the tempo to get those notes strung out the way you want. (Don't worry) lock those notes to absolute time in the clip properties time base field restore the tempo back where it was The notes in your new clip should remain distributed through time, losing their musical time association, while the rest of the music is essentially undisturbed, being restored to the original tempo. It still needs some planning to get your time-disturbed sequence to end just where you want it. It's multiple steps, but saves you having to perform it perfectly or calculate each note perfectly. Edit: By the way, once you get those notes into the right time distribution, you will still be able to adjust the overall length and speed of them by using the normal clip stretching operations. Edit again: I've never tried this

parboo12, you're entitled to submit some kind of problem report to the bakers. I doubt this thread will come to their attention. Seems like the easiest thing for them to do is change the document; the functionality is OK otherwise. By the way, for real-world quantizing, such as entering MIDI by hand or sequence and then wanting it to fit with a real performance, it seems like "groove quantize" would be the way to go. Want to check those parameters??

My only aim was to confirm the OP did bring up a valid discrepancy between the document and the result. Also to clarify the actual operation of the one parameter. I get that you're not on board with that. What anyone wants to do with quantize or why doesn't seem important to that end.

Would you like to try it? With a window of 50% (or higher) all notes get quantized. Strength is not being tested here, nor is performance. And yes, the window straddles the grid point. So as I tested, a window of 50% reaches all the notes. Whereas the document says: "A window of 50 percent extends only a quarter of the way toward the adjacent quantization points."

I don't think the quantize (non-groove) dialog works exactly as the document says. I think there is no difference between setting the window at 50% and any value above 50%. Numbers 50% and smaller seem to work, and 50% covers all notes. I think the % represents the fraction of the distance between two grid points. Using 100% would make every note part of the window of two consecutive grid points (actually 3 if the note is on a grid point). Every window N% greater than 50% could make some notes within the N% window of one grid point also be within the N% window of the other nearest grid point. For example, if window is 70%, if a note is at 60% from one grid point it is also at 40% from the nearest grid point. Quantize then favors the nearest gird point. Obviously the document is wrong in saying 100% represents half the distance between grid points.

Another likely scenario is that the pedal-up event was in the end section that you split off and deleted.

The next thing I would check for is midi routing. Maybe there is some kind of midi storm or at least duplication of data going through the Roland or going to Pianoteq. I don't know if MidiOx might help diagnose this or maybe examining the event list of the track you are recording for Pianoteq. So also check your MIDI tracks' channel configuration (setting a single channel instead of omni) and make sure echo is off and make sure "local control" and "thru" is off for your keyboards.

Is midi going through a midi interface or a USB connection? Any further details would help: make, model, hub?

So when the transport gets stopped, those sounds won't match how you set them with those controllers. The "chase" setting should put them back where they should be wherever you restart, but if you want to play those instruments or edit notes, etc., after stopping the transport, they won't sound right. Come to think of it, it's kind of inconvenient to have controllers modifying sound when you go to edit at different points in the timeline.

I don't know the answer and I don't disagree with your suggestion, but in the absence of the "all notes off" option, maybe there is some existing workaround to whatever issues you have with "Zero Controllers...". Can you describe a situation that zero controllers messes things up?

Can anyone say what should happen with dim solo in that simple case? When track 1 is soloed, then would track 2 be dimmed as it goes out to the patch point? Then track 3 dimmed also, double-dimming the sound from track 2? How should double-dimming be avoided? And did such attempt to avoid wind up being the source of the no-dimming on track 3? More complex routing would probably have even further hazards.

Is the studio live f/w up to date? Sample rate you're using in Sonar/Cakewalk matches the device setting (in Universal Control) ? Are you using DAW mode or interface mode? USB presumably?

Maybe the Soundcraft signature series 12 MTK is only capable of 48KHz recording. What sample rate is your project set at? What sample rate does Cakewalk think the Soundcraft can do? Are you using a soundcraft driver? ASIO? Asio4All?

Is it like this: "tempo based delay and noise"?

Impressive!

Do you mean external synths? Misbehaving MIDI interface, too many thrus, bad or too long MIDI cables... Can you make a shortcut to the "panic" (all notes off) button? (The Reset MIDI and Audio button in the Transport module)

If you truly mean a MIDI track, what is the thing that should be generating audio? Is it an external device which you have wired to send audio back into cakewalk? If so, you would need to make sure that device's audio track is grouped with the MIDI track's solo button so it doesn't get automatically muted along with all your other tracks.

What did you mean by 'peaks'

Back there you said "peaks, clicks, etc.". Clicks could be a performance issue, but what did you mean by 'peaks'; also 'etc.'? Is there some audio distortion happening that could be independent of performance issues?

As a point of information, try recording one of those non-controllable patches from the keyboard, then see how that bank & patch is labeled in the event view of Cakewalk. To be complete, make the keyboard change banks as well as programs as you record. The event view might work as your debug log. You can open the event view by selecting a track and pressing ALT-8.

Dirty console emulator?

Also, if you're using firewire & WDM drivers, try ASIO.

A straight line with boxes would not be able to explain anomalies in the mute & solo & input echo parts of the MIDI signal flow or how prerecorded material merges with live input or the entanglements with instrument tracks and their synth components.