Are all the devices in Idle mode if there's no hearable audio involved?

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

My latest track is making my i7 @3,4 Ghz crackling, I needed to increase buffer from 128 to 256.
We know Props are working on a release that are making Reason faster in CPU, but I'm not sure if it has any benefit for us who don't use VSTs. Or in my case I have one ReaXcomp VST in a master-chain but rest of the devices are either REs or Stocks. My question is that are the devices in idle mode, when they don't make sound?

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

And also, would there be some idea if you could pre-render certain tracks into an audio that streams em instead of CPU-calcualting them, but in a fly without bouncing them?

EDIT: I'm thinkering now, that how would be a best way to do that here. As example would there be a need for an metering detecting, that knows when a last audio has ended. Another thing, how much of audio is needed to "In a FLY render" IF, certain tracks repeat the same measure and are identical.

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

Maybe a brickwall-ending automatically to the render-in-fly audio, but when you'd manually stretch a tail of a clip you could do that , when needed. IE, you manually re-render these.

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

The best things should be automated and your micro-editings also easlilie ready to be done, maybe few options/rules you choose to suite your workflow too?

User avatar
Loque
Posts: 4041
Joined: 28 Dec 2015

Post 14 Sep 2018

Sadly, no. A lot of devices consume CPU with LFOs, FX or ADSRelease tails, even if they do not produce any audible sound. PH said nothing of performance improvement of RE or Reason in general. The VST performance boost will probably come at the end of the year.

To save CPU in general, here are a few ruls of thumb
* Less reverbs
* Shorter RELEASE in ADSR envelopes, Also check filter AND amp RELEASE
* Less polyphony
* Maximizers only in finaly mastering stage
* Do i really need this extra fx or oscillator?
* less SERIAL CHAINED routings interventing with other routings, making them chained into the main signal route (typical sharing audio or CV with other channels)
* Lower sampling rate
* Less or no oversampling
* Bounce complex one-shots
* Remove everything that is not used (delete, but keep them saved somewhere)
* Check out what consumes the most CPU and bounce it if possible. Look here:
sllpdc.jpg
You do not have the required permissions to view the files attached to this post.
:reason: 10, Win10 64Bit.

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

VST speed-improvement should be secondary to REs and Core CPU improvements !
Right now we have like Gazillion requests that look like a giant mind-worm-noodle already.
Soonish it explodes and makes the Props rewrite it all from a ground-up LOL.
At least that's how some of us propably feel, heh!

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

Image

Aaaaaaaaahhhhhh...... Splipashhhh!

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

But,,, If a midiclip could be tickable to be part of "into audio in fly" - well, that was one of my first thinkerings about that solution to save cpu. The pre-calculating could be happening in a fly or the calculating would happen when you don't playback the song. Or both, but this is all I have, I'm not a programmer so forgive me that much, cheers!

User avatar
Loque
Posts: 4041
Joined: 28 Dec 2015

Post 14 Sep 2018

deepndark wrote:
14 Sep 2018
But,,, If a midiclip could be tickable to be part of "into audio in fly" - well, that was one of my first thinkerings about that solution to save cpu. The pre-calculating could be happening in a fly or the calculating would happen when you don't playback the song. Or both, but this is all I have, I'm not a programmer so forgive me that much, cheers!
Ppl here always talk about "freeze track". That means, render the audio, play that audio, leave everything in the original untouched and diable everything. Sounds easy, but in Reason it may get very complicated with routings.
:reason: 10, Win10 64Bit.

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

Loque wrote:
14 Sep 2018
deepndark wrote:
14 Sep 2018
But,,, If a midiclip could be tickable to be part of "into audio in fly" - well, that was one of my first thinkerings about that solution to save cpu. The pre-calculating could be happening in a fly or the calculating would happen when you don't playback the song. Or both, but this is all I have, I'm not a programmer so forgive me that much, cheers!
Ppl here always talk about "freeze track". That means, render the audio, play that audio, leave everything in the original untouched and diable everything. Sounds easy, but in Reason it may get very complicated with routings.
But basically the both sides of the racks do the same tasks anyway, maybe now there should be something needed to be rewritten then?

User avatar
Loque
Posts: 4041
Joined: 28 Dec 2015

Post 14 Sep 2018

deepndark wrote:
14 Sep 2018
Loque wrote:
14 Sep 2018


Ppl here always talk about "freeze track". That means, render the audio, play that audio, leave everything in the original untouched and diable everything. Sounds easy, but in Reason it may get very complicated with routings.
But basically the both sides of the racks do the same tasks anyway, maybe now there should be something needed to be rewritten then?
Erm...maybe i missed your point. Sorry.
:reason: 10, Win10 64Bit.

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

