-
Posts
158 -
Joined
-
Last visited
Everything posted by John T
-
I think all the functionality is there; in that sense, it's not limited. But you're right that it could be made more friendly and intuitive. And I know Cakewalk of late are very keen to improve user-friendliness.
-
Yeah, I totally get what you're saying. If you read it a certain way, it sort of sets you up to think "should I open the folder? Is that a thing that I need to do?" UI and workflow design is full of these kinds of things. Perhaps "update now / update later" is what this box should be asking. Or maybe it should just automatically update after downloading.
-
I suppose the assumption is that you'll either open the folder to install from there OR install from in the program. So the pop-up is a fork in the path, not a hub, as it were. "Take a look and then install from in the program" has never occurred to me, but I see what you mean.
-
New format for this in the latest update is great for me, thanks so much. Really clear and readable, and LSR indication clearly separate from the name is a great addition.
-
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.
-
^ I don't understand this post at all.
-
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.
-
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.
-
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?