Bitwig PDC... exactly same problem as LIVE!!

[kurasu]

We've increased the PDC buffer limit by 4 in the next build.. that SHOULD be enough for any musical use, because the usability of the application breaks down way before that because you can't hear changes you do within a reasonable amount of time.

[virtualmark]

It's not fixed at all, I wish people would learn to test properly. It's not difficult, it took me all of 60 seconds to find out that it's not working!

Virtualmark, you are very agressive and counter productive imo.
My advice to you is to use Ableton Live, Studio One, Logic X, FLStudio or Reaper.
If that choice is not enough, please find a daw yourself, there are many out there, and please do not come messing things up here.

The only person who is messing things up is you! Your post adds unnecessary bloat to the thread, please stick to discussing PDC issues.

[mrmatt]

I really just want to be able to complete a song on it right now these limitations are making it hard. I would rather my memory be my limitation and not the program.

It's obvious from the amount of attention this thread is getting that this is going to be a high priority for the BW team. I'm looking forward to seeing what happens with the next update.

[virtualmark]

We've increased the PDC buffer limit by 4 in the next build.. that SHOULD be enough for any musical use, because the usability of the application breaks down way before that because you can't hear changes you do within a reasonable amount of time.

Cool, thanks. While I agree that it may be ok for most uses, I'd still prefer to have the choice. I'll always be happy to sacrifice a bit of RAM for better DAW performance.

[Costa Rica]

I am pleased with the latest explanation from BW; besides, I always try to limit my use of VSTs at first.

[Lesha]

We've increased the PDC buffer limit by 4 in the next build.. that SHOULD be enough for any musical use, because the usability of the application breaks down way before that because you can't hear changes you do within a reasonable amount of time.

You were talking about a trade-off between max PDC and memory usage, what effect would this 4x increase have on BWS?

[Hez]

It does raise an interesting question of the optimal balance between the two though - at some point you HAVE to concede to plugin delay issues unless you literally want 5 seconds between changes before anything happens, which completely nullifies Bitwig's use as a live jamming program.

What's the longest delay time anybody here has built up in an actual musical project? Obviously anybody can create an artifical 2000ms worth of plugin delay by stacking linear phase EQs but that's not a real world example - I can't really see how one would ever use more than one or two linear phase EQs in a row to be honest. There are multiple ways to do everything - in the hardware world LOADS of stuff is impossible so you have to find ways around it and this often leads to musical creativity. Insisting that the PDC buffer be set infinitely large so that you can shoehorn in 5 linear phase EQs is the wrong approach to using your tools, in my opinion.

Note that this isn't directed at anyone specifically! It's totally valid to test the program with extreme cases. I just never really thought of the point that Kurasu is making, that at some point you have to make a compromise from a conceptual perspective, not just from a 'whether or not the code can handle it' perspective.

EDIT: Would it be possible to configure a different maximum PDC buffer for cases where audio is being bounced? That could maybe work in the long run, though I imagine it might be an absolute monster to code. E.g. there is a 128 buffer limit or whatever for live playback plugin compensation to stop Bitwig getting too unresponsive, but if a user really desperately needed to bounce down a complicated section with very heavy plugins, or if they wanted to draw some final crazy automation in before bouncing their master, Bitwig could handle it during non-realtime playback? No idea about the realities of coding such a thing and I'm sure you guys have discussed it already, but might as well throw it out there!

[bulusglo]

It's not fixed at all, I wish people would learn to test properly. It's not difficult, it took me all of 60 seconds to find out that it's not working!

Virtualmark, you are very agressive and counter productive imo.
My advice to you is to use Ableton Live, Studio One, Logic X, FLStudio or Reaper.
If that choice is not enough, please find a daw yourself, there are many out there, and please do not come messing things up here.

The only person who is messing things up is you! Your post adds unnecessary bloat to the thread, please stick to discussing PDC issues.

That was the point. I see that you understood. Thanks to keep the line now for everybody's further reading.

[malleus maleficarum]

EQs in a row to be honest. There are multiple ways to do everything - in the hardware world LOADS of stuff is impossible so you have to find ways around it and this often leads to musical creativity. Insisting that the PDC buffer be set infinitely large so that you can shoehorn in 5 linear phase EQs is the wrong approach to using your tools, in my opinion.



EDIT: Would it be possible to configure a different maximum PDC buffer for cases where audio is being bounced? That could maybe work in the long run, though I imagine it might be an absolute monster to code. E.g. there is a 128 buffer limit or whatever for live playback plugin compensation to stop Bitwig getting too unresponsive, but if a user really desperately needed to bounce down a complicated section with very heavy plugins, or if they wanted to draw some final crazy automation in before bouncing their master, Bitwig could handle it during non-realtime playback? No idea about the realities of coding such a thing and I'm sure you guys have discussed it already, but might as well throw it out there!

+1

[TeePee]

...
(To return to the noticeable latency thing, I also noticed that you seem to gain or lose 1 or 2 samples when bouncing occasionally, but I haven't investigated that in detail at this point).

Loopback (DA->AD) recording alignment is also 1 sample late.


Plus, with no recording offset in prefs. my DA->AD recordings are another 178 samples late due to my use of ADAT converters hanging off an RME Digiface.

[Orga]

EDIT: Would it be possible to configure a different maximum PDC buffer for cases where audio is being bounced? That could maybe work in the long run, though I imagine it might be an absolute monster to code. E.g. there is a 128 buffer limit or whatever for live playback plugin compensation to stop Bitwig getting too unresponsive, but if a user really desperately needed to bounce down a complicated section with very heavy plugins, or if they wanted to draw some final crazy automation in before bouncing their master, Bitwig could handle it during non-realtime playback? No idea about the realities of coding such a thing and I'm sure you guys have discussed it already, but might as well throw it out there!

I was literally going to suggest that. Seems like the 'ideal' solution.

My question is, with the PDC buffer limit now set at 4, I'm assuming this function only comes into play when one uses plug-ins that are inducing latency - otherwise BW runs as normal right?

Hope that doesn't come across as a stupid question. Just trying to get my head around this whole PDC issue and the trade-offs etc..

[dom@bitwig]

I suggest we lock this one for historical reasons and start a fresh one with new findings... the title and first post are outdated by now.