Live data from Hacker News

Ableton Live 11

ableton.com

251–260 of 268 posts

Re: Ableton Live 11

#251

Earlier quoted context omitted.

You'd end up with GarageBand. It all depends on the target audience. If you have a piece of software meant to be used by experts, it should be powerful enough that it doesn't restrict them. I disagree that software has a tendency to dumb everything down to the lowest common denominator, simplifying and automating things is the purpose of software in the first place, but there's a huge amount of software out there tha…

> everything Adobe makes When Lightroom moved from v6 (iirc) to Creative Cloud a stunning amount of functionality seems to have been lost for the sake of making it idiot friendly.

Lightroom v6 is still available as Lightroom Classic. Lightroom CC was a rewrite, and they are definitely playing catch up.

Re: Ableton Live 11

#252

Earlier quoted context omitted.

The specific example you cite seems to be: [ A, B, C ] --+ | +--> [ G ] | [ D, E, F ] --+ If Live really insists on running [ A, B, C, D, E, F, G ] all in a single thread, then I agree with you, Live is being sub-optimal at best, dumb at worst. Despite their description supporting this notion that their scheduling works this way, I'm skeptical, because they're just not that dumb (I hope! :) However, sandboxing is abs…

Yes this is what's happening in Ableton and by your description I'd love if Ableton did the same thing as Ardour. I understand sandbox is not the simplest, but it is exactly what jBridge does and it gives me better performance in Ableton, so by simplest I meant that Ableton wouldn't have to change how they do processing, as jBridge is just a wrapper - does not modify Ableton in any way.

"Yes this is what's happening in Ableton"

Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no CPU usage change), but I can't test with VSTs right now (none installed). Maybe VST hosting has that problem, but processing of audio summing, Live's own devices and M4L doesn't have any major problem with multi-core.

Re: Ableton Live 11

#253

Be aware, that in reality, for live performance, you have to buy a costly Push device. This is if you want to create live loops of a specified length and have them start playing automatically. They crippled this feature in the DAW so that you have to buy a Push. They could have allowed you to do this without a Push in many different ways. There is a third party tool called BinkLooper which gets you there, sort of, bu…

C'mon, anyone can easily find dozens of videos that prove otherwise. Also, the Push API is open, anyone can program python remote scripts to access it, that's how apps like Touchable work, completely false you have to buy a Push, don't need hardware nor M4L. Even if you don't know Python you can use ClyphX. And I talk about Live 10.

Re: Ableton Live 11

#254
post #192

Earlier quoted context omitted.

Quite off topic, but: where would a person go nowadays to get up to speed about music making? (Learning, news, etc). I used to tinker with beatmaking back when fl studio was still called fruity loops, and this post has made me very nostalgic. I would like to get back as a hobby, but it's been like 15 years and I'm quite lost.

couple of ableton made, but completely browser based tutorials (they might not fit the specific topic you are looking into learning but still I think they are cool to check out) https://learningmusic.ableton.com/ https://learningsynths.ableton.com/

Let me add Ableton's book "Making Music", which is quite well done and relevant to beginners as well as experienced artusts/users: https://makingmusic.ableton.com/

Re: Ableton Live 11

#255

Be aware, that in reality, for live performance, you have to buy a costly Push device. This is if you want to create live loops of a specified length and have them start playing automatically. They crippled this feature in the DAW so that you have to buy a Push. They could have allowed you to do this without a Push in many different ways. There is a third party tool called BinkLooper which gets you there, sort of, bu…

Push is absolutely optional. A great device, but still very much optional.

Re: Ableton Live 11

#256

Earlier quoted context omitted.

I am using i9 9900k @5GHz so I think it is quite fast. The plugins I use are CPU heavy and you can run limited number of them on a single core. I am not interested in low latency - I am running 1024 buffer, however I would like my projects to play smoothly even if there is latency. Ableton unfortunately does not work well with such use case as it won't parallelise where it could and sandboxing does just that and I ca…

For other readers: It is a misconception that sandboxing per-se enables parallelism. On the contrary, it only hurts performance. The speedup observed with jBridge might have other reasons. More here: https://news.ycombinator.com/item?id=25068976

