hibidy wrote:One of the things I've noticed is that there is a difference in the "makers" of DAW's vs the "users"
There will always be odds because some people want general comforts, some don't care, and there are always a ton of people who back up the idea that we don't NEED onwards and upwards.
In all these years (which was about the time I joined KVR) I've seen and been a part of dramatic change, but in fact, nothing has changed that much. For example, if tracktion had continued development under Jules way way back, I don't think I'd have gone through the MARATHON of hosts I've tried. When mackie got involved it a) died b) didn't work all that well for many people.
So the idea that a host doesn't "need" x or y is an endless debate but I think some of the things missing are critical for a modern DAW.
Yeah, good points.
For me it boils down to the balance between developer vision and user needs/vision and how well the communication works between those.
To create a full DAW you need a lot of motivation and a rather large amount of headstrong rigour to keep on track and don't lose focus every time a user or even a large group of users decides to give you pressure in a certain direction.
Since you need to keep the whole application in focus and how everything works together, things are way more complicated and have much more implications down the road as the typical user is aware of or cares about (I explicitly include myself here ).
At the same time, the developer needs to be open minded about things, since of course he has his own preferences and some of them may NOT be motivated by how to best do things, but simply grounded in his own interests and bias.
You can see this clearly in some of the smaller DAWs, that struggle endlessly uphill since they somehow miss some basic things that would make them "whole" for a larger audience but somehow the developer doesn't see them as important enough or that critical. That can be GUI and workflow things or must-have features that are Yes/No things for too many.
The user on the other hand needs to get the feeling that he is heard and cared for, that he is welcome, that he's on a positive ride towards a better application, even if something is missing ATM. If that can be transported by clear and open communications, it's half of the mission done. The other half of course is to create that better application on several levels, from GUI to workflow to features to docs to overall "feel" of software and company.
Until now, Bitwig had "carte blanche" to do and change things as they wanted (more or less of course). As soon as the application is released, this is over, since from that moment on, you need to keep everything in line and working. Your freedom as a developer is drastically reduced.
So before release, you need to make sure that the basis and groundworks are strong and flexible enough to survive many years of continued development, even if some features may be missing - the foundation is actually much more important for a 1.0, even if the future userbase may heavily disagree...
And still you will always have areas where after a while you realize, you painted yourself into a corner in some regards. That's simply unavoidable.
In addition, some decisions simply create certain dependencies. If clean PDC is one of the goals, certain other things suddenly become very complicated. You can't just send data around tracks as otherwise a modular host could do easily, since you simply wouldn't be able to keep things in time.
Or the decision to create a DAW for live use: You can't trim it as heavily towards low CPU use as a pure studio DAW, since on stage, you need to enable and disable tracks and effects etc. fluidly, so they basically need to run all the time, even if disabled/muted...
Other things are limited by the GUI: If you offer unlimited Sends, how do you deal with them GUI-wise?
I found it rather healthy to be involved in some such projects to realize, how some "very tiny things" can cost hours and day of work. Adding one tiny feature can explode in all directions, from keeping presets and scenes consistent and backwards compatible to showing a new parameter in the GUI in a consistent way to adding it to the docs, not even mentioning the whole enchilada that may arise internally.
So buying into BWS 1.0 isn't about getting the perfect host on day one IMHO.
But if all parties involved do their best, it should become a hell of a ride.