Input and output names

[Noel Borthwick]

2 hours ago, John T said:

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.



 

Its not confusing to me at all. It shows me very clearly that Aux L is the 5th physical input on your device and that you have hardware inputs 1-4 disabled. These are the Fantom VS inputs right?  If you hadn't disabled 1-4 you would also see them listed in the dialog as 1-4 which would perhaps make more sense visually.
Irrespective its showing extra identification channel info that you would not have seen earlier that's all. This data can be very useful for troubleshooting esp for new users who couldn't correlate what they saw in the menus with the actual hardware before.

However I get your point that you don't like seeing numbers that don't correlate to the numbers reported by the device despite the fact that the numbers reflect reality   
 

[John T]

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.

Edited July 1, 2021 by John T

[Will.]

3 hours ago, Noel Borthwick said:

We're trying to get away from excessive options in the app...

I dont drink: but, I will definitely raise a glass to this right here. ? 

Edited July 1, 2021 by Will_Kaydo

[John T]

No disrespect to you, Milton, but I'd like to clearly seperate myself from this:

13 minutes ago, Milton Sica said:

And my feeling of hostility and "we're right" and "you're wrong" remains with regard to many approaches taken in this forum when it should be quite the opposite.
 

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.

 

[Noel Borthwick]

56 minutes ago, John T said:

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.

I'm sorry you find this silly but I think its due to your refusal to see that there are other points of view where this is useful. It has nothing to do with a programmer point of view since in fact these suggestions did not come from developers. 
I'm not sure how many other DAW's you have used - please take a look elsewhere. Pretty much most others exposes the hardware device channel index in the UI in some form or another so if anything us not doing it was the non standard feature. I posted a screenshot of Windows but we did check how several other prominent DAW's do this. I'm not going to post screenshots here but you are free to check them out for yourself.
Keep in mind that we focus on features that need to be intuitive to users coming from other platforms and with different experience levels. Occasionally this means that we have to change how we do things in ways that existing users may not initially like. Its an unfortunate part of making progress.

I think we're beating a dead horse here however. As I said I understand you don't like it.

[John T]

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.

[Noel Borthwick]

For clarity here - (without arguing the point further)
The ONLY change is using numbers instead of the Left Right Stereo convention and being consistent about this everywhere.

Here is what it was before:

The Left Right and Stereo were Cakewalk specific prefixes because we group everything into stereo ports by default (something many other users coming in from other DAWs dislike btw).

And here is the same I/O listing now:

Compare the two - many would say that the new display is cleaner and easier to understand.
We changed that to something more useful like 1, 2, 1+2 which is pretty much the de facto standard for naming in other applications. Left right and stereo are completely implicit here because they are in groups of three and the numbers automatically show that in a more compact way.
We did the same to all I/O's for devices and virtual instruments so that new users have a consistent user experience.

 

[John T]

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?

 

 

 

[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.

Edited July 1, 2021 by John T

[jackson white]

5 hours ago, Noel Borthwick said:

We're trying to get away from excessive options in the app...

amen. and thx.

[Terry Kelley]

Define excessive. I like lots of options but recognize we could get in a situation where things stop working and figuring it out is overwhelming. But I don't know what excessive is.

[John T]

It can never really be precisely defined for this kind of thing, I think. I mean, I think Reaper is really impressive, but I rarely use it unless forced to by work requirements. And that's exactly because every long menu and huge, 20-button pop up box in Reaper makes my eyes glaze over.

At the same time, I know there are people who love that degree of reconfigurability. So there's the question-of-taste aspect.

On top of that, there's the more objective fact that it is easier to find your feet in an application that demands you make technical decisions you might not have a view on less often, or perhaps never. Garage Band is at the far extreme of this, happily sacrificing flexibility in favour of ease of use.

For what it's worth, I think Cakewalk is more and more successful all the time at presenting a friendly default top layer, but having lots of underlying flexibility for advanced users.

So I think "staying away from excessive options" is a good aspiration, and one that's been yielding good results. I don't think it should be a dogma, though. But I think they get the balance right most of the time.

 

[Ted K. Ling]

Hi, I'm reading this with interest ...

I'm using SSL hardware with RME cards which give me (max.) 192 channels.  I have not yet updated to this latest version, but will make sure to take screen shots of before and after.  I spent quite a bit of time making "friendly names" easy to read in the dropdowns, so I'm interested to see if this new "feature" will be just as easy to understand after the update.

I'll comment more later.

[John T]

Why close it? Anything can be discussed and thrown around constructively as long as anyone wants to if everyone just relaxes a bit.

You seem to be saying "I have decided Cakewalk operate in a closed and hostile manner, and they should prove me right by closing down a conversation that I've decided they're not willing to have, despite them being here having it".

Honestly, I don't think this stuff is helping anything.

[Noel Borthwick]

2 hours ago, Ted K. Ling said:

Hi, I'm reading this with interest ...

I'm using SSL hardware with RME cards which give me (max.) 192 channels.  I have not yet updated to this latest version, but will make sure to take screen shots of before and after.  I spent quite a bit of time making "friendly names" easy to read in the dropdowns, so I'm interested to see if this new "feature" will be just as easy to understand after the update.

I'll comment more later.

Ted thanks I would be interested in your feedback. I also have an RME albeit with 40 channels. What is cleaner now is that channel names are properly reported for all input pairs in Cakewalk and you can specify per channel friendly names if you use that feature.
A couple of users have reported that they would prefer to number their friendly names manually rather than see the automatic numbering we have now. We'll consider removing the auto numbers in the menus for friendly names for next release. 

[Noel Borthwick]

48 minutes ago, Milton Sica said:

 

I don't know if there is a manager able to close topics in the forum.

If there is, now is the time to do it.

There is no need to close a topic where there is constructive feedback being given by users. We listen to all feedback. Discussion is necessary to understand user requirements. Perhaps you shouldn't read this thread if its bothering you?

[Will.]

That's because this is the global input reading. 

Edited July 2, 2021 by Will_Kaydo

[John T]

^ I don't understand this post at all.

[Will.]

Just now, John T said:

^ I don't understand this post at all.

Cakewalk right now display it's Inputs and Outputs as what the global language for this is in most DAWs. 

[Base 57]

19 hours ago, Noel Borthwick said:

Compare the two - many would say that the new display is cleaner and easier to understand.

I think the new way is an improvement. I have 64 ins and outs that are split about evenly between mono and stereo. So having the friendly names for mono ins and outs is very helpful to me. I especially like the way they are displayed in the Inspector and console view. But to straddle the fence here, IF there was an option to not show the numbers in the menu I would choose it. But they are not so distracting that I can't get on with my work.