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.

btw, is anyone of you firm with that pono music format and player thing?

And I noticed this and cheered:

• The digital filter used in the PonoPlayer has minimal phase, and no unnatural (digital sounding) pre-ringing. All sounds made (including music) always have reflections and/or echoes after the initial sound. There is no sound in nature that has any echo or reflection before the sound, which is what conventional linear-phase digital filters do. This is one reason that digital sound has a reputation for sounding "unnatural" and harsh.

Everyone should think about this quote before putting in a feature request for a linear-phase EQ in bitwig (great way to ruin the latency for your whole project), which is probably the second most misguided effort in the daw-dsp world following 64-bit summing (brilliant invention by cakewalks marketing department, but at least that one doesn't hurt latency).

ThomasHelzle wrote: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.

One thing that I have noticed that plays a part in this: You can be considering feature implementation A and B, where let's say A is pretty much superior. If you put out A, lots of people will be happy and no issues. If you put out B and then change it to A when you realize it's better, you will inevitable get a bunch of angry people telling you you've ruined their workflow and omg how do you not care about how people are using your daw and how can you not understand this .

kurasu wrote:which is probably the second most misguided effort in the daw-dsp world following 64-bit summing (brilliant invention by cakewalks marketing department, but at least that one doesn't hurt latency).

Thanks. I'm still concerned that Push support isn't going to be full even if someone makes a script. I dunno if it's just the lighting but in the PXT vids it seems there there isn't feedback from buttons other than the pads: http://www.nativekontrol.com/PXT-General.html

And will it be able to do everything like use the browser and whatnot, that depends on Bitwig.

ThomasHelzle wrote: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.

Wise words. Unless one is omnipotent (good luck with that) I think it is unavoidable, that something will come up later to make you think... "Damn, if only I'd considered that during initial development."

I sat down with a business customer some years ago and coded a medical billing (home health care state contract business) app on demand, contracted from scratch, following the clients directions for feature and layout all along the way because they knew how the business worked, how the forms needed to look, how the financials and reports needed to flow, and I didn't. I did exactly what they asked for. It took about 5+ weeks of that to get something that could roughly be called a usable beta, something that worked and did everything they asked for and was accurate enough to actually use for their employees and clients.

Then ... something - else - occurred to them, something that nobody had considered, and it took another 2-3 weeks to rewrite a large part of the code to manage that bit because the foundation I'd written couldn't handle it without it being a really ugly hack that would also be a debugging nightmare.

I suppose we could probably scale that up by a factor of 2000 for audio workstations.

We as end users tend to say ... "Just do it [the change] it's easy." It's often actually not so easy.

My only concern is the foundation. Get the foundation and the building blocks right. All these missing features which people (myself included) fuss about are small ornaments that will [presumably] get added in over time, but having a rock solid, flexible, modular system trumps everything and is the main reason I hope to make this my home. Knowing your software won't be pigeon holed in the future or potentially held hostage by poor decisions early on in the development is priority #1.

Ok, somebody please help me clear this up. I'm trying to completely understand 32/64 bit plug compatibility with Bitwig. I've been told that a host must be 64 bit to use 64 bit plugs, and that there is one version of Bitwig, and the Bitwg site says it supports 32 and 64 bit windows. So something is not adding up there. If there is one 64 bit version it can't run on 32 bit windows. So how many versions are there, and which plugs is each compatible with, please?

One version, which installs on both 32/64 bit windows, but depending on the bit-ness of your windows you have it swill start either a 32- or 64-bit engine when you launch it. On 32-bit windows only 32-bit plug-ins can be used but on 64-bit windows you can use both 32- and 64-bit plug-ins at the same time.