v5.79pre5 - March 30 2018

Stevie · 03-30-2018, 11:41 PM

v5.79pre5 - March 30 2018
+ ReaScript: prevent buffer overflow if very long strings entered in Python path/libname in preferences
# Performance meter: fix potential crash

v5.79pre4 - March 30 2018
+ Glue: round start/end times to project samplerate [t=205043]
+ Multiprocessing: allow autodetection of up to 32 cores/threads
+ Performance meter: optionally show xrun counters
# Notation: allow more columns of nearly-overlapping accidentals
# linux: use clock_gettime(CLOCK_MONOTONIC) for various timings, use prio_inherit for event mutexes
# linux: use smaller file reading buffers by default

Full changelog

Stevie · 03-30-2018, 11:59 PM

i don't know, am i do it right or no but..

Still have massage.
From previous PRE'S, where was:

"+ Free item positioning: order items by timeline position if they were split from the same original recording"

if there are an FX's on a sliced audio from the same original recording, how should it works? becose it's still messy if u have an fx

musicbynumbers · 03-31-2018, 04:27 AM

Devs. Please consider an action for turning on and off the video delay compensation option in preferences.

Even if it's a hidden toggle that is only an action and not a visible option.

More and more speakers are getting phase compensation built in and we will all need a fast way to switch between linear and minimal phase modes.

Or do you know if I could get someone to write a script to change the delay time via a script. Is that value accessible via a script? I'd be happy with that!

Thanks.

Justin · 03-31-2018, 07:32 AM

Quote:

Originally Posted by musicbynumbers

Devs. Please consider an action for turning on and off the video delay compensation option in preferences.

Even if it's a hidden toggle that is only an action and not a visible option.

More and more speakers are getting phase compensation built in and we will all need a fast way to switch between linear and minimal phase modes.

Or do you know if I could get someone to write a script to change the delay time via a script. Is that value accessible via a script? I'd be happy with that!

Thanks.

This is a FR that is not in the right place...

musicbynumbers · 03-31-2018, 07:51 AM

Quote:

Originally Posted by Justin

This is a FR that is not in the right place...

I'll put it in the right place then sorry.

If it's scriptable then be good to know as I'm happy to just go and ask there instead.

Thanks.

Klangfarben · 03-31-2018, 07:58 AM

Quote:

Originally Posted by Stevie

+ Multiprocessing: allow autodetection of up to 32 cores/threads

So this is probably a very silly uninformed question but does this mean that Reaper is currently unable to address more than 32 cores/threads? I currently have a 44-core machine and will probably be bumping up to 64 cores next year so obviously that would change my thinking as Reaper is now my sole DAW.

Also, does that mean that hyperthreading is essentially not effective/not used once the core count is past 16? (assuming a 16-core/32 thread cpu)

Thanks and sorry if these are dumb questions.

Justin · 03-31-2018, 08:15 AM

Quote:

Originally Posted by Klangfarben

So this is probably a very silly uninformed question but does this mean that Reaper is currently unable to address more than 32 cores/threads? I currently have a 44-core machine and will probably be bumping up to 64 cores next year so obviously that would change my thinking as Reaper is now my sole DAW.

Also, does that mean that hyperthreading is essentially not effective/not used once the core count is past 16? (assuming a 16-core/32 thread cpu)

Thanks and sorry if these are dumb questions.

No, you can manually increase it more, it just means that it won't use those cores automatically.

REAPER is ignorant of hyperthreading -- it just looks at the logical core count and uses that.

Klangfarben · 03-31-2018, 08:52 AM

Quote:

Originally Posted by Justin

No, you can manually increase it more, it just means that it won't use those cores automatically.

Thanks, Justin. Again, silly question. If one then has extra cores beyond 32 that aren't being used automatically, how are those cores addressed? Do they have to be manually assigned to plugins, etc.?

Quote:

Originally Posted by Justin

REAPER is ignorant of hyperthreading -- it just looks at the logical core count and uses that.

So in the case of higher core count would it be better to disable hyperthreading?

EvilDragon · 03-31-2018, 09:20 AM

No, you just manually type number of cores in Preferences->Audio->Buffering. Gotta disable auto-detection of course.

Quote:

Originally Posted by Klangfarben

So in the case of higher core count would it be better to disable hyperthreading?

No, why? You get more threads to execute at the same time, which IS going to be great for anticipative processing.

Klangfarben · 03-31-2018, 09:23 AM

Right. Got it. Thanks for the explanation EvilDragon. Much appreciated.

Justin · 03-31-2018, 10:41 AM

The limit I mentioned is one of auto-detection, increasing the thread count manually makes REAPER still automatically distribute the load.

Currently (and for all of v5.x I believe) there are some hard internal limits on thread counts:

64 worker threads for media reading/anticipative FX multiprocessing.
32 worker threads for live FX multiprocessing.

As you increase the thread count and CPU core count, at some point the overhead of synchronizing them all outweighs the additional processing benefit. This is more of an issue for the live FX multiprocessing, and more of an issue at smaller block sizes, but it's something to keep in mind.

ferropop · 03-31-2018, 07:14 PM

Quote:

Originally Posted by Justin

