Ableton Forum

CR78 wrote:Thanks flux for your interview:

http://youtu.be/dHC5QDia8js

Thanks for posting!

sandboxing vsts in their own process sounds slooow

ian_halsall wrote:sandboxing vsts in their own process sounds slooow

Ordinarily it would be, but if they're using modern code it will be fine, the fact that they're developing for Linux shows that they're bare metal coders.

yeah - I forgot about that - I suppose if it's unix only then they can use shared memory, pipes, signals, semaphores etc.

but if they do that then it's difficult to stop the processes crashing each other

ian_halsall wrote:sandboxing vsts in their own process sounds slooow

On that note, this exchange is interesting:

ian_halsall wrote:yeah - I forgot about that - I suppose if it's unix only then they can use shared memory, pipes, signals, semaphores etc.

but if they do that then it's difficult to stop the processes crashing each other

Well it's not unix only, I don't think they're taking that approach, they're not going to use OS specific code... I think they're probably just using modern design patterns, they're competing against Ableton for performance so they've got quite a bit of overhead to use. Maybe it won't be as fast as say Cubase or Sonar but it's not hard to be faster than Ableton, Live has an antiquated codebase, it wasn't fast to begin with but now it's very old and you can tell by how hard it was convert to 64 bit... I think Bitwig will perform very well based on what I've read.

generally speaking it involves piping data via a file on disk. getting data across a process boundary is an overhead no matter what design patterns you apply, but compared to all the other processing a vst has to do maybe it's not such a great CPU overhead. I'd be more concerned about how small the buffer could be before disk latency could become an issue - causing drop outs.

crumhorn wrote:generally speaking it involves piping data via a file on disk. getting data across a process boundary is an overhead no matter what design patterns you apply, but compared to all the other processing a vst has to do maybe it's not such a great CPU overhead. I'd be more concerned about how small the buffer could be before disk latency could become an issue - causing drop outs.

sorry this doesn't sound right to me, surely these would be loaded into memory? I don't think you'd be piping via a disk.

Yeah, I wouldn't expect disk latency to be an issue during realtime VST performance, since most of that is calculation/RAM-based (with the exception of some samplers, as I understand it)

But then again, my knowledge of hardware/software interactions is minimal at best

agent314 wrote:Yeah, I wouldn't expect disk latency to be an issue during realtime VST performance, since most of that is calculation/RAM-based (with the exception of some samplers, as I understand it)

But then again, my knowledge of hardware/software interactions is minimal at best

That's what I thought, DFD samplers stream from disk.

sdfak1234 wrote:

ian_halsall wrote:yeah - I forgot about that - I suppose if it's unix only then they can use shared memory, pipes, signals, semaphores etc.

but if they do that then it's difficult to stop the processes crashing each other

Well it's not unix only, I don't think they're taking that approach, they're not going to use OS specific code... I think they're probably just using modern design patterns, they're competing against Ableton for performance so they've got quite a bit of overhead to use. Maybe it won't be as fast as say Cubase or Sonar but it's not hard to be faster than Ableton, Live has an antiquated codebase, it wasn't fast to begin with but now it's very old and you can tell by how hard it was convert to 64 bit... I think Bitwig will perform very well based on what I've read.

I used cubase for years - Live is faster.

pipes can be implemented however you like - on Unix they are not necessarily files although the os may choose to put them to disk

you can open a pipe from c or c++ easily on unix - shared memory is preferred although this is more difficult

ian_halsall wrote:

sdfak1234 wrote:

ian_halsall wrote:yeah - I forgot about that - I suppose if it's unix only then they can use shared memory, pipes, signals, semaphores etc.

but if they do that then it's difficult to stop the processes crashing each other

Well it's not unix only, I don't think they're taking that approach, they're not going to use OS specific code... I think they're probably just using modern design patterns, they're competing against Ableton for performance so they've got quite a bit of overhead to use. Maybe it won't be as fast as say Cubase or Sonar but it's not hard to be faster than Ableton, Live has an antiquated codebase, it wasn't fast to begin with but now it's very old and you can tell by how hard it was convert to 64 bit... I think Bitwig will perform very well based on what I've read.

I used cubase for years - Live is faster.

pipes can be implemented however you like - on Unix they are not necessarily files although the os may choose to put them to disk

you can open a pipe from c or c++ easily on unix - shared memory is preferred although this is more difficult

We are talking about system resources? I'm sorry you are completely wrong, I don't know the last version of Cubase you used but Cubase is A LOT more efficient than Live, it wipes the floor with live.

.. is this turning into a cpu process coding discussion for the lame?

All this aside... and as much as some of the concepts behind BW seem a bit "borrowed"..
there are also many original and forward thinking ideas in that team...
it's looking rather sexy.
I want this kind of competition. still waiting to get my hands on a beta though

is it just me or does the GUI look a bit.. NI reaktor style?

That is expectable phenomenon as FL has been offering that feature for long and explaining that individual process may technically take more CPU than inside host process.

lowshelf wrote:

ian_halsall wrote:sandboxing vsts in their own process sounds slooow

On that note, this exchange is interesting:

the new mapping system is a joy to use. they got rid of the dropdown menus for routing stuff and just went click-drag-happy. so much nicer. it's really coming together quickly now (i know i know, "quickly"...)