Macro programming in LEAP

[Claus]

Hello.

A feature i would like and use alot.
Example X-over shop.

I usually measure raw frequency responses from 0 - 180 or 0 - 360 depending on symmetry. All drivers separately. Then I simulate the x-over networ for all angles (10 deg resolution), copy-paste to guide -> average for power approximation. A lot of work... A macro or similar would do this quite a simple task, yes ?

Example Enc-shop.

Lets say i am going to do a cardioid subwoofer. I a multichamber box with suitable drivers on the front and rear sides. I run simulations from 0 - 180 or so, copy and paste to X-over shop. This for every single driver separately... 19 sims times X drivers with some resolution equals a lot of time... A macro would free the operator to do somerhing else during the time.
Another solution for this example would be a component in the "network" box in Enclosure parameters that could be called "transfer function" (insted of R or L etc.) or something. Maybe a curve entry with magnitude and phase...

Is it possible to add a macro feature in the future ?

TIA,

Claus

[cstrahm]

I'm not sure exactly what you are trying to do, but there are other places already to put in transfer functions. Tons of them in XvrShop, and in EncShop you do it in the Analysis Parameters. It's already setup for that. Is that what you mean?

[Claus]

I'm not sure exactly what you are trying to do, but there are other places already to put in transfer functions. Tons of them in XvrShop, and in EncShop you do it in the Analysis Parameters. It's already setup for that. Is that what you mean?

Not really.

In the multichamber box one can have different drivers in different chambers. Then theres the network for passive components. That way the enc-shop is capable of doing simple xo-sims. This is how its planned, I think.

Now take the cardioid example. The rear driver has inverted polarity, delay and maybe some response shaping. That cannot be done (simply) with passive parts. If I could import a transfer function (with all that, delay, polarity, shape etc.) I could see the polar plot in one single sim. If my transfer function isnt working as it should I would just re-do it in xover-shop. Way less hours that way.
Think of a box 1200 x 600 x 800 mm in size, 6th. order diffraction with maybe 1 kHz resolution and some 6 - 9 sources... that times 19 (x 2, rear and front separately) to get "raw data". With importable transfer function and some experience I think 2 or 3 runs would do it. :)

[cstrahm]

>> The rear driver has inverted polarity, delay and maybe some
>> response shaping. That cannot be done (simply) with passive parts.

You can reverse the polarity with the network, and you can put in passive network eq/xvr. But the only place you can put in a transfer function is in the Analysis Parameters, and that applies to all drivers.

>> If I could import a transfer function (with all that, delay, polarity, shape etc.)

That's what XvrShop does. EncShop different animal.

>> I could see the polar plot in one single sim.

It sounds like you are doing multiple driver sections in EncShop. If you do single driver sections, then add your networks etc in XvrShop, I don't understand why you would then need to be going back and forth. Everything you do then is in XvrShop.

[Claus]

>> The rear driver has inverted polarity, delay and maybe some
>> response shaping. That cannot be done (simply) with passive parts.

You can reverse the polarity with the network, and you can put in passive network eq/xvr. But the only place you can put in a transfer function is in the Analysis Parameters, and that applies to all drivers.

>> If I could import a transfer function (with all that, delay, polarity, shape etc.)

That's what XvrShop does. EncShop different animal.

>> I could see the polar plot in one single sim.

It sounds like you are doing multiple driver sections in EncShop. If you do single driver sections, then add your networks etc in XvrShop, I don't understand why you would then need to be going back and forth. Everything you do then is in XvrShop.

I get the raw data from enc-shop. I build the box like it would be built in real life. Drivers and ports on their actual positions. Then I run sims from 0 -180 deg front and rear separately (I change the 1 u ohm resistor to 1 G ohm in the network for the side I dont want). Now I have 38 curves with correct RELATIVE phase to copy to x-over shop for filter design. With the accuracy I need (180 deg off axis...) I do need quite high a resolution and order, yes. For a big box this might take 38 h. on a normal PC. If I could import a transfer function for the rear driver(s) instead of R, L or C I could get the whole polar plot in just one run, maybe 1 h.

Sorry I cant explain this better.
I am not worried about cardioid subs per se, those are easy to do empirically but theres stuff above 100 Hz too. :)

[cstrahm]

>> If I could import a transfer function for the rear driver

Adding a capability of that kind is mountains of work. You may see it as easy, but the numerical machinery under the surface is huge, and this has to be setup in arrays to handle any driver in any chamber. Many areas of code would be impacted. There is a lot involved. Not going to happen anytime soon.

[Claus]

>> If I could import a transfer function for the rear driver

Adding a capability of that kind is mountains of work. You may see it as easy, but the numerical machinery under the surface is huge, and this has to be setup in arrays to handle any driver in any chamber. Many areas of code would be impacted. There is a lot involved. Not going to happen anytime soon.

Ok, cool. You are right, I have absolutely no idea of what is involved.

But, with a macro script like in LMS I could tell LEAP to do those simulations (both E and X, original post) without me. From the example, I would write a script that runs those 38 sims with correct angels etc. and copies results to the guide library. Or ?

[cstrahm]

Gee, you can really think up the ideas. First, a macro script system requires an interpreter to be constructed that can process the commands , understand them, and execute them. Second, executing them means calling other routines elsewhere throughout the entire program that know how to do these things with an entirely different interface than the dialog Windows controls.

Again, this is a mountain of work. You are talking about changing and adding program code in a vast number of places, that spans over a million lines of source code.

Yes I created all that for LMS, but EncShop is about 100X times larger. I don't even want to think about this anymore or I will have nightmares tonight.

[Claus]

Gee, you can really think up the ideas. First, a macro script system requires an interpreter to be constructed that can process the commands , understand them, and execute them. Second, executing them means calling other routines elsewhere throughout the entire program that know how to do these things with an entirely different interface than the dialog Windows controls.

Again, this is a mountain of work. You are talking about changing and adding program code in a vast number of places, that spans over a million lines of source code.

Yes I created all that for LMS, but EncShop is about 100X times larger. I don't even want to think about this anymore or I will have nightmares tonight.

Ok. No need to loose sleep over me.