Redundancies & inconsistencies in Bitwig

[antic604]

I'll preface this by saying that I LOVE Bitwig and I think it's a great piece of software, however it's not without its faults. One of them is that - I feel - because of its rapid growth there's a lot of redundancies & inconsistencies in features and the way that some of the devices work.

Some examples:
- LFO modulators - we have 3 of them (Beat LFO, Classic LFO, LFO) - together they have a perfect feature set, but separately each one of them is missing some things that others in isolation have (trigger settings, per-voice, etc.),
- envelope modulators - 4-Stage, ADSR and AHDSR - same thing,
- sidechaining modulators - Audio and Note - one returns the shape of the input waveform, the other an ADSR envelope; great, but what if I wanted a waveform spike to trigger an ADSR-like change to my filter? or if I wanted the modulator to act only on selected notes (or velocities), like I can restrict the Audio Sidechain to selected freq. range?
- why is there an Envelope Follower modulator still, if we have Audio Sidechain that does the same thing with few extra options?
- why separate Dynamics and Compressor, when the former can do all that the latter can and more?
- why in some devices Frequency and Resonance are still referred by their name, while in the others by icons; why in one place you pick a filter type from a drop-down, while elsewhere you've got a row of icons to click?
- why do you get huge meters in MIX view, but can't extend vertically the actual faders (and there's no markings on them of any kind, to tell you where you are)?
- why you can map your keyboard or MIDI to a lot of really, rreally esoteric stuff, yet things like 'toggle automation write', 'toggle automation lines for selected track', 'move playhead forward / back' or 'toggle between remote control pages' are not there?
- etc. etc.

I'm sure a lot of those things are irrelevant for most people, but for me they suggest that Bitwig - in current v2.1 - is in a transitional stage. The devs want to (and do!) add great features, but they're are in this weird zone where they're reluctant to remove already existing features / devices to replace them with something more general and on the other hand can't yet open the full modular backbone.

Personally, I'd rather have a single LFO device that could be triggered by anything (free, transport, note, clip), synced to whatever (Hz, notes), have whatever shape (incl. a hand-drawn one) and be mono- or polyphonic. I'd rather have one "Follower" device - again - triggered by anything, where I would filter out the unwanted data from the source and I could shape the response however I like.

Or maybe even go a step further and split the modulators into more "generalised" devices, like triggers, filters, envelopes, oscillators that we could chain to build our own modulators. Probably (hopefully) this is where its heading, but I simply have a hard time dealing with the present inconsistencies and redundancies as a necessary half-step between past and the future.

Again, sorry for the rant - it's all in good spirit and hopefully constructive

[svervs]

Have to agree here ...

Especially this kind of inconsistencies I find quite irritating.

- why in some devices Frequency and Resonance are still referred by their name, while in the others by icons; why in one place you pick a filter type from a drop-down, while elsewhere you've got a row of icons to click?

I've had various situations where it's impossible to make similar changes across devices because they all have different ranges, e.g LFO rates, Steps, Arps
I've brought this up as well in the Beta forums (screenshots below), but it seems went unnoticed.

[Enrize]

And why there are two styles of the same button?

[antic604]

Hehe, so I'm not crazy after all. Great detective work - the only one I disagree with is filter types in Filter and Polysynth. The latter got one extra ("--") to disable the filter completely, whereas it wouldn't make sense for Filter device (you just don't put it in chain or disable it)

I can see this is a (very) small team, but it does reflect on perception of the software - even their webpage still shows videos and descriptions (e.g. list of devices) for Bitwig v1, only then re-directing you to the sub-site for v2. I can live with that, because I've been following the development and I know what's still there and what isn't but it can be really confusing for new potential users.

It's a shame, because I see incredible modularity and interconnectedness behind the scenes, yet I feel the places and way the devs poked the holes in "traditional DAW" to let us play with it seem random and oftentimes confusing.

Here's hoping that one of the 2.x releases will be a "cleanup" version that'll address those issues - and hopefully this as well

[nsq]

Also note that some input/display boxes are black with sharp corners and orange text while others are white with rounded corners.

[svervs]

- the only one I disagree with is filter types in Filter and Polysynth. The latter got one extra ("--") to disable the filter completely, whereas it wouldn't make sense for Filter device (you just don't put it in chain or disable it)

Yes it's not the most significant example. But even this shows the problem: If you have a e.g. layered chain where those 2 devices appear independent, but you want switch the filter types with a single Macro or Modulator you have to deal with 2 different values ranges, and Off is just not available.