The limit I mentioned is one of auto-detection, increasing the thread count manually makes REAPER still automatically distribute the load.

Currently (and for all of v5.x I believe) there are some hard internal limits on thread counts:

64 worker threads for media reading/anticipative FX multiprocessing.
32 worker threads for live FX multiprocessing.

As you increase the thread count and CPU core count, at some point the overhead of synchronizing them all outweighs the additional processing benefit. This is more of an issue for the live FX multiprocessing, and more of an issue at smaller block sizes, but it's something to keep in mind.

Hey Justin, I've lost track as to whether the tweaks are in the current builds that relate to nested folders and multiprocessing? When organizing projects into large folders with nested subfolders (ie. DRUMS, INSTRUMENTS, FX) when you strap processing on these big folders the RT CPU was crushing hard. I remember a few pres ago there was some beta code introduced relating to this, then removed, etc...just wondering where it's at.

Thanks!

Justin · 04-01-2018, 07:51 AM

Quote:

Originally Posted by ferropop

Hey Justin, I've lost track as to whether the tweaks are in the current builds that relate to nested folders and multiprocessing? When organizing projects into large folders with nested subfolders (ie. DRUMS, INSTRUMENTS, FX) when you strap processing on these big folders the RT CPU was crushing hard. I remember a few pres ago there was some beta code introduced relating to this, then removed, etc...just wondering where it's at.

Thanks!

The 5.79pre series includes the live FX multiprocessing improvements relating to folders and routing.

hopi · 04-02-2018, 07:12 AM

OT how does one get 64 cores on a PC?

Vasily · 04-02-2018, 07:51 AM

Quote:

Originally Posted by hopi

OT how does one get 64 cores on a PC?

you'll need a multi-cpu system, I believe.
with multiple 16-core processors that's possible (both in xeon and opteron ranges)

Jack Winter · 04-02-2018, 08:07 AM

Be careful with NUMA systems though, at least at low latency. AFAIK they never really got the cache coherency to work well enough for low latency audio.

Hopefully someday I can build a nice 64 cpu system to test firsthand for myself

DANIELE · 04-03-2018, 02:45 AM

Quote:

Originally Posted by Vasily

you'll need a multi-cpu system, I believe.
with multiple 16-core processors that's possible (both in xeon and opteron ranges)

And obviously you have to sell your car and your home to buy that system.

sonicowl · 04-03-2018, 03:12 AM

Quote:

Originally Posted by DANIELE

And obviously you have to sell your car and your home to buy that system.

Yea, and then you run 60$ version of Reaper on it... I think basic version of Reaper should only support up to 10 cores or so. Those who want more, should pay for Reaper at least 10% of the price of their computer. Pay-per-core.

EvilDragon · 04-03-2018, 03:51 AM

That's ridiculous.

Meo-Ada Mespotine · 04-03-2018, 04:36 AM

Quote:

Originally Posted by Justin

The limit I mentioned is one of auto-detection, increasing the thread count manually makes REAPER still automatically distribute the load.

Currently (and for all of v5.x I believe) there are some hard internal limits on thread counts:

64 worker threads for media reading/anticipative FX multiprocessing.
32 worker threads for live FX multiprocessing.

As you increase the thread count and CPU core count, at some point the overhead of synchronizing them all outweighs the additional processing benefit. This is more of an issue for the live FX multiprocessing, and more of an issue at smaller block sizes, but it's something to keep in mind.

How about ReaScripts? Are there any thread-limits with them? Or is it managed by, e.g. Lua itself?

Justin · 04-03-2018, 08:02 AM

Quote:

Originally Posted by mespotine

How about ReaScripts? Are there any thread-limits with them? Or is it managed by, e.g. Lua itself?

ReaScripts all run in the main UI thread.

jacques mk2 · 04-03-2018, 09:18 AM

Quote:

Originally Posted by Justin

The limit I

As you increase the thread count and CPU core count, at some point the overhead of synchronizing them all outweighs the additional processing benefit. This is more of an issue for the live FX multiprocessing, and more of an issue at smaller block sizes, but it's something to keep in mind.

So... Practically : how many physical cores would a machine need in order to get optimal results ? (especially when working on huge CPU demanding projects)
Thank you

jacques mk2 · 04-03-2018, 09:21 AM

By the way, are those limitations specifics to Xeon processors due to sync problems ?

Klangfarben · 04-03-2018, 04:20 PM

Quote:

Originally Posted by DANIELE

And obviously you have to sell your car and your home to buy that system.

Until very recently, very true. The previous and current generation Intel 8xxx series processors are just ungodly expensive. However the current AMD EPYC CPUs with 32 cores are pretty competitive in terms of pricing. Their fastest EPYC CPU, the 7601, is a little over 4 grand a pop. If you take a couple of those and combine them with a Supermicro dual cpu motherboard or the like, graphics card, memory, etc. you really aren't looking at much more than a maxed out Mac Pro (which has very old E5-2600 v2 processors) or iMac Pro which uses Intel Skylake Workstation Xeons.

Obviously, you can't really do an apples to apples comparison here but with Moore's law now dead, higher cpu count is going to become a lot more mainstream.