Input and output names

[Noel Borthwick]

@Base 57 to clarify are you referring to suppressing the numeric channels only in the friendly names case or even when friendly names are off?

[John T]

27 minutes ago, Will_Kaydo said:

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

Sort of, sort of not. The thing we've been talking about is the prefix numbers which the new update has added. None of those screen shots feature anything like that.

[Base 57]

6 minutes ago, Noel Borthwick said:

 to clarify are you referring to suppressing the numeric channels only in the friendly names case or even when friendly names are off?

I can't imagine not using friendly names so I guess I would only suppress the numbers with them. 

Thinking about this I'm going to rename the AUD file and see what it looks like without friendly names. I'll report back in a bit.

[Noel Borthwick]

Just now, Base 57 said:

I can't imagine not using friendly names so I guess I would only suppress the numbers with them. 

Thinking about this I'm going to rename the AUD file and see what it looks like without friendly names. I'll report back in a bit.

Oh you dont need to do that  Just turn off the checkbox to show friendly names,

[Base 57]

Doh! 

Too late. It's already done (and done er).  This screenshot shows the Orion 32+ inputs without friendly names.

This should definitely solve the problem of newcomers not being able to find their even numbered inputs. And also please everyone in the department of redundancy department. ?

[Noel Borthwick]

DOR indeed  However keep in mind not all audio drivers are nice enough to have names that properly show their channels and this also varies drastically by driver mode.

For example a device with a single stereo input may just call it "Input". Now if we didn't have the numbers in the menu you would get something like:

Input
Input
Input

Instead of what it shows now.

1: Input
2: Input
1+2: Input

Just to illustrate that there are cases where numbering is not redundant... This stuff is a complete maze with the differences between devices, driver modes, and virtual instruments. I can barely get my head around all the permutations of things. Hence we decided to simplify and use a uniform numbering method. Anyway we'll collect more feedback and if there is a way to solve it without breaking some other case we'll improve it for next release.
So far its looking like the safest approach is to disable it only for hardware ports when friendly names are used, since the user has control over the naming there.  i.e even if it led to the bad case listed above you could go in and rename the ports to resolve it. 

 

 

[Xoo]

1 hour ago, Noel Borthwick said:

For example a device with a single stereo input may just call it "Input". Now if we didn't have the numbers in the menu you would get something like:

And here's a good example of why the current system is no better than the previous one: it's a *stereo* input (or output) but now says 1+2, which is more confusing, potentially, for the new user who is most likely to have an interface (or onboard sound) with a single stereo I/O.  Yes, the old way wasn't perfect, but the new is differently bad in my opinion.

My own issue is that I have essentially fixed connections to an 10 in device (ignoring outputs for now*).  They are labelled 1-8 on the hardware, but appear by default as stereo pairs in the hardware's software mixer - they can be split into mono.  Now I have them connected so that 1 and 2 are mono, and 1+2 would never be used, as it's an illogical combination; all the others, I have as pairs (3+4, 5+6, 7+8 - 9+10 is SPDIF which I don't use), and the others are all used as stereo pairs, so mono for 3-8 are inputs I'd never select.

Even with the pipe delimiting function (thanks for this!), there is no nice way to show this neatly in CbB that I can see.

I *want* to see:

1 - Instrument
2 - Mic
3+4 - Synth 1**
5+6 - Synth 2
7+8 - Synth 3

What I actually end up seeing is either:

1: Instrument
2: Mic
1+2: Instrument + Mic
3: Synth 1
4: Synth 1
3+4: Synth 1

Or:

1: Instrument
2: Mic
1+2: Instrument + Mic
3: Synth 1 L
4: Synth 1 R
3+4: Synth 1 L + Synth 1 R

Urgh.

If the I/O were exploded completely and we could select and name at the mono or stereo level, I'd be more than happy (it would also make it less likely to select the wrong track input, which I'm sure we've all done, as we have fewer distinct options available), and I think it might also help address other people's issues that have been raised.

* Interestingly the first pair of outputs is labelled L and R on the device, then the others are 1-8; CbB actually displays the second pair, by default, as 3+4: MOTU Audio ASIO Analog 1-2.  Not confusing, no sirree.  And none of the outputs are individually addressable, so are always stereo pairs in the MOTU software mixer, so having them appear as L/R as they did previously was more consistent with the hardware (obviously, this may be hardware/driver specific).

As an aside, the inputs are also similarly named by default, so I have 3 inputs named <something> 1, but are named 1+2, 11+12 and 13+14 respectively by CbB!

** The names have been changed for simplicity.

Question for anyone who has multiple interfaces of the same type running under the same (ASIO) driver: does CbB display the second devices ports (which would be labelled 1, 2, 3, 4 presumably on the hardware) as n+1, n+2, n+3 etc (where n is the number of ports on the device)?  This seems...unhelpful if so.

[Noel Borthwick]

What you are proposing isnt possible to do today because inputs are always grouped as stereo pairs. 
This wasnt an attempt to change that - all I did was improve the naming within the current scheme.

[petemus]

Since we already have the option to define the names separated by a '|', it would be quite easy to add a way to exclude the number from the menu item text as well.

E.g. start the friendly name with a minus sign, asterisk or such to make the numbers disappear, it would just be an extension of the "syntax". This would make it possible for the ones that don't want the numbers to show at all to hide them.

Cumbersome and techy, yes, but possible for them who are irritated and confused by the odd numbering scheme provided by the driver.

Just my 1,98 cents here...

[Noel Borthwick]

21 minutes ago, petemus said:

Since we already have the option to define the names separated by a '|', it would be quite easy to add a way to exclude the number from the menu item text as well.

E.g. start the friendly name with a minus sign, asterisk or such to make the numbers disappear, it would just be an extension of the "syntax". This would make it possible for the ones that don't want the numbers to show at all to hide them.

Cumbersome and techy, yes, but possible for them who are irritated and confused by the odd numbering scheme provided by the driver.

Just my 1,98 cents here...

I will likely just remove the numbering prefix in the menus when using friendly names. As I explained above I didn’t remove it originally because some drivers don’t provide descriptive titles so I was trying to make less work for users to tweak the name. No need to add more modifiers. I wasn’t aware that the friendly names feature was so popular

[Noel Borthwick]

2 hours ago, Milton Sica said:

Thank you for your consideration in answering me.

I must have misunderstood what you meant by "(without
further discuss the point) ".

