I said if applied properly looks actually very clear and good. I didn’t say anything about better, worse or any other evaluation.
The emphasis is on the second sentence.
You should clearly reconsider your strategy on how to cite. Or focus on doing one thing right, when you read and cite someone’s text.
I personally favour material design from Google. And as for newmorphism it’s just shadows applied (yes, design). This makes it look like elevation with a smooth ramped gradient. you will find plenty of examples to compare. Not the point here
I didn’t say anything about dislike here. Seriously guys and gals, you need to read more carefully and don’t let your mind trigger something when you read keywords. Please read again:
Summary:
Impropmptu
on of the best modules
no need for different version
compress the UI to as little units as possible
add a button to expand the UI
This is and always was an objective measurement.
I repeat again for ALL OF YOU.
It is not about the DESING it is about the UX (User Experience) and by this the complete workflow. Is design part of it, yes? Does it matter so much?Maybe, but it’s not the problem here.
My problem with the Skeumorphisms applied in rack are not related to design. I want to have a healthy discussion for everyone interessted in it. This is neither a blame thread nor a you are stupid thread. I’m just pointing out things which could lead to improvements. No need for anyone to adapt or feel blamed.
We don’t need to stick to hardware limitations like size and matter. We can make the modules look like the hardware but don’t need them to behave exactly like hardware. There is no reason to restrict a module from expanding to fullscreen, or have drawers which hide cables and ports. Sections of a module that completely fold and make them disappear… Alternate UIs on top of a patch for custom UI (Like in Reaktor) …
Just some examples. If you don’t like my ideas and findings, I understand. I learend early that I have a very unique way of viewing at software and find spots others can’t imagine. So I’m here to share some ideas.
It’s interesting you chose Impromptu and MindMeld as your examples because (as you probably know already) they are both coded by the same developer - they just have very different philosophies.
The philosophy behind Impromptu has always been that the modules are designed like hardware and could be fully reproduced in hardware (with all the limitations that implies) - so a full screen UI would not fit with that philosophy at all.
The philosophy behind MindMeld is essentially the opposite - they are designed as software modules for a digital platform and we’ll happily use any advantage that platform offers without any artificial limitations imposed.
Regarding your idea of having one version of the mixer and dynamically adding tracks as needed - that was certainly something we considered very early on, and it seems like a good idea at first but there are 2 main reasons we didn’t do it.
The first is complexity - both code and UI - there are so many different options, settings and signal routings in the mixer that having dynamic tracks link into all of those would have been extremely complex to code (it was complex enough already). It would have also caused UI complications for Inserts, CV inputs and Direct Outs for example. Also Auxspander channels would have needed to be added dynamically at the same time as tracks and they are designed 2 tracks to a column so that would have posed another problem.
The second reason is that modules that dynamically change size are not particularly welcome in Rack iirc.
This is an important part of what Rack is all about, it is precisely for people who like cables and ports and knobs with a bit of space in between them for your fingers, even if you are using a mouse. And to see all those in front of you, almost like a real Rack (not in some hidden panels) is the great thing about Rack. Anything else would be another software, which people are free to make if none exists to their tastes, but changing the foundational cement of what defines VCV Rack is not a thing you will find many Rackheads are enthusiastic about.
Because I count them to the best in class. And it was also obvious for me they were build to be implemented in hardware. That’s exactly the criticism about the UX. They are still awesome modules, best in class. I just dislike the typical hardware fiddling of this kind of modules. I personally would favor panels that switch completely. Click a button, show a different panel. I know, you can’t do that in hardware. choice by design … I feel you. I don’t say your modules are terrible. I say: I don’t like the indirections necessary to use them. MindMeld and Clocked are in my template so a certificate of how good they really are. So your reasons are easy to follow. From a maintainers point of view I get it.
I’m just saying the UX would be nicer from my point of view. But this is just me. And like I repeatedly said: Your modules are awesome.
Yes you did. A deliberate choice of provocation. And from the response I read, this triggered a lot of the readers. I shouldn’t have been writing it, probably because the reader, you included feel offended by this. So I’m sorry to everyone who felt offended by this.
I don’t blame anyone for doing what he is doing. Steve pointed out his choice for why you guys did what you did. I did not blame you for your great work on the modules. Or the choices I dislike.
I said like you cited corretly, and I put it into context again.
I ranted about the failure of easing hardware limitations in software, citing Reasons evolution and drawing a analogy to Rack. You can’t discuss the complexity of key combinations you need to train away vs. direct access in software with clear guidance of good UX design choices. And as a final verdict, I said:
“No one on this earth should do skeumorphism in 2020 if he claims to be smart”
There is no blaming in what you do. I appreciate every module released in rack.
I translate: You should not copy limitations from hardware to software. I don’t call this smart. what I call smart is copying the hardware to software and redoing its UI/UX to benefit from the new possibilties
I didn’t ask to change that. I said an option to expand or hide. This broadens the user base and attracts even more people to the ecosystem by giving options, not restrictions.
Again … guys. please read more careful. I don’t imply changing a good working ecosystem. I’m arguing about giving more value to it. Like dark themes. And we all know how this discussion went…
You are arguing for a specific style of how to do things. This is the way (to cite the mandalorian here, because its awesome). I’m just saying. Give the ecosystem more options and make it even better.
But you guys just read between the lines and draw conclusions without even asking back
Keep on discussing. I’m glad to anwser all your findings.
I think the key issue is that it’s hard to make music when your physical interface is a mouse and typewriter keyboard. To make VCV or any other software synthesizer useful for musical expression, I need to pull the controls out to physical devices. That was sort of my point in citing the Brian Eno essay. This is why I hacked a way of stuffing floats into VCV (and other synths) from outside non-MIDI controllers. It’s why I did some work on low noise pot digitizing from the Arduino. I need to grab something real when I’m playing. I need a piano keyboard to bang on. I think even a touch screen wouldn’t quite measure up no matter the UI design. For building an instrument, I strongly believe the visual metaphor created with VCV Rack works for the majority. I know it works for me, and it helps me visualize the signal flow. It’s all DSP underneath, but presenting it as knobby modules and wires creates a mental model with a long precedent. That has value even if it is imperfect.
That’s the thing with options though, too many of them and the software becomes a monster. It’s insidous even, and at some point it will not attract more people but drive away those who appreciate the current paradigm and it’s inherent simplicity.
But to be fair, I understand your point. It would be an interesting exploration, I just think it should be done in another project, by someone else that has the time to invest in this.
The current way Andrew is developing Rack has my admiration on many levels, not only for what he has done in Rack, but for what he has not done in Rack. The amount of feature requests he gets is mind-numbing, and at some point decisions have to be made. If the creator has a vision for a consistent UI/UX that he wants beginners to not be intimidated by, then all the better as far as I’m concened.
One could even argue that everything your are suggesting could be enabled or activated under one single “power mode” switch, which would take only one small menu line. So everyone would be happy. For people who don’t have the code in their hands, it may seem easy to think of adding this or that feature, but things are also hard to do sometimes, and hard to maintain if they are not done right, and at some point something also has to be said for quality over quantity.
the OP calls the UI/UX of Racks skeuomorphism a failure. if that was the actual case then Rack wouldnt have the growing community it has.
i think this thread has run its course. using blanket statements with the words “stupid” and “failure” arent going to result in the “healthy conversation” that you claim to want to engage in.
migrate to Puredata or Plogue Bidule if Rack UX isnt your thing and we’ll all stay here and continue to enjoy this stupid skeuomorphic failure.
Moderator here: let’s keep it civil or this thread will be locked. No need to keep replaying the words stupid and failure. The author has attempted to apologise if I read it right, let’s move on past the name-calling and keep it to a debate about skeuomorphism.
The trouble is that it isn’t a debate. It seems to me that someone’s got religion, and he’s on a crusade against those he perceives as infidels namely most of us. That it’s got more than a few noses out of joint is not at all surprising. For the bulk of us, I really don’t think there’s a useful argument. We use VCV Rack precisely because of rather than despite what it offers. I think you are being very generous in your reading of the OP.
The trouble is this is much like someone entering an emacs chat room and vociferously complaining that emacs is bad because it doesn’t behave like Sublime. This isn’t going to go over well with long time emacs users, and it only serves to promote acrimony. In short, such an entry forestalls legitimate debate.
