Hello all, been awhile, sorry :-)

I'm sure i have asked this before but what are the chances of getting 2 things:

1 the CPU load for modeler appears to be capped at 30% not sure why and it doesn't change if i change the priority of the exe but is i possible to lift that cap so that i can increase performance during STIPA calc's

2: by extension of my above point could it be also made into a multi-threaded application

I'm building lots of stadia models at the moment with ArenaMatch / ShowMatch at 80 + speaker enclosures thats a lot of ray tracing knowing that every driver produces rays @ 7(drivers) x 80 cabinets.

would it not be useful to calculate the 7 octave STIPA bands in parallel across my 8 cores of CPU? 

why is it capped?

cheers

Original Post

Hi Toddy,

Good to hear from you, I hope all is well.

 Just a few thoughts, maybe Trevor can chime in about any future plans.

Unfortunately, I cannot say why the processing power is capped. Back then, Modeler was not designed to support multi-threading and as you can imagine, this would require fundamental infrastructure changes. Modeler is also a 32-bit application, that’s why it cannot allocate more than 2GB of memory. And yes, this will result in some speed penalty on very complex models.

Nonetheless, we are regularly designing complex stadia with 20-30 arrays and often, up to ten modules each. If such a design takes an hour to run 2000 to 3000 impulse responses, that’s still state of the art today.

If you need to be even faster, then we’d recommend reducing the number of samples, e.g. by placing – say – 100 listeners at ‘representative’ locations and turning off the mapping for surfaces. That may give you an average STI result which is already representative of the entire system and will give you enough information to further iterate your design, apply EQ or leveling, etc.

What is most costly here is the ray-tracing – just like you said. But the geometry predictions are the same for all frequencies, so distributing frequency bands across cores would not help much. And Modeler’s pipeline already helps a lot in making these predictions most efficient.

Just for completeness, the number of drivers we use in speaker files must not match the number of physical drivers. E.g. for AM, we have two balloons/drivers in the speaker file, not seven. For RM, there are four sources and for SM, this number is three.

Are you really using the STIPA option (and not full STI) ? Any specific reason for that ?

 Hope this helps.

Best rgds,

Thomas

I'd definitely endorse using sample receivers over area-wide calcs.  I think of it as, and area-wide quick calc is like walking in to the venue and walking around t hear how consistent the sound is, and identify typical and untypical coverage areas.  Then point calcs are like choosing where to put your mic for your SMAART/EASERA/Measurement System of Choice, except it is feasible to have a 100 of them without much shoe leather being lost.

It's no surprise that Modeller, as excellent as it is, can't easily be ported to 64-bit and/or multi-thread - it's not exactly a high sales-volume or simple package. 

Cheers guys

Regards full STIPA plots, the clients expect to see it along with distribution data which i understand as is more intuitive to understand compared to a dist graph,

its just a shame i can take full advantage of my pc with 8 cores and gpu cores. 

i cant render photo real images using ray tracing faster than modeler, and apologies i meant STI not STIPA.

Thanks for the feedback, didn't realise Mr Malpas was lurking around the Bose forums, nice to hear from you again buddy.

 

Add Reply

Likes (0)
Post
Having trouble signing in?

We recently updated our sign-in procedure and if you have old sign-in data cached, this can create a problem. Please:

  1. Clear your browser cache and cookies
  2. Then close the browser (not just the window)
  3. Open the browser and try again
Thank you

Please make sure that your profile is up to date
×
×
×
×