Optimizing Reason 12 for playing live

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
Post Reply
User avatar
syzygianrrf9999
Posts: 36
Joined: 14 Aug 2018
Contact:

15 Oct 2021

As the title says, I'm trying to optimize my laptop (a pre-M1 MBP on Catalina) for performing live with Reason 12. I'm looking for pretty much any trick that anyone can think of that might optimize performance given what I'm working with, mostly out of an abundance of caution rather than any particular problem I've had. Here's some background:

Previously while performing I would simply arrange pre-produced tracks, with about 50% being bounced stems from those tracks and the other 50 being the actual rack instruments and automation from those tracks that I'd manipulate from a controller (or two). I didn't really produce with playing live in mind though. Over the past few years, that's all changed and most of my producing is now improvised, and in general the nature of my song files and Reason configuration has changed quite a bit:
  • Firstly, I use Reason exclusively, nothing else (this has always been the case).
  • I never use the sequencer if I can help it. If it can be done in the rack, it is getting done in the rack.
  • Even when composing at home, if I can help it, I never hit stop on the sequencer (after all, I wouldn't hit stop if I was playing live!)
  • Since the sequencer's use is almost 100% limited to Rex Loops and raw audio files, as well as any ad-hoc automation that can't be CV-automated, like certain mixer channel settings, there's a LOT of step sequencer use in the rack and a LOT of CV routing, gating, merging, and splitting. I've gone so far as to create CV mux devices to automate pattern selection via other patterns or sequences.
  • My typical rack is usually 6-7 columns wide, just to give an idea of the scope. Also, I don't use a lot of synths other than drum synths. Mostly samplers/rex loops, and there'll be on average 2 synths for non-rhythmic elements that I'll simply manipulate through various effects and parameter automation. I'd say no more than 10-15% of the devices in my rack actually make sound.
  • I use combinators for almost everything. Most of them have between 10 and 50 RU worth of devices in them. By FAR the most common devices in my rack (other than Combinators) are CV mergers/splitters, Euclid Rhythm Generators, Select CV Switches, various Chronologists devices (mostly Truth logic gates and Now counting gates), the Quadelectra CV suite devices, and Rex players - all fairly lightweight devices AFAIK.Other than I guess the Dr. Octo Rex none of these are more than 2 RU but there's a LOT of them.
As far as the hardware I have available to me (sadly, the last MBP generation prior to the M1 chips, the ones that get stupid-hot for no reason.) It has a 12 core CPU, 32GB ram, and a 1 TB SSD.

Finally, here's some stuff I'm already doing. Some of it I know for a fact can help, and some of it is out of necessity, but some of it just me guessing and may actually be doing more harm than good:
  • Obviously, I close everything else but Reason (which I usually open my song file in well before playing), even widgets and small stuff like that. If its dark enough wherever I'm playing I turn the brightness way down.
  • As far as power being drawn from the laptop, I have two midi controllers and a 1TB HDD used as a swap/scratch disk.
  • I abuse "save and optimize", remove unused recordings, and usually self-contain all samples immediately before playing.
  • Settings: Mouse knob range and automation cleanup levels are set to their minimum values. Trigger notes while editing and Cable animation are off. Reduce cable clutter is on and set to show cables for selected devices only.
  • Sample rate: I use 88200hz. The reason for this is that I do a lot creative BPM manipulation and I'll jump between 1 and 500 bpm regularly (if Reason would add 256th notes the need for this would be lessened...) once you get up past 200-ish or so 44100hz and 48000hz are insufficient and I start getting artifacts in some cases.
  • Buffer: 2048 - this is to help with audio files which get stretched and un-stretched all over the place while I'm playing.
  • I'll usually set a loop in the sequencer and then never touch it again, just for the sake of resets on pattern devices. This is typically between 64 and 256 bars.
  • I try my best to keep everything in the rack I don't need to see collapsed, especially stuff like oscilloscopes.
  • Everything I've made as far as song files, loops, patches, and audio files, as well as all refills, are all under the same folder.
    Reason itself as well as all VSTs are in different locations (not sure if it would help as far as I/O to keep literally everything in the same spot).
Questions:
  • Is a scratch disk helping in this context?
  • For live performance is it better to self-contain all samples or not?
  • Not counting the Rex/drum machines, I rarely use samplers - how much benefit will I see from loading any audio files I don't need to stretch or cut up into an NNXT or something similar?
  • Can rearranging file locations improve performance?
  • As far as my rack workflow: I'll typically use CV splitters with the maximum number of inputs/outputs (I rarely use the Spiders). I'm under the impression that sequencers/pattern devices hit your CPU harder than simple CV processing devices and therefore I'll limit the number I use and instead use splitters to route them to various combinators stuffed full of CV gates and routers - the thing is, I'm pretty sure after CV data has traversed a certain number of devices that I'm going to run into latency. Is there a good balance to try and strike here?
Sorry for the long post - any input is much appreciated!
industrial/psycore/breakcore/electronic modular metal: https://soundcloud.com/rose-red-flechette

User avatar
plaamook
Posts: 2593
Joined: 22 Jan 2015
Location: Bajo del mar...

15 Oct 2021

My two p.

1) bounce as much to audio as you can. The less running processes the better but be aware there is an intermittent bug that can crash R12 if you move sequencer lanes around, so don’t do that live.