Loque wrote:
14 Sep 2018
deepndark wrote:
14 Sep 2018


But basically the both sides of the racks do the same tasks anyway, maybe now there should be something needed to be rewritten then?
Erm...maybe i missed your point. Sorry.
Well, you said the back-side makes it impossible to add features we want, but the backside could as well as being taken into a consideration (tehnically) the same way as the frontside. Or is the TAB pressing having a curse atm. ??

User avatar
Loque
Posts: 4041
Joined: 28 Dec 2015

Post 14 Sep 2018

deepndark wrote:
14 Sep 2018
Loque wrote:
14 Sep 2018


Erm...maybe i missed your point. Sorry.
Well, you said the back-side makes it impossible to add features we want, but the backside could as well as being taken into a consideration (tehnically) the same way as the frontside. Or is the TAB pressing having a curse atm. ??
I did not explicitly said backside, but yea, if you understand this under rooting it is ok.

And i did not said it is impossible. I said it is comlicated. When i just think of my last track, where i had side chained compressors and the CV gain reduction from the controlled EQs. And that was apretty simple setup. There were no fancy CV maths involved that get changed on weird othere dependencies.

Dont get me wrong, i want to have that feature. But i am reastic enough, that there may be problems that can make it incredible complicated. A simple example is, that there is no PDC everywhere evailable - that shows that the routings can be complicated... And yes, i want PDC everywhere too :-P
:reason: 10, Win10 64Bit.

User avatar
antic604
Posts: 1272
Joined: 23 Oct 2017
Location: Warsaw, Poland

Post 14 Sep 2018

Freezing - logically & functionally - isn't very different from bounce-in-place, which would require some additional scripting and few missing functionalities:
- you choose the freezing point: instrument, instrument+FX, instrument+FX+mixer, instrument+FX+mixer+inserts, pre/post-fader, etc.
- Reason bounces the audio signal and copies over the devices & mixer settings beyond the freeze point,
- Reason disables all the devices on the source track: players, sound generators, FX, mixer, inserts, disables all the modulation coming from outside (without disabling the devices generating said modulation, because it might be used elsewhere),
- Reason hides the original track

This way you're left with audio track + all the processing that you've decided to have retained past the freeze point. At any time you can "unfreeze", where Reason would simply delete the audio track, unhide the source and activate all the devices.
Reason 10 // Bitwig 2 // Live 10 @ Surface Pro 4 i7 8/256GB
My music: https://soundcloud.com/antic604

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 14 Sep 2018

So about the PDC, the master section has one as well now in a R10? I've been clicking on that auto PDC and sometimes prefer it without one. But I know the Props are not clowns, they make their software like they would do for themselves as well. Lets wait and see.

S1GNL
Posts: 45
Joined: 31 Jan 2018

Post 16 Sep 2018

What's wrong about mixer channel bouncing? I find it even more comfortable because you can set start/end points without changing the midi clips.

User avatar
antic604
Posts: 1272
Joined: 23 Oct 2017
Location: Warsaw, Poland

Post 17 Sep 2018

S1GNL wrote:
16 Sep 2018
What's wrong about mixer channel bouncing? I find it even more comfortable because you can set start/end points without changing the midi clips.
Nothing, but it's "just" bouncing - you can't completely disable the source track (and hence its DSP load) and if you remove it, you can't edit & re-bounce.
Reason 10 // Bitwig 2 // Live 10 @ Surface Pro 4 i7 8/256GB
My music: https://soundcloud.com/antic604

User avatar
deepndark
Posts: 1268
Joined: 16 Jan 2015
Location: Finland

Post 17 Sep 2018

antic604 wrote:
17 Sep 2018
S1GNL wrote:
16 Sep 2018
What's wrong about mixer channel bouncing? I find it even more comfortable because you can set start/end points without changing the midi clips.
Nothing, but it's "just" bouncing - you can't completely disable the source track (and hence its DSP load) and if you remove it, you can't edit & re-bounce.
Yup, this.

S1GNL
Posts: 45
Joined: 31 Jan 2018

Post 20 Sep 2018

antic604 wrote:
17 Sep 2018
S1GNL wrote:
16 Sep 2018
What's wrong about mixer channel bouncing? I find it even more comfortable because you can set start/end points without changing the midi clips.
Nothing, but it's "just" bouncing - you can't completely disable the source track (and hence its DSP load) and if you remove it, you can't edit & re-bounce.
You don't have to remove it. Just mute the lane.
It will stay on mute no matter what you're muting/unmuting/solo'ing anywhere else.


RE and Props Instruments barley use CPU resources when in idle mode/not playing. VSTs can be disabled completely.