I didn't observe that. I have experienced no difference apart from improved performance.

Re: Ableton Live 11

#257

Earlier quoted context omitted.

Again, sandboxing is not done for performance reasons. On the contrary, it degrades performance because of the context switch and thread synchronization overhead. I am saying this as someone who has developed a VST plugin host with sandboxing options. Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.

To elaborate why sandboxing itself can't help performance, let's assume you have an FX chain A -> B -> C and "B" is sandboxed. After you've computed "A", you take the output and pass it to "B". You then have to wait for "B" to finish before you can go on and compute "C". So while the subprocess for "B" might run in another thread, the main audio thread has to go to sleep. See how there's actually no parallelism at pl…

Your assumptions are wrong, because when you run jBridge A B and C are sandboxed. You are essentially running all plugins in its own processes. As I stated in other comments, the performance is improved even with the losses coming from context switching. The effect is I am able to run much more plugins than without jBridge without Ableton having a breakdown and task manager shows better core saturation. I also stated I don't care about latency - I run my projects at 1024 buffer plus plugins introduce their own delays, so sometimes it takes a couple of seconds to hear something after hitting play. That's fine as long as the playback is uninterrupted. I am running very CPU heavy plugins and that bring Ableton to its knees. Other DAWs handle it miles better - especially Reaper. Unfortunately I cannot get used to the workflow in other DAWs so I have to use workarounds. I am not sure why people keep defending this flawed architecture. It's what makes the Ableton community so toxic, but still better than Bitwigs though - if you dare to comment you dislike something about Bitwig you likely get crucified.

Re: Ableton Live 11

#258

Earlier quoted context omitted.

Sounds like a great feature. Elsewhere in this thread I asked for advice on how could I take two mp3 recordings and synchronize their tempos and beats but couldn't get a very clear answer, except that it is a "very basic task". Reading your comment about this new feature it seems obvious to me now that if the tempos in those mp3 recordings vary independently, like they do in much recorded music, it would be impossibl…

Not quite. I think we're discussing two different things. You're trying to synchronize two pre-recorded songs. That feature has been around since the beginning and is fairly trivial to do once you learn some of Ableton's core concepts. That can be demonstrated in countless Youtube videos. What I'm describing is composing music on the fly that is locked to a master tempo and clock (like most electronic music). Jamming…

Yes much thanks. But so to do the tempo-syncing you say I need to "use warp markers to snap the song to the 80bpm grid ...". I would have hoped that this could be done automatically (with the new feature in the new version perhaps).

If it can synchronize with live musicians, would it not be as easy (or even easier) for it to synchronize with a recording of live-musicians?

Re: Ableton Live 11

#259

Earlier quoted context omitted.

Yes this is what's happening in Ableton and by your description I'd love if Ableton did the same thing as Ardour. I understand sandbox is not the simplest, but it is exactly what jBridge does and it gives me better performance in Ableton, so by simplest I meant that Ableton wouldn't have to change how they do processing, as jBridge is just a wrapper - does not modify Ableton in any way.

"Yes this is what's happening in Ableton" Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no…

Yes I did such tests and then compared the same scenario with jBridge.

Re: Ableton Live 11

#260

Earlier quoted context omitted.

"Yes this is what's happening in Ableton" Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no…

Yes I did such tests and then compared the same scenario with jBridge.

I think you may be misreading that FAQ page, it mentions sidechain as the reason for using one thread for "dependant" tracks.

Sidechain is not mere grouping/routing like the chain PaulDavis described with ASCII art (different from Sends too), with sidechain the plugin needs the audio from the other track for actual DSP processing, that's why sidechained tracks become a single thread "dependant" signal flow.

That page also mentions Live can use one thread per Chain if needed (for non Live-users, Chains are internal routings inside one single track), so it clearly states Live can use more than one core for one single Track.

Also, plugins like u-HE's use multicore just fine for a single instance, if you disable their own multicore handling (which conflicts with Live's multicore handling).

For Live's own devices, I'm pretty sure multicore works just fine, just tested again with Groups and Sends.

Don't know what problem you have, but it is not simply Live's multicore handling, it is some specific scenario you hit upon.

Post reply on HN