John T

In the example you post, the numbers aren't confusing, but they are redundant and unnecessary. I appreciate that there may be cases where this isn't true, but in your posted example, they add nothing. The improvement comes from the ability to name the individual ports in a pair, not from the numbering. In my example, the numbers are counter-productive. Surely this is a case for a user-selectable option.

With respect, I can only refer you back to the picture of my system that I posted. Do you seriously say this - I mean specifically this example - is clean and easy to understand?

All I'm saying is, previously, this numbering was not mandatory, and that specifically was better than it being mandatory. I have no objections to the functionality in and of itself.

No disrespect to you, Milton, but I'd like to clearly seperate myself from this: I might not have pulled this off, but I was aiming for a humorous tone. I don't see any hostility from the developers here. I think Cakewalk's developers are very constructive and helpful, and attentive to user feedback. Noel in particular has directly helped out me and many others going back for many years. I just think it's taking some time to reach clear mutual understanding on this specific thing. It happens sometimes. No big deal.

Again, I think this notion of "reality" is misplaced. This seems to me to be a tension between the "programmer model" and the "user model". I'm a producer and recording engineer. "Channel one is actually port 7, you know" is some internal tech stuff that has nothing to do with what I'm trying to achieve when using the program. I plug a mic into input one. It's labelled "1" on the back of the box. The automatic driver naming, as ugly as it is, also calls it "1" (or, ok, "Left 1-2" in the old approach). I call it "one". The only area of disagreement is Cakewalk is calling it "7" and not letting me edit that. You can tell me 7=1 makes more sense and is more "real" all you want; it's an obnoxiously user-hostile state of affairs. I hope sense prevails at some point. Really frustrating to be going around in this rather silly circle on this. Anyway, happy seventh equals first of July to everyone.

Hmm. I wonder if we're all consistently talking about the same thing. The case where Noel said that prefix numbers were hidden is in the drop-down menus for port names in channel strips. These things: The things you're talking about above are the automatic names put in the track name field for hardware outs. I don't *think* that changed with this update.

Also, I am fully on-board with not having excessive options. BUT! In this case, as you say, there's very little the Cakewalk application itself can do about the wild west of different manufacturers' port naming. So doesn't that make this a case where user-configuration is in fact a necessity, and not an excess? Nothing to stop having what you have as the default.

I don't wish to seem pedantic, but the below, which is the best state I can edit the names into for menus, is objectively worse and more confusing than what I previously could see. And I can't see how anyone could argue otherwise. It's weird to keep getting told it's better. It isn't.

I see what you're saying. Does seem like a "Hide prefix numbers in friendly names" check box would be the winner here.

The thing with that, though, is that the menus are where I want to be able to quickly choose and click on an option. So the menus are precisely where at-a-glance-readability is most valuable.

I feel like I should digress to briefly say the latest update seems really good so far. It must be a weird experience to have a big cycle of effort immediately followed by complaining. I think I may be coming across badly here.

OK, I can see how that works ok for some decently large number of interfaces. Makes sense. However, I still reckon this numbering being mandatory in friendly names in particular doesn't actually add anything, especially alongside the L / R naming enhancement. The user is now fully empowered to add their own meaningful friendly names, apart from the fact that they now have numbers stuck on the front, which may or may not be confusing, in a way that the application can't change. Except by making the prefixes optional. Do you see what I mean?

It's still not clear to me what the prefix adds for anyone. Under the previous system, people could make the friendly names whatever they liked. The new pipe separator thing is a good addition. but enforced prefixes is the removal of flexibility, and in cases like mine, actively reduces clarity.

No, come on. I am losing something. "7=1"is a wildly unhelpful thing to appear in a drop down list if trying to work efficiently. If the argument is "look, you're the fringe case, so just have to deal with it", I don't rate that argument much. If it's "this thing that you don't like is actually something you should like", then I rate it even less.

To clarify a bit, I know why the numbers have come out like that. Internally, the VS-700 considers its Fantom synth to be 1+2, the ARX expansion input to be 3+4, and its AUX input to be 5+6. So we only get to the actual input "1" at what the VS-700 considers to be "7". Seems to me that the *entire* point of a "friendly names" system is so we don't have to be concerned with the interface's internal mapping. But suddenly here it is. It's like a previously solved problem has been un-solved. I realise I may be missing something, but I genuinely can't work out what the purpose of this is. Also, while I appreciate the V-700 system isn't supported any more, I feel like it's not asking for the moon on a stick for Cakewalk branded hardware to not appear like this in, um, the Cakewalk application.

Heh, indeed it does look wrong. But yes, using the correct and official ASIO driver. I'm really unconvinced of the merits of this prefix system in the specific case of hardware ins and outs. As far as I can see, the best it can be is redundant, ie: telling you what's already obvious. And in a case like mine, it just adds confusion. What's it actually for?

I know this was discussed quite a bit in the early access threads, so apologies if I'm misunderstanding something. But... what? I don't get this at all. This seems like an egregiously weird numbering system to impose:

I don't know what y'all did with the plug-in menu fonts, but it's like angels are blowing gentle clouds of comfort and joy onto my tired eyeballs, and I want you to do it to the whole program. Also: didn't expect to like the waveform outlines, but that's really visually agreeable "in the flesh" as it were. Automation display improvements also really great. Has something about the editing functionally changed? Perhaps an illusion because of the nicer visuals, but it feels really great to edit with all of a sudden. Not had something this good for free since the last time I robbed a bank*. * have never robbed a bank, it's a joke.

I think you should consider whether the other tracks aren't fine and the vocals actually are. -18 to -12 is a good benchmark for the raw recording level of everything, not just vocals. It sounds to me as if everything else is too loud. This assumes that other sounds are coming from recorded instruments and not plug in synths and so on, but a similar principle applies.

I've noticed that I can't use the mouse wheel to scroll the control bar modules any more. Is that a setting somewhere, or has it just been removed?

Asking for a colleague, and as we don't have anything like old "computers and hardware" sub-forum any more, thought I'd try here. I'm really out of the loop on this, as I build my own desktop computers and have done for years. Who are the current US-based suppliers / builders of laptops that are set up well for audio? Got an audiobook narrator who I work with who's had a hell of a time with DPC latency glitches on an off the shelf system. She works enough that she can justify paying a decent premium to make the problem go away. Any recommendation? Thanks all.

Got a minor niggle with with the new ALT+X to toggle Aim Assist labels on and off. The setting defaults to off and doesn't persist, either globally or within projects. I do a lot of editing work, and mostly want it on all the time. Would be really nice if it could persist at least within a project. At the moment, having it on, but saving, closing and reloading the project (not even the whole application) will switch it off.

I think this was updated in the previous hotfix, nit the latest update, so apologies if that's the case. Either way, it's still the same in the current version: The new split behaviour, that creates a crossfade on a split is cool. However, it doesn't follow the default selected crossfade for most crossfade options. For example, I generally use "Slow out, fast in", and that becomes "fast out, fast in" when splitting. The first couple of options work ok, but the rest give different (wrong) results. Is this just me, or has anyone else seen this?