Input and output names

[John T]

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:




 

[John Vere]

Are you using ASIO?  That list looks wrong to me. 

[John T]

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?

[John T]

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.

Edited July 1, 2021 by John T

[Jonathan Sasor]

55 minutes ago, John T said:

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.

The VS-700 system is a bit less common in that it has those extra ports that are listed before mic/line inputs 1-8 as you mentioned. As the driver goes, they are technically starting at ports 5 and 6. I get what you're saying though, but the new system is clearer for most other devices that have the analog 1-8 inputs listed first. The other driver names or friendly names are still there though, so aside from getting acclimated to the prefixes you're not losing anything. 

[John T]

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.

[John T]

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.

[Jonathan Sasor]

6 minutes ago, John T said:

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.

Because for years people have asked us for a system where they were confused by inconsistent third party driver names and how they were labeled only as left, right, and stereo. The port numbers actually will show you input port 1 on your device. It's beyond our control that Roland wrote a driver that put "mic/line 1" as input 5. Obviously it's not perfect for everyone at the moment, but the amount of work required to renumber the driver ports exceeded the scope of this update. @Noel Borthwick can give you more specifics.

[Noel Borthwick]

1 hour ago, Milton Sica said:

On the subject, at the time of the release of the early access version, I made considerations and questions about such nomenclatures. I was harshly questioned by the development engineer, wondering what "I would be missing if they were adding improvements". In the dialogue, he said that it is necessary to preserve the knowledge acquired in the use of the tool, even in the improvement of innovations, under penalty of loss of use.

Um I'm not what you used to translate my response to you but it wasn't anything like above. 
I responded to your questions asking you what you found missing from your workflow to understand why you didn't like it. Nothing more than that.  

[Noel Borthwick]

As Jon mentioned its been a user request forever.
Literally every audio application lists devices by their enumerated channel index. Here is how windows enumerates my RME device:

 

As you can see there are channel indexes listed in the enumeration. We do this in an identical way but have generalized this to all ports software and hardware since the same issues exist. The fact that some drivers choose to label their ports differently is completely out of our control since there is no way to retrieve that information.
Most drivers label their I/O's serially and then have a more descriptive string that shows something like Mic or Line.
The channel indexes are simply the identifier of the physical hardware mono channel the exposed list of inputs and outputs. In a multi I/O device it tells you exactly which I/O you are using.

Here is how it shows for me in preferences. I can see that the inputs go up to 30 channels and tally with the labelled values for all the analog ins.
For AES and ADAT they internally label them differently which is completely normal. ADAT 1 is physical output 15 and so on.


  

What is also new is that we display the actual left and right channel names for input ports. Previously you would only see the left channel listed. 

  

[John T]

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?

[Noel Borthwick]

When using friendly names the prefixes are not shown in the port name fields just in the menus.
Channel indexes are still required in order to correlate arbitrary driver names (some drivers have terrible names) to actual hardware channels. For example irrespective of the driver names if you have some I/O's deselected in preferences the channel prefix allows you to exactly know which input or output is being referenced.
Unfortunately there is no one size fits all solution because the names differ drastically across various devices and even across different driver modes. The indexing ties it together in an attempt to make it more universally understandable. 

[John T]

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.

[John T]

2 minutes ago, Noel Borthwick said:

When using friendly names the prefixes are not shown in the port name fields just in the menus.
 

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. 

[John T]

4 minutes ago, Noel Borthwick said:

Unfortunately there is no one size fits all solution because the names differ drastically across various devices and even across different driver modes.

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

[Noel Borthwick]

There is no loss of information in the menus, in fact there is a more actually useful information now than previous versions. All it did before was show the first channel name for stereo pairs. This was very confusing to many new users who interpreted this as missing inputs.

2 minutes ago, John T said:

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

We do hide the prefix automatically for port names. They are only shown in menus (as mentioned above even with friendly names there are use cases for seeing channel numbers). 3+4 is much more informational than (L+R) since a stereo pair is implied but the channel number wasn't visible before. i.e we haven't really added anything extra by replacing the L/R with the actual channels in use.
We're trying to get away from excessive options in the app...

[John T]

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.



 

[John T]

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.

 

[User 905133]

Ooops

Edited July 1, 2021 by User 905133
different location of names/numbers

[John T]

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.