User avatar
EnochLight
Posts: 4815
Joined: 17 Jan 2015

Post 20 Sep 2018

A solution to this would be to enable a new feature on the mixer channels that allow you to freeze the channel into a bounced audio track, which then automatically mutes/disables any and all devices that are sending info to that channel. And if one of the devices in that "chain" are linked to devices in another channel - whether it be by CV or whatever - those mixer channels, sequencer tracks, and devices get muted/disabled as well.

Sounds easy in theory, but I would imagine there would be an immense amount of coding that would need to happen to make this work the right way.
Windows 10 64-bit | Reason 10 |  Studio One 3.5 | Asus Sabertooth Z77 | Intel i7 3770k Quad-Core @ 4.5 Ghz | 16 GB RAM | Mushkin Reactor 1TB SSD | RME babyface Pro| Nektar Panorama P-4 | M-Audio Trigger Finger Pro

User avatar
antic604
Posts: 1272
Joined: 23 Oct 2017
Location: Warsaw, Poland

Post 20 Sep 2018

S1GNL wrote:
20 Sep 2018
RE and Props Instruments barley use CPU resources when in idle mode/not playing. VSTs can be disabled completely.
Well, but that's not true - otherwise my current tune with no VSTs whatsoever wouldn't eat 4 DSP bars without even starting playback :(
Reason 10 // Bitwig 2 // Live 10 @ Surface Pro 4 i7 8/256GB
My music: https://soundcloud.com/antic604

User avatar
antic604
Posts: 1272
Joined: 23 Oct 2017
Location: Warsaw, Poland

Post 20 Sep 2018

EnochLight wrote:
20 Sep 2018
Sounds easy in theory, but I would imagine there would be an immense amount of coding that would need to happen to make this work the right way.
Guess who's paying the coders working in Props HQ? ;)
Reason 10 // Bitwig 2 // Live 10 @ Surface Pro 4 i7 8/256GB
My music: https://soundcloud.com/antic604

User avatar
EnochLight
Posts: 4815
Joined: 17 Jan 2015

Post 20 Sep 2018

antic604 wrote:
20 Sep 2018
EnochLight wrote:
20 Sep 2018
Sounds easy in theory, but I would imagine there would be an immense amount of coding that would need to happen to make this work the right way.
Guess who's paying the coders working in Props HQ? ;)
Like any "for profit" company, probably from their NOI. ;) Be that as it may, no amount of money will change the fact that it's probably a metric shit ton of work. :)
Windows 10 64-bit | Reason 10 |  Studio One 3.5 | Asus Sabertooth Z77 | Intel i7 3770k Quad-Core @ 4.5 Ghz | 16 GB RAM | Mushkin Reactor 1TB SSD | RME babyface Pro| Nektar Panorama P-4 | M-Audio Trigger Finger Pro

S1GNL
Posts: 45
Joined: 31 Jan 2018

Post 22 Sep 2018

antic604 wrote:
20 Sep 2018
S1GNL wrote:
20 Sep 2018
RE and Props Instruments barley use CPU resources when in idle mode/not playing. VSTs can be disabled completely.
Well, but that's not true - otherwise my current tune with no VSTs whatsoever wouldn't eat 4 DSP bars without even starting playback :(
There are other CPU resources consuming factors: busses, automation, effect REs/stock plugins, amount of different audio clips (especially when using stretching and pitch correction). You might look into that and deactivate stretching everywhere you don't need it and bounce pitch corrected clips.

User avatar
EnochLight
Posts: 4815
Joined: 17 Jan 2015

Post 22 Sep 2018

S1GNL wrote:
22 Sep 2018
antic604 wrote:
20 Sep 2018


Well, but that's not true - otherwise my current tune with no VSTs whatsoever wouldn't eat 4 DSP bars without even starting playback :(
There are other CPU resources consuming factors: busses, automation, effect REs/stock plugins, amount of different audio clips (especially when using stretching and pitch correction). You might look into that and deactivate stretching everywhere you don't need it and bounce pitch corrected clips.
Automation data, pitch changing and time stretching uses absolutely zero resources when your project isn’t playing back. And the amount of audio clips should have virtually no effect as well. Not until you hit play, anyway.

antic604‘S performance woes are when his project isn’t even playing, and Props can certainly improve how RE’s handle that, IMHO.
Windows 10 64-bit | Reason 10 |  Studio One 3.5 | Asus Sabertooth Z77 | Intel i7 3770k Quad-Core @ 4.5 Ghz | 16 GB RAM | Mushkin Reactor 1TB SSD | RME babyface Pro| Nektar Panorama P-4 | M-Audio Trigger Finger Pro

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot], mmm and 3 guests