In Brazil where I live when a Senior Manager says "(without
discuss the point further) " there is no longer any reason to go back to the same subject.

The continuing demonstrations in this topic demonstrate that, like me, many users have been confused by the new implementations and approaches brought to port naming.

Yes its was likely lost in translation. I was trying to tell the user that I respected his personal reasons of wanting to remove it but not his reasoning that it was useless (because there are situations he wasn’t aware of where drivers do not provide descriptive names)

With any change to common UI there is a potential for confusion. Its important to learn and also let users work with it for awhile before making “gut reactions”. We will continue to improve this in future updates.

[Starship Krupa]

It doesn't seem like any of the people who begged for the port naming to be corrected have chimed in here. The OP and the other people complaining  can't see how this change would  help anyone, so I am here to enlighten you with some background, the justification for doing this.

I say "corrected" because I have an interface that has 8 inputs on the front. They are labeled 1-8. They are not labeled left, right, up, down or anything else. As follows, this is how my inputs 3 and 4 were displayed to me in Cakewalk:

• Left FirePod ASIO x64 FP1 - Input 3L
• Right FirePod ASIO x64 FP1 - Input 3L
• Stereo FirePod ASIO x64 FP1 - Input 3L

Tell me which of those inputs is 4 and which is 3. Then tell me how long it took you to figure it out. If the answer is longer than "instantly," then having a "4" that corresponds to input 4 on my interface is an improvement. Whatever input you think it is, notice how the numeral 4 appears nowhere in any of the choices. The second choice in the list is labeled both "Right" and "L." My interface has no "stereo" inputs either, it has 8 mono ones, so "Right and "Left" and "L" are useless unless I am going to look up at the interface and count them from left to right instead of just seeing the correct number on the screen. I don't mind Cakewalk grouping them to indicate what inputs will be tied together for recording stereo tracks, but Input 3 on my interface is not a stereo input and there's no input labeled "3L."

The thread below is one of my earlier requests on the subject, and I will tell you that since that time, I had one session where I was trying to record a vocalist and wound up with the singer's mic connected to "Left FirePod ASIO x64 FP1 - Input 3L" instead of  "Right FirePod ASIO x64 FP1 - Input 3L." However, there was a mic plugged into "Right FirePod ASIO x64 FP1 - Input 3L," across the room in front of a guitar amp.

The minutes that it took me to figure out why I could hear the singer at a low-amplitude thin sound, but tapping on the mic didn't do anything were verrrrry lonnng minutes. This came out okay in the end, after I apologized to the singer for the extra time I took running around looking foolish.

There have been two other times when I was trying to capture live drums and at the end of the take, one of the 4 channels was flatlined because I armed the wrong input. They were just me recording ideas while I was practicing, but should serve to illustrate the kind of thing I was running into. Having your inputs mislabeled isn't just inconvenient, it can result in failures to get a good capture. Who knows if my singer would have performed better if he hadn't had to stand there while I ran around jiggling cables. It did actually bite me in the asterisk as I thought it might.

