The All In One Source Bitwig Information & Speculation Thread

[Cyoon]

agree with Thomas..

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

https://www.kickstarter.com/projects/10 ... vers-music

seems like its worth to consider for future compatibility judged by the amount this project already has risen..

po(r)no music

edit: ah ok, it`s basically just a FLAC player, hm..does Bitwig support FLAC export?

[kurasu]

agree with Thomas..

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).

[Ogopogo]

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 .

[tooneba]

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).

And Ableton.

[Ogopogo]

There is a project on Bitwig Beats to create a script for Push.

http://www.bitwigbeats.com/forums/viewt ... y0dTfB_t8E

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.

[LawrenceF]

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.

[tooneba]

I always felt something odd when I read someone wrote post like we can surely expect this simple feature will be come out in next version blah blah, even though I don't know about programming.

[nechronics]

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.

[Cyoon]

this waiting kills me

[dsan@mail.com]

Only four left Suloo


Now it is as BWS first suggested way back when - Coming SOON!

Still, not soon enough right

Happy Musiking!
dsan

[Ogopogo]

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?

[kurasu]

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.

[dsan@mail.com]

As I understand it, BWS has incorporated a wrapper that will run 32 or 64 bit plug-ins. Like has Sonar X (name your poison).

Most 64 bit DAW's today will only run 64 bit plug-ins (unless you use something like jBridge).

EDIT: Oh, and yes, you have been told correctly. Also, karusu assessment is correct.

HTH Ogopogo!

Happy Musiking!
dsan

[Ogopogo]

Thanks!

[ThomasHelzle]

No, a host doesn't have to be 64 Bit if there is a bitbridge - a bitbridge can go either way if it runs on a 64 Bit system - if not you can only use 32 Bit anyway.

Bitwig consists of several parts and loads what fits the system and the plugins at hand.
In the end it frees you from even thinking about it.
I for instance returned to using mainly 32 Bit plugins, since BWS can run each plugin in it's own process which means that even 32 Bit plugins can each use up to 4 Gig of Memory (on windows x64), which for me is enough even for Kontakt etc..
Since there is no gain in 64 Bit other than memory, this is pretty neat, since it allows me to use all my older plugins too.

In most other hosts all plugins run in the same process as the host, so
a.) if one crashes, it may crash the host too.
b.) they all share the same memory space, so if it's 32 Bit, you are limited to a total of 4 GB (on a 64 Bit system) or much less (on a 32 Bit system).

So:
- On a 32 Bit system, you can only run 32 Bit Plugins. Bitwig takes care of everything else.
- On a 64 Bit system, you can run 32 and/or 64 Bit Plugins. Bitwig takes care of the rest.

You can also either run each Plugin in it's own process (what I do since I have 32 GB Ram anyway) or you can run all 32 Bit Plugins in one process and all 64 Bit Plugins in another. Additionally, you can tell individual plugins (like Kontakt) to run in their own process.

But since the sandbox only works for individual Plugins if they all run in their own processes, I have it set to each running in it's own.

Sounds complicated - is dead easy. No other software did this so well EVER.

Cheers,

Tom

Edit: Ooops - I was too late