David Baay

I generally resist the urge to comment on posts here, but sometimes the rest of the forum is so quiet, it's hard to resist. ;^) Ultimately these suggestions are intended primarily for the Bakers' eyes, but that doesn't mean other users aren't welcome to weigh in with their opinions about the value, necessity or implementation details of a suggested feature/change. It can happen (and has happened) that a suggestion gets accepted and implemented in a way that really screws up the workflow of long-time users, so they have right to register their concerns in advance. And, as you say, there appear to be many cases where a user isn't aware of an existing feature that offers most or all of what they want.

Right-click deletes. Also not previously mentioned, I believe, is that left-click and drag draws a note of any desired length, and a very short drag before release draws another note of the last-used duration - effectively giving you a note with a single-click, no modifier, and no tool-swapping. Since it's difficult to make music of any interest using only a single duration (one-shot drum sample triggering excepted, of course), I would think a lot of note entry would involve this click-and-drag gesture.

Just say "no" to My $.02: If you're writing enough music in the PRV to get a repetitive stress injury, it's time to start recording the old fashioned way... using a MIDI keyboard. Even if you have to use Step Record mode rather than real time recording, it should be significantly more efficient and ergonomically friendly than drawing notes with a mouse. And if you can manage even a rough real time performance, correcting the mistakes will probably require less clicking. And the more you do it, the fewer mistakes you'll have to correct.

That was my first thought as well, but the screenshot shows that track with the active audio meter is not focused, and not echoing.

A tick equals a millisecond only at exactly at 62.5 bpm. Your first post indicated you know the required offset in milliseconds, so nudging it by milliseconds would be the easiest way to do it. If you want to know how many ticks that's going to be, the formula is: Ticks = Milliseconds/1000/60 x Tempo x 960 (assuming default 960 PPQ Clock setting)

Hard to tell without being able to see the inputs of the synth audio parts of the Instrument tracks. My first guess would be that an instrument track was cloned which creates linked tracks associated with the same synth . Split the instrument tracks, show the I/O widgets, and let us see that along with the synth rack if you can't see the problem immediately. EDIT: Actually, a quick double-check shows that issue with duplicating instrment tracks was fixed some timte ago as I thought it might have been. Nevertheless, you'll need to check the routing, and let us know how what steps were used to create the tracks.

I don't actually work much with 'looped' audio . So far as I know, just having looping enabled makes a clip follow project tempo. I'm not sure why there's a separate 'Stretch to Tempo' option. If you imported the clip into an existing project, it should have taken on the project tempo, but as long as it is, there may have been an error when the tempo was set on export from FL Studio. Loops typically aren't that long. If you just want to work with this audio in Cakewalk at the original tempo, I suggest you go back to the source, and make sure it exports as an ordinary .WAV file. If it's not a loop, it won't matter whether you set the Cakewalk project to 160bpm before or after importing it

The Groove Clip section of the Clip tab in the Inspector has an 'Original Tempo' field.

Then I would go with Mike's suggestion that they were already REX/Groove-enabled before you imported them, and need to be bounced. But they'll automatically take on the project tempo when imported, which could already be different from the native tempo of the clip(s).

Have you confirmed the audio actually plays at a different tempo? The M:B:T timeline is the fixed reference in Cakewalk, and the Now cursor just travels faster or slower at different tempos. As a result, when you change tempo, the displayed length of audio clips will change, but they aren't actually being 'stretched'.

In addition to Nudge, there is also Process > Slide or you can enter a number of ticks in the Time field of the Event Inspector with a '+' or '-' in front of it to indicate you want that offset added to or subtracted from the the current position of each note.

Technically, it should probably be possible to to bounce only real-time audio input with Fast Bounce disabled, but it seems Cakewalk will not give you the option if nothing in the selection has existing audio or soft synth source to render. I found that you can fool it into giving you the bounce dialog by recording a short clip of any source, and muting that clip or muting the take lane. Then bounce as usual with Fast bounce disabled, and Live Input enabled. That said, since the bounce will have to be real time in any case, you might as well just set up aux tracks to route and process the left and right signals as desired, arm the final target track, and record it.

I'm most impressed that Ramona was able to pull off that piece on a 2-1/2-octave, unweighted controller. Bravo! ;^)

Ah, sorry. the routing probably reset to default when I loaded a drum program to replace the 3rd-party one I didn't have so I could hear what was going on. Still, the multiple aux tracks and sends seem unecessary.

I don't really get this. Is it just that you want a sort of 'minihost' version of CbB that just hosts VSTis with recording capability, and nothing else? Or is there something here that CbB actually can't do with reasonable simplicity?