VituixCAD

..turn off In-Room reflection plots in Power &DI graph?

1st order reflection response set in Room tab was and still is alternative to estimated in-room response /CTA-2034-A. Estimated in-room response is visible when walls, ceiling and floor are unchecked in Room tab.

All three new curves can be switched on/off with context menu in rev 2.0.31.1.

New CTA-2034-A curves are quite blind to some obvious issues so I've not yet found good reason to automatically optimize with any of them.
 
I input 5Hz in the first "Filter gain of driver" input box before clicking Axial response of Driver again to make Optimizer curve reach 5Hz, is this OK to do?

Frequency limits are freely available for both 'Filter gain of driver' and 'Axial response of driver'. Location of text boxes at the same "row" with Filter gain.. radio button is insignificant.

Adjusting of frequency limits is usually best to do the last, just before starting 'Axial response of driver' optimizing to verify that target curve does not reach too far; frequencies which are acoustically impossible for the driver and would lead to worse total result.
 
^^Improved build of 2.0.32.0 is done.

^CLIO 10-12 has been supported in Convert IR to FR tool since rev. 2.0.5.0 (2018-10-02). CLIO mls was the first one with ARTA pir quite naturally because I've had CLIO since version 10 with fw-01.
I wasn't too aware of CLIO Pocket and it's different file formats crp and ffp, but now also crp is supported to offer same possibilities to Pocket users.
 
Auto file naming is date+time in Pocket app, but I've already asked consecutive numbering from R&D.
Individual mic calibration - if not available - could be another imperfection, though calibrated MIC-01...03 or calibration service are available, and VituixCAD Convert IR to FR can calculate compensation to responses.
 
Thanks so much again, your software is the best!
A couple of questions if you don't mind.

1) Are .vxe (Enclosure) files ready for sharing to a friend even if the friend doesn't have the driver I use in his database? Would it work if I were to modify an existing driver from the database, and send a .vxe over to that friend? In other words, do .vxe files contain the driver parameters and do they modify the parameters of the local database at which it is opened?

2) Is there a quick way I can view calculated power compression when choosing an alignment? From the info in the manual I understood that it is possible to quess a number in the [Max comp %] box and see when it stops agreeing with the number (text turns red).
 
^
1) vxe does not include T/S parameters. It just refers to driver database with Manufacturer and Model so you should have the same data in two places in order to copy vxe to a friend.
Request to deliver new driver data to me to get updates to online database and from there to everyone's local is not repeated very often or written to user manual.

2) There's no power compression calculation in the package. Basically everything is assumed to be linear. Simplified estimation of non-linearity due to air compression in sealed enclosure is only exception.
 
Copy-paste as xml text is just one option to transfer data from local to local. It is targeted to single...few records because Paste button in Edit/Add driver window picks just the last one if xml contains several DRIVER elements. xml data travels easily by e-mail.

Xml text is not yet supported in 'Update database' feature. That plays with tab delimited text only at the moment. It's able to add and/or update hundreds...thousands of drivers at once. Header line with column names is needed to map data to correct fields which causes small extra work when e.g. data of 50 drivers is copied from one local to another or someone's local to my online. I probably add xml support in days...weeks.
 
Incredible, but I don't have much to add/update unfortunately. A couple (2) drivers I modify for my own use and a couple vintage ones to add (but due to the age of the drivers, maybe not a good idea to add them to the database yet).
Thanks again, me and my friend will send you a cup of coffee soon.
 
I don't have any official strategy or instructions to collect driver data from users to online. Adding data manually is slow (compared to datasheet reader I have) and users have not offered much help so this has been on my shoulders with few exceptions visible in Updated-field.

Modifying local driver data without offering changes to online is not specially recommended because updating from online overrides local changes. Adding from online does not override existing data, but making own local data perfect and up to data while online become obsolete is generally quite selfish if modified drivers are public retail products. Custom drivers of commercial manufacturers are different cases.
I could easily remove local database if that would increase motivation to provide data for community using freeware :)
 
It's refreshing to see your openness about this. I was used to WinISD and it is new to me to be able to participate, to me it always seemed (with WinISD e.g.) that contributing was unwanted.

(The speakers I want to contribute are SB MW16P-4 and MW19P-8. The manufacturers spec is off by enough (e.g. for MW16: 9l->11l, 78Hz->68Hz) to become unreliable for enclosure design. Before I hand in the parameters though I want to double, triple and quadruple check multiple times to be sure :) )

PS:
I wouldn't mind to be prompted when edit/add a new driver, with a dialogue for "Upload parameters to Developer and contribute to database? Y/N". And even follow-up questions on how accurate the data (measurement?) is rated by the user, how it was conceived etc. When the parameters show up in your inbox they can be autodeleted when gibberish input, if passed: rated for quality. This could be another point where users could contribute their time, to cross-check other user input.

I know there are people out there who are especially into serial numbers, specifications etc. Some of those would jump on the opportunity to contribute.
Some more regular users may have other programs loaded with their own personal database of drivers and specs, and might not even know how easy and helpful it is to import and contribute.

In short, I think users wouldn't mind helping you at all. If you make it easy, I'm sure others will step in. A seperate thread on the forum could excite and hopefully maintain momentum too. :)
 
Last edited:
Rev. 2.0.33.1 (2019-12-02)

Enclosure
* Copy as xml command replaced with Export xml (Ctrl+E). Exports selected rows to xml file.
* Added support for xml text (on clipboard, file or online) to Update database function.

Now it's easier to deliver local driver data to someone else, for example to me for online database. Procedure: Select drivers to be transferred from local database as full rows. Export to xml file and send it by e-mail. Receiver reads the file into local database with Update database function. Local database file is copied to server for online data @kimmosaunisto.net.

I'll try keep online database according the latest revision of manufacturer's datasheet regardless of possible differences compared to some delivered units, with or without burn-in.
If someone has measured drivers to get significantly...radically smaller error in the simulation, those can be stored to personal local database as duplicates with slightly different Model name e.g. own initials in the end to avoid overriding if local is fully updated with online database (not just added new drivers).

Sending driver data is voluntary of course. I don't even ask it because manual adding is slow, and I have pdf reader available (in debug mode) which is able to read couple of hundred drivers in a minute directly from datasheets. It's not public tool because reliability is <<100% with some manufacturers having random properties in datasheet pdfs. Tuning of reader and corrections might be needed.

Part of the work is just spying which datasheets have updated since the last import. I guess no one is interested to do that.