2) consider getting as much on controllers as poss. Sweaty nervous fingers are risky on a track pad in my experience.
What I use is a White korg nanokontrol.
You can use wire wool to get all the manufacturer’s markings off it so it’s blank white. Then you can use a pencil to draw whatever makes and labels you like and they can be erased. It’s very cool.

3) following on from point 2, consider getting a mouse. They’re easier to deal with when you’re nervous than a track pad.
I work only on a track pad for composing, so I’m used to that, but live it can still be more tricky than you think.

4) don’t update ANYTHING. I had a bug in Better touch Tool update that would randomly send the pointer to the start position (Apple logo, top corner) and drag any faders etc you’re tweaking along with it.
Nearly blew the front row to oblivion!

5) I turn off wifi just to be safe.

6) Thrn sleep off and just leave your whole system running after sound checks. Prob safe to sleep it or whatever but as they say, just because you’re paranoid doesn’t mean they’re not out to get you.

I think that’s it.

Good luck
Perpetual Reason 12 Beta Tester :reason:

You can check out my music here.
https://m.soundcloud.com/ericholmofficial
Or here.
https://www.youtube.com/channel/UC73uZZ ... 8jqUubzsQg

User avatar
mcatalao
Competition Winner
Posts: 1824
Joined: 17 Jan 2015

17 Oct 2021

I'm here thinking how 2048 sample buffer can possibly be a good option for live performances. At max, 512... But it depends on what you're doing. When I did this I always played piano and an EWI USB live through reason.

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

17 Oct 2021

None of the questions you ask will affect performance except perhaps the last one. I can’t speak to CV devices performance as I never use them to nearly as large of a capacity as you, but any latency you experience would likely be due to you running a 2048 buffer. The higher the buffer, the higher the audio latency.

Seems like you’re not having any performance issues, but you are pushing your computer very hard with the high sample rate. If your MacBook is running hot, there’s definitely a reason why in this case. However being that your use case is unique, if it ain’t broke, don’t fix it.

Bewlay
Posts: 52
Joined: 28 Aug 2015
Contact:

16 Apr 2022

Can I jump on this old thread since I just have one specific question that was asked above?

- For live performance is it better to self-contain all samples or not?

Does anyone know the answer to this? I use Reason in a live setting with a midi controller and I manipulate delays which is probably hard on the CPU. It all works fine but I've started noticing samplers with more of my samples in them occasionally pop when I'm using delays. Should I self-contain the samples or leave them read from the hard drive?

Thanks.
Reason 10, Mac OS 10.9.5, Digital Performer 7
http://www.grousemusic.com/

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Apr 2022

Bewlay wrote:
16 Apr 2022
Can I jump on this old thread since I just have one specific question that was asked above?

- For live performance is it better to self-contain all samples or not?

Does anyone know the answer to this? I use Reason in a live setting with a midi controller and I manipulate delays which is probably hard on the CPU. It all works fine but I've started noticing samplers with more of my samples in them occasionally pop when I'm using delays. Should I self-contain the samples or leave them read from the hard drive?

Thanks.
Self containing samples doesn’t change performance. Just saves the samples along with the reason file. Reason still loads samples into ram, sounds like you may be exceeding what your ram is capable of.

Bewlay
Posts: 52
Joined: 28 Aug 2015
Contact:

17 Apr 2022

QVprod wrote:
16 Apr 2022

Self containing samples doesn’t change performance. Just saves the samples along with the reason file. Reason still loads samples into ram, sounds like you may be exceeding what your ram is capable of.
Ah right, thanks for the clarification. So if the samples are self-contained or not, in both cases, they are loaded up into RAM for the sake of the project.
So self-containing is simply a convenience for moving projects/ samples. I figured as much, just wasn't 100% sure.
Thanks again.
Reason 10, Mac OS 10.9.5, Digital Performer 7
http://www.grousemusic.com/

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 32 guests