Jump to content
John T

Input and output names

Recommended Posts

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:

image.png.8c5a9cf161124ba9098e59bfc5ac1609.png

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.

  • Thanks 1

Share this post


Link to post
Share on other sites
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.



 

cakewalk input names 2.png

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 :)  
 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by John T
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Will_Kaydo
  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, John T said:

This seems to me to be a tension between the "programmer model" and the "user model". 


 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.

 

I fully agree with you.
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.
In these various approaches, it does not seem to me that the user's manifestation instrument is being validated.

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:
image.png


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:

image.png


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.

 

Share this post


Link to post
Share on other sites

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?

 

 



 

cakewalk input names 2.png

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by John T
  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Noel Borthwick said:

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

amen. and thx.

  • Confused 1

Share this post


Link to post
Share on other sites
12 hours ago, jackson white said:

amen. and thx.

Without wanting to generate more controversy on the subject, I would like to better understand your opinion.

Do you agree that an application should not have excessive options?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites
1 hour 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.

From what I understand from the application engineer's statement ("(without discussing the point further)") this debate is already closed by the option for the developed algorithm.

It doesn't seem to me that there is more of a positive environment for the contradictory or opinions that diverge from the implemented one.

This only comes to confirm and confirm my perceptions of this Cakewalk Bandlab space.

With respect and consideration for developers, this is the statement.

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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?

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...