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.
Ableton Live 11
251–260 of 268 posts
Re: Ableton Live 11
#252Earlier 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.
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
#253Be 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…
Re: Ableton Live 11
#254Earlier 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/
Re: Ableton Live 11
#255Be 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…
Re: Ableton Live 11
#256Earlier 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
Re: Ableton Live 11
#257Earlier 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…
Re: Ableton Live 11
#258Earlier 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…
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
#259Earlier 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…
Re: Ableton Live 11
#260Earlier 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.
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.