It's a shame, because I see incredible modularity and interconnectedness behind the scenes, yet I feel the places and way the devs poked the holes in "traditional DAW" to let us play with it seem random and oftentimes confusing.

That's especially what sometimes makes me feel sceptical about this whole underlying-device-building system. The whole modularity should be based on standardized modules, so an LFO-shape, Phase, whatever module, would be the same in every device. Whereas currently seems kinda patchworked in some places.
On the other hand, the v2 Modulator implementation is so great, I'm not even sure if I'm still interested in this being opened up if we can other features sooner.

[antic604]

On the other hand, the v2 Modulator implementation is so great, I'm not even sure if I'm still interested in this being opened up if we can other features sooner.

Yeah, I thought about this as well - I'd rather them give us access to limited and well thought through number of fine-grained standardised devices that we could chain to create our own modulators (e.g. trigger detector + input filter + envelope/lfo/steps generator), instead of - ultimately - giving access to all the nitty gritty stuff with patchbays, nodes and cables. While I personally would probably love that, it would consume a lot of time to put something together, which I'd rather spend on writing actual music. It would also scare a lot of potential users. I mean even now I see people complaining about how barebones the Polysynth or Sampler are (which they are right on the latter, to certain extent), because the "Bitwig way" expects you to combine the synth with modulators and nested FX (and likely layer few of them) to achieve the effect you can get from Massive or Serum just by loading a preset. What I mean is that stipping down things to their basic components might be a huge divisive move for the user base: some will love it, others coming from Live or other DAW will find it either overwhelming or - paradoxically - not deep enough, because things that could be achieved with few clicks in Live in Bitwig require an elaborate setup, which they can't be arsed to go through or ...won't understand.

Frankly, I don't envy the Bitwig guys the choices they have in front of them, because it's either making a DAW that is like all the others with small, unique flavour; or it's doing great and ultra-flexible DAW, that will alienate a huge portion of potential user base. Look at Sensomusic's Usine Hollyhock - an awesome idea, well executed and ...tiny user base. Or Renoise.

On your comment regarding modularity - I'd hope it's all there in the back in form of some libraries and standardised functions, but the abstractions (devices) we have available now are made by different people that tried to tailor them to their specific functions, so maybe they thought that limiting or differentiating time divisions or frequency ranges was making sense for typical use cases? I hope that's the case and what we're seeing is just a tip of the iceberg and Bitwig guys (& girls) are smart in how they're gonna let us see more of it in the future

[llze]

What did the support say to these suggestions?

[antic604]

What did the support say to these suggestions?

In general my experience with support is good, i.e. they'd reply after few days acknowledging your request (or complaint), but in this case I'm not sure this warrants issuing a ticket, unless it really is a bug.

I'm fully aware those things will only bother the more analytical or OCD-prone of us, because all the 'artsy' types won't care. It's like a real painter who wouldn't give a damn about his favourite brushes coming slightly longer or shorter from the same provider. But myself, I'd start to wonder if maybe their quality control is failing? or they had to fire some staff to cut costs? or their machines break down and they can't afford to fix them? or they don't care to make them equal length?

Same here - if I see such obvious (to me) inconsistencies then I start to wonder what's behind it. For Live I know certain choices were made or updates suspended because of their priorities to prefer the OSX and Push userbases over "traditional" producers, or because of legacy code they've been dragging along for 15 year. Here, I don't know.

But I'm not gonna file a support ticket asking for that

[llze]

yea do it, the response would be interesting, because apart from the myth talk it might be valid feature requests they didn't think of yet, because there is this other long list of stuff to do or whatever.

So as a quote

Feature wishes

If you have any feature wishes you want to let us know about, also just send them in via
http://www.bitwig.com/en/support/tech-support.html


Cheers,
Dom

I could imagine at least that such cosmetic issues are not currently the highest prio, but follow up when time allows.

[Tearing Riots]

Notes are not midi. Thus it makes sense having a higher resolution vs. the 128 steps.

Some of those are legacy devices.

Others are chosen limitations, preferring useful ranges over tons of options (and consistency).

Now the phase one i wondered myself, maybe they're showing off different ways to build interfaces.

[askewd]

>>have whatever shape (incl. a hand-drawn one)

Yes still hoping to see this soon!! I'm waiting to replace Xfer LFOTool or KickStart etc ie really tight pumping 'sidechain' effect without sidechaining.