If a flat "cone" could be made as light and rigid as a conical shaped cone (there is a reason they are called cones) that would be nice for your purpose, but they can't, so we deal with the physical realities best as possible.
I have do it in akabak, and as you say close to baffle, I have measured the the cone distance to baffle and get this respons from it, with a basrefex port in it.
do not look bad, it is for a two way so woofer has to reach 1000 hz, but I go try also a little cone wideband in stead of a CD but think it then wil never reach 15 a 20 khz, because of the same problem.
regards
kees
Attachments
Hi Paul,
Are you referring to results produced by the Wavefront Simulator tool?
If so, could you please post a Wavefront Simulator screenprint showing an example of the interference pattern you are seeing. Thanks.
Kind regards,
David
Hornresp Update 3500-140903
Hi Everyone,
CHANGE
Driver parameter values can now be saved to a permanent database. Pmax and Xmax are included as driver parameters.
File > Copy Driver to Database
Copies driver parameter values from the current record to the driver database. Not applicable to the default record. Attachment 1 refers.
File > Paste Driver from Database
Pastes driver parameter values from the driver database to the current record. The File menu command is enabled when the input parameters window is in edit mode. The menu command can also be selected by right-clicking any driver parameter label in edit mode. Attachment 2 refers.
My thanks to 'epa' for prompting me to consider adding the driver database feature.
Kind regards,
David
Hi Everyone,
CHANGE
Driver parameter values can now be saved to a permanent database. Pmax and Xmax are included as driver parameters.
File > Copy Driver to Database
Copies driver parameter values from the current record to the driver database. Not applicable to the default record. Attachment 1 refers.
File > Paste Driver from Database
Pastes driver parameter values from the driver database to the current record. The File menu command is enabled when the input parameters window is in edit mode. The menu command can also be selected by right-clicking any driver parameter label in edit mode. Attachment 2 refers.
My thanks to 'epa' for prompting me to consider adding the driver database feature.
Kind regards,
David
Attachments
Hi Sabbelbacke,
Of necessity the new Hornresp driver database uses a random access file, where the records are all of the same length, and where the file comprises one long data string. It would not be that easy for a user to extract a single record from the file to transfer to somebody else.
Complete database files can of course be transferred if so desired - the data is stored the Hornresp.drv file, which is located in the Hornresp / Data folder.
Parameter values for a single driver can be transferred as part of an exported data record, and parameter values for multiple drivers can be transferred in a *.dat data file created by the user, which can be accessed and edited with the Editor tool.
Kind regards,
David
Would it be possible to have the database store separate files for each driver in a folder? Or go even more crazy and give it the ability to use sql?
Member
Joined 2003
Hi Kees,
No. You divide by two when you build the actual system. As an example, assuming that you are happy with the simulation results for the system shown in the attachment and want to build it, then the following values should be used for each driver in the constructed horn:
Rear chamber volume = Vrc / 2 = 10.50 litres
Rear chamber length = Lrc = 15.20 cm
Throat chamber volume = Vtc / 2 = 224.00 cc
Throat chamber area = Atc / 2 = 278.50 sq cm
Throat chamber port area = Ap1 / 2 = 15.90 sq cm
Throat chamber port tube length = Lpt = 1.80 cm
A Synergy horn can be simulated in Hornresp, but needs to be considered as two separate systems:
System 1 - Loudspeaker with driver at the apex throat of the horn (for the higher frequencies).
System 2 - Loudspeaker with multiple drivers offset from the apex throat of the horn (for the lower frequencies).
Kind regards,
David
No. You divide by two when you build the actual system. As an example, assuming that you are happy with the simulation results for the system shown in the attachment and want to build it, then the following values should be used for each driver in the constructed horn:
Rear chamber volume = Vrc / 2 = 10.50 litres
Rear chamber length = Lrc = 15.20 cm
Throat chamber volume = Vtc / 2 = 224.00 cc
Throat chamber area = Atc / 2 = 278.50 sq cm
Throat chamber port area = Ap1 / 2 = 15.90 sq cm
Throat chamber port tube length = Lpt = 1.80 cm
A Synergy horn can be simulated in Hornresp, but needs to be considered as two separate systems:
System 1 - Loudspeaker with driver at the apex throat of the horn (for the higher frequencies).
System 2 - Loudspeaker with multiple drivers offset from the apex throat of the horn (for the lower frequencies).
Kind regards,
David
Attachments
Last edited:
Hi DrDyna,
As mentioned in my earlier response to Sabbelbacke, you can already do this if you wish by using the File > Export and File > Import menu commands. Personally I prefer the database functionality as currently configured because it enables driver details to be accessed faster - simply by right-clicking on any driver label in edit mode. My main objective was the ease of use in Hornresp, not in providing an external stand-alone database containing individual files.
Nevertheless, I will think about it some more, but I cannot promise that I will make any changes
.Kind regards,
David
Perhaps a driver export/import functionality similar to the record export/import functionality could be implemented easily? And a way to import and merge an entire driver database? Since the individual records are just fixed length text strings, these operations should be fairly simple.
-Bjørn
-Bjørn
[/URL][/IMG]
This is a conical polar map...same thing is seen with OS or high-T expo...anything approaching conical. Also visible as low-level "chatter" in directivity plots.
I suspect diffraction but want to be sure.
Hi Paul,
Thanks for the clarification. The interference pattern you are seeing in the polar map is caused by the directivity pattern itself becoming "jagged" at higher frequencies (see attached example). It is simply an intrinsic result of the calculation process, and is not due to diffraction effects.
Kind regards,
David
Attachments
This was what I had in mind - of course, if there were some central database, it should be maintained somehow. I have gathered quite a lot TSP over the last decades, I could provide many and would supply some resources to maintain the database. Of course there are many ways how to deal with this - one could be that I (with some help if it gets too much data) supply a driver file with drivers in it and david bundles this one in the releases. We open up a thread where people can give suggestions or wishes or an email where TSP can be sent to and I put them in the database...
I guess we then quickly have to think about some sort-feature... or simply a search button in the driver database field should do it as well..
Of course, this puts hornresp in the position of not only being a simulation tool but also a global driver database... I love the old tsp-site with hundreds of records and always thought it could be useful to have something like this again. Maybe if bundeld or as a "side project" to hornresp it is worth giving a second thought (on my side tenth thought
).I also was thinking about a way how people themselfes could put records in the database, just like in a wiki. I am not sure if this would become too confusing. My guess is that soon popular drivers will inserted in the database in duplicates (and many drivers have different TSP over the years, some people are not aware of correct designation)..
Of course these are only thoughts of "nice to have". hornresp already does help us so much...
Hm, in addition... what I originaly had in mind for a few ýears was a complete database of drivers where everything could be stored - all technical data available to a driver (not only tsp and power ratings but voice coil height, material use in VC, recone kits available, etc...). Of course this would be much more data than we need in hornresp... I always didn´t come to realize this project simply because of lack of time... There came the first kid, the second, the company.... My personal dream would be to have a biiig central database with ALL information known to every driver - a good search implementation and then whip up a export function to hornresp (then a simple web-attached search within hornresp could be realised as addition - if connected to the internet .- hornresp would simply need a search field to this database in the web and if the database has a positive result, the result would be sent to hornresp... this way the work of maintainig a database is completely out of davids to-do list - he does a lot of work already..... )
Hi DrDyna,
Nevertheless, I will think about it some more, but I cannot promise that I will make any changes
Kind regards,
David
Awesome, it'd be cool to see something like this in the future, as it might enable people to more easily share driver parameters if one driver = one file, and it might lend itself to being set up to push and pull data from external sources.
I guess my dream is that one day, driver manufacturers and software authors teamed up and created a standard file format for specs, which can be easily created by the driver manufacturer. One of my biggest pet-peeves is that we're now in 2014 and I still have to tab over from design software to a website, so I can hunt and peck through specs one by one..and sometimes manually using something like convert.exe to go standard -> metric...it seems like with the tech we have available, what we do currently is.... a little archaic.
I don't expect Hornresp to solve this, but my thinking is, the more "modular" the driver database is, the easier it becomes to take steps like standardizing the format, I.E how musicbrainz.org handles music tagging, which is then accessible by all media players.
Ahh, early morning ramblings.
Yes, this would be lovely - if all manufactureres would team up... I doubt this will ever happen because the specs are not only technical information but also quality measures (wich makes this case different from the musicbrainz example). Most manufactureres relly on the lack of knowledge among the users to get their material into the market and sell it. Transparency is not always what the seller wants (but the customer is keen on it, of course)...
Of course, if a database like this would be built up, the data format had to be as flexible as possible, XML comes to mind for this purpose. This way tons of front ends, converters etc could be made by anyone who would want to distribute. I still see the need of some "inner team" taking care of the quality of the data, otherwise we´d soon end up with a lot of junk information in a oferflowing database.
Some manufactureres are open to such ideas and have databases like this themselves for their own products. Maybe some would share their information and provide driver specs as soon as new speakers come out. They would benefit from the fact that people get to know the drivers very fast after indroducing them to the market and people would start to play around with the drivers in hornresp - it could help boost sales...
Of course, if a database like this would be built up, the data format had to be as flexible as possible, XML comes to mind for this purpose. This way tons of front ends, converters etc could be made by anyone who would want to distribute. I still see the need of some "inner team" taking care of the quality of the data, otherwise we´d soon end up with a lot of junk information in a oferflowing database.
Some manufactureres are open to such ideas and have databases like this themselves for their own products. Maybe some would share their information and provide driver specs as soon as new speakers come out. They would benefit from the fact that people get to know the drivers very fast after indroducing them to the market and people would start to play around with the drivers in hornresp - it could help boost sales...
Yeah, I'd do it pretty much exactly how musicbrainz does it. They have a team of administrators that handle serious stuff, but anyone can become an editor and submit new data, then new data has a cooling off period before it's committed to the live database, so anyone can contribute data, but a submission or change can be "voted down" in case it's terrible.
Well, that's enough thread derailing for me, if I ever get off my duff and start working on a website, I'll start a thread up and see how much interest there is.
Member
Joined 2003
Hi David,
Sorry, I'm still not clear...
1. Is directivity actually "jagged"?
2. Directivity is actually smooth, but the jaggies are an artifact of the software math?
Either way, I'd like to understand the cause.
Thanks!
Hi Paul,
The jaggies are due to the "sampling rate" used to generate the directivity pattern, rather to the actual mathematics of the directivity model. Hornresp calculates the directivity pattern data points at two degree intervals to reduce overall calculation times, which would become unacceptably large otherwise. As you will have noticed, generating a polar map is already a time-consuming exercise.
Kind regards,
David
The jaggies are due to the "sampling rate" used to generate the directivity pattern, rather to the actual mathematics of the directivity model. Hornresp calculates the directivity pattern data points at two degree intervals to reduce overall calculation times, which would become unacceptably large otherwise. As you will have noticed, generating a polar map is already a time-consuming exercise.
Kind regards,
David