John T

Really like this! Is it going to be added to buses too?

Just downloaded this and had a poke around. Seems promising. Overall, I like the flatness, though of course, it's still a bit raw in its present version.

What the manual calls "Quick Groups" is how this is done, but unfortunately it's not universally applied, and I don't think it works in plug-ins. But basically, you select multiple tracks by CTRL+clciking them. And then you hold down CTRL while you move a control. Where this has been implemented, that control will move on all selected tracks. This works well on the console and track view, and on many (most?) controls in ProChannel modules. But I've just checked, and it definitely doesn't work in the Sonitus compressor. I think it probably doesn't work in any VSTs.

There's a bunch of stuff to consider here. As CSistine says, there are uses of the term "bit depth" that are unrelated. First thing to get clear is that audio bit depth has *nothing* at all to do with the system processor. Disregard that completely. Also, Cakewalk will happily have files of different bit depths in your project. You may well record at 24 bit, as per your audio interface setting. But you may have dragged in a 32 bit file from elsewhere. Or - more likely - you've ended up changing a file to 32 bit by doing a bounce or freeze. Cakewalk's default setting for that kind of in-project rendering is 32 bit. If memory serves, this file stats box in the browser shows the highest bit depth of all the files in the project. So it's unrelated to either the project bit depth, or the audio interface bit depth. For the most part, you don't really need to think or care about this, these days. Always record at 24 bit, and mostly the software will take care of the rest for you.

If it happens again, we should call in the rockers too.

Have noticed a behaviour change with the new update. Previously, I had auto crossfade on all the time, which is useful for my workflow, but I could use S (or ALT+click) to split a clip without it doing a crossfade, which is also useful for me. Now having auto crossfade on also crossfades S-splits. Is there a way to get the old behaviour back? Switching auto crossfade on and off is slowing me down quite a bit.

AMEN

By the sound of it, it's currently just a global scaling level for the whole application. But independent zoom levels for some views would be a great feature for the future. EDIT: Mainly I'm thinking that I like my main / track view as it is, but would like to scale up my console view a bit. That kind of thing.

Reading through a chunk of this thread and just idly wondering if there's still a block function in this version of the forum. Can't seem to find it. Asking for a friend.

I miss the Munch Button.

Is anybody excited about scalable UI? Cause I think that's kind of exciting. For one thing, it'll make touch screen use much more viable than it's ever been in Sonar, despite it having had a decent fundamental implementation for years. I've tried it a bunch of times, and only really been defeated by the smallness of many of the controls. I can see a lot of potential in that.

It does! You hold down ALT (on the console, not your keyboard) and press the "SEL" button for the track you want to branch. Repeat to get back to regular mode.

+1 to this. I'm a big fan of Spitfire, and a user of BBCSO, and it's great. But it is kind of twitchy, and they're not great on bug fixing. If you want a hacky workaround to explore, I've found that it sometimes behaves better in non-ASIO driver modes. But a lot is dependent on what interface and what drivers you have; I've not found a consistent pattern across different setups.

Whatever son.

Yeah that's it. The clip rectangle will shrink as you zoom out until it's only a pixel wide. Then if you zoom out more than that, it disappears entirely. I think two things would improve this; have the clip rectangles never vanish, and always be at least a pixel wide. And also, always have the dots extend to the last clip. Of the two, I think the dots thing is more valuable.

Project 5 was really cool, yeah. But Abelton Live ended up owning that section of the market, so I can see why they gave up on it. But a really important and under recognised part of the development of computer-based music production, IMO.

That's a good point, and I'll see if I can edit it. But if someone wants to say "you're not reading closely enough", well, perhaps they should be reading further than the title themselves.

Hey dude, read my answers again. Or, if you've nothing to contribute - which you don't - go and be rude and brusque elsewhere.

Yes. The dots are meant to show how far a given track extends, as I understand it. So if there's a zoom level where the clip is sub-pixel sized*, then ok, the clip disappears, but surely the dots should still be there? If they're not, then they're not serving their purpose. * arguably, it would be good for clips to always display at least a pixel width line at any zoom level. But either / both solutions work.

No, I know what the dots are, and I do want them to be displayed. This is about dots disappearing when they shouldn't.

I mustn't have explained very clearly. The dots are a good and useful feature, I agree,. The issue is that in the second picture, they stop too early, even though there are clips to the right of them. This seems to be caused by the zoom level. Once you're zoomed out enough for the last clip to become invisible, the dots leading up to that clip also disappear.

Here's a thing that's been a niggle for a long time, but I've never got around to documenting. So, among the things I do in Cakewalk is post production for audiobooks. And when dropping in pickups, I end up dealing with a lot of really tiny slivers of audio. Anyway, here's a view of the dots showing up to the last sliver in the third track (just to the left of the Now Time Marker) Now here's a slight zoom out from there. Notice how the sliver becomes invisible at a certain level of zoom. But more importantly, the dots now don't extend that far, and instead stop at a prior still-visible sliver. I realise this is a fairly fringe case, but would be really handy for me if it got fixed.

I've not upgraded to Windows 11 yet, but as I understand it, nothing about the driver model has changed. So the same process to get it working under Windows 10 should work fine.

Ah, re-reading your post, I see you're not currently using CBB. I suppose I'd say - it's free, so costs nothing to give it a go! Apart from time of course, which I realise is often a limited resource. But to answer your main question, fundamentally, all the big key features work. I use it all day every day to make a living, so that's one person's experience. There are quirks and annoyances, but aren't there always. I can't speak to the video editing experience, if you're talking about the integration with other hardware and all that. Outside of my area. But like I say, it's free to try. And I'd guess at that stuff being fairly standard Roland / Edirol integration anyway. Decent odds that Cakewalk's implementation of stuff makes little difference to that.

There are some bugs, to be sure. I find you can crash the program going back and forth between "EQ" and "Send" on the channel strip control panel, for example. I've just stopped using the send function. And there are oddities here and there. However - and I say this as someone who's been a vocal critic of how quickly support for the vs700 was dropped - it's pretty damn close to "full functionality". Certainly, the two things you mention, surround panner and the T-bar, both work perfectly well. Can you describe what problems you're having more specifically? There are a few of us vs700 users that refuse to quit on these forums, and I'm sure we can help you out.