So if you think making the change was "a bad idea," you're wrong. It was an excellent, necessary idea. It looks like the implementation isn't working for everybody, which in a feature like this is probably not unexpected. So as far as "it wasn't broken so why fix it," okay, maybe it wasn't broken for you.

It's valuable to know that the new implementation isn't working well for everybody, and it looks like the developers are going to take steps to change it. Relax, I had to live with it the old messed up way for years. The new messed up (for you) way will likely be changed in 30-60 days.

It seems like the preferred option is to allow suppression of the port numbers in friendly names. I'm sure they can handle that.

 

[Noel Borthwick]

@Starship Krupa thanks for your analysis of the original problem. These are exactly the issues we fixed that have been around for about 20 years.
We have literally had hundreds of support calls and reports about this over the years. Even though it was a huge PITA to fix I decided to do it since I was making similar changes for synth port naming which was potentially an even worse issue with multi-out synths like Kontakt.

[Ted K. Ling]

Been away for a few days, so am coming back here after updating today to the latest version and to answer Noel's request for feedback.

At first glance, I was not expecting such a deep change to the input/output naming.  I'm still looking and will post screen shots tomorrow (I have rehearsals today).

Basically, it has changed a lot for me and I'm not too happy about it.  The extra (sequential) numbering has messed up my carefully prepared friendly names.  I run a hell of a lot of outboard equipment collected over the years and this has been reflected in the naming of the channels, etc.  At the moment I think I would join the "please make it optional" movement as this is an intrinsic change.  More tomorrow.

[Ted K. Ling]

 So, to continue, here are BEFORE (on the left hand side) and AFTER update screen shots.  As you can see, I've lost all the "Left" and "Right" naming and all channels after 24 are numbered differently, with the ensuing confusion .  I'm not sure if just removing the automatic numbering (as Noel [I think] has suggested) will restore the "Left" and "Right" naming as in the BEFORE pics.

To clarify:  I use a 512-point patchbay to connect all my gear and the labelling matches the "friendly names" I use(d?).

@Noel Borthwick I know you and your team have put a lot of effort into this and I also understand those who think the changes have helped them in their routing issues.  I've never had any routing issues but may have now.  I therefore would like to have the new system made "optional".  Please consider and thank you.

 

 

 

 

[Ted K. Ling]

On 7/3/2021 at 4:14 PM, Noel Borthwick said:

 I wasn’t aware that the friendly names feature was so popular

It was the only way to get over the issues back then and is still IMHO the way to go if you're not happy with the sometimes "over the board" long interface names.  The assignment of logical names to physical IO was/is a great feature.  So thank you Noel.

[Noel Borthwick]

I’ve made a few tweaks to the port naming logic for the next update.

• When friendly names are used it will no longer show the generated prefixes and leave it upto the user to name them appropriately.
• The I/O channels are now only shown in the menu and not in the actual port name field to make the name even more compact. (it will be shown in the tooltip)
• The channel display in menus now separates the channel from the port name text from the driver more clearly by using columns
• You can choose to display the I/O channel information as a prefix or suffix to the port names showin in the menu.

Hopefully these changes should make it even more useful. Regarding arbitrary ordering of ports, while its technically possible it would be quite complicated since we already have abstraction for ports because you can already choose to disable channels that are not in use. Adding reordering on top of that would make my head explode

 

[Ted K. Ling]

Thank you Noel (and team).  Great work !

Edited July 10, 2021 by Ted K. Ling
Quote didn't work ... never mind.

[Will.]

On 7/9/2021 at 1:57 PM, Noel Borthwick said:

I’ve made a few tweaks to the port naming logic for the next update.

• When friendly names are used it will no longer show the generated prefixes and leave it upto the user to name them appropriately.
• The I/O channels are now only shown in the menu and not in the actual port name field to make the name even more compact. (it will be shown in the tooltip)
• The channel display in menus now separates the channel from the port name text from the driver more clearly by using columns
• You can choose to display the I/O channel information as a prefix or suffix to the port names showin in the menu.

Hopefully these changes should make it even more useful. Regarding arbitrary ordering of ports, while its technically possible it would be quite complicated since we already have abstraction for ports because you can already choose to disable channels that are not in use. Adding reordering on top of that would make my head explode

 

Sorry to revist this Noel. Not sure if i'm suppose to create my own Topic in feedback for this, but seeing that here is a thread open on this - I thought to add it here. 

Can we reorganize the menu too in the next up coming updates? I've put some examples together. 

EXAMPLES:

 

Some alignment issues. 

I think this makes for an easy read. 

Edited July 11, 2021 by Will_Kaydo

[Noel Borthwick]

Honestly, that is subjective depending on whether you prefer seeing stereo or mono first. I like the bold text but currently it isn’t easy to do. When we switch to the new menuing system in the future we can consider it.