Thanks. I'll play around with CTRL+C and CTRL+R and make it work.Hi SamAnytime,
The existing Compare tool is as far as I am prepared to go with regard to showing 'before and after' results.
Compare Tool:
Displays the current and previous or captured acoustical impedance, acoustical power, acoustical pressure, electrical impedance, diaphragm displacement, phase response, group delay or beam width results on the same chart.
Previous results are used in comparisons by default. Press Ctrl+C to capture the current results or Ctrl+R to release captured results. Results can also be captured or released by right-clicking on any chart.
Press F4 to show or hide the previous or captured results.
Kind regards,
David
Hi Josh,
I will have to think about that one for a while
I can already foresee a few problems, and no doubt other issues will pop up as I look into things further.
You will have to leave it with me for a time, to 'cogitate' over
Kind regards,
David
Thanks for considering it at least.
Technically this can be done with HR currently...
it just requires switching back and forth between the max spl graph and the standard constant voltage graph and keeping a few mental notes.
Hi Josh,
I will have to think about that one for a while
I can already foresee a few problems, and no doubt other issues will pop up as I look into things further.
You will have to leave it with me for a time, to 'cogitate' over
Kind regards,
David
Could this idea be incorporated into something similar to the sample tab?
Hi just a guy,
Thanks for the prompt response. I was hoping that you would post something like the designs you show
Just to confirm that I understand correctly, in effect what you are asking for is the ability to check the particle velocity at the interface points between the segments in a multiple segment horn. In the worst case (a port tube assembly specified using a throat adaptor and four segments) this would be at the following points:
S0 (Throat adaptor entry)
S1
S2
S3
S4
S5 (Port Outlet)
Is this correct?
Kind regards,
David
Yes, that's the worst case example.
But we are already able to check velocity at S1 and at the end of the port (whether that be S2, S3, S4 or S5).
The best case scenario would be that I only need to check velocity at the node before the end of the port (whether that be S2, S3 or S4).
The first example I showed used 3 segments and the port end was S4, so I would need to check velocity at S3. The second example used 2 segments and the port end was S3, so I would need to check velocity at S2.
At the moment I can't think of a reason to need to check velocity at S0. If using a flared port S0 shouldn't be smaller than S1 or it would defeat the purpose of the S1 flare. In some rare cases with a horn design it might be nice to check at S0 but I think I'm ok with not being able to check at S0 if this is not possible or problematic.
In the vast majority of cases I would only need to check velocity at the node right before the port end, which would be S2, S3 or S4 depending on how fancy the port is.
Another way to look at it is that I just need to check velocity at the narrowest point in the port (or line or horn or whatever alignment type I'm working on).
Last edited:
Yes I was looking at the same record. The reason I asked if anyone else had the same problem was because I didn't think you could have missed something so obvious. With confirmation that it worked for others, the question became what is wrong with my system or database.
Trying to debug it, I watched for writes to the hornresp.dat file. This didn't help because you apparently just write the file on exit from hornresp.dat.
I switched from running on my internal SSD to an external hard drive with same behavior.
I have a number of records all port variations on the same horn and chamber so I started going through each of their filters in turn. At first, apparently because I was watching so closely, it seemed that the save feature was working. Given that was the case, I started optimizing filter settings, revising filter settings for each of 6 records in turn before exiting hornresp, re-opening it, and checking to see if my changes survived --- only some of them had!
I chased this for a while and it seemed that one record in particular - the one that I was focused on when I first flagged the problem, but perhaps others that eventually self healed - was problematic. I first verified that it wouldn't save and then gave it an F5. After the F5, it saved just the peq1 setting but not others. I redid the other PERQs, exited to save again, and the second time all the settings survived.
I exported the suspect HR record before and after the F5 but didn't see anything suspicious in it when comparing the two.
Nevertheless, it seems that this is another instance of corrupted database preventing a save - IIRC the reason you coded the F5 when I first reported this type of problem.
Its also very curious that the problematic record was created initially from one of the earlier records in the group I was working on and which apparently either had no problems with F9 save or self healed. If it was derived from a good record, where did the corruption come from? So while I'm happy to have seemingly cured the problem for now, I'm not entirely confident that it will remain cured.
I wonder if there might be some kind of sanity check that you could do when a record is first created or when F9 is pressed; either to give a warning that F5 may be required or to clean up the entry directly.
Thanks and regards,
Jack
Hi Josh,
I had a look last night - I think I can overcome the problems I was concerned about. I will try to include the enhancement in the next release.
The user will able to specify all, or a subset, of the following parameters as inputs:
* Maximum amplifier output power
* Maximum amplifier output voltage
* Maximum amplifier output current
* Maximum driver input power (Pmax)
* Maximum driver diaphragm displacement (Xmax)
Kind regards,
David
Hi Mark,
The Sample tool will be modified as part of the proposed changes.
Kind regards,
David
Hi just a guy,
That is a good way to approach the problem - I will see what can be done once the modifications for Josh are under control
.Kind regards,
David
Hi Piyapong38,
Hornresp can only be used for systems having up to four horn segments. For more than four segments, AkAbak should be used:
Download - Akabak
Kind regards,
David
Hi Jack,
The way that filter settings are saved was changed with the latest update. Hopefully the problems you have been experiencing will become a thing of the past as you progressively "wash through" any remaining suspect records. When you do come across another recalcitrant record, could you please export it and send me a copy, so that I can try to work out what is going on.
Kind regards,
David
Wow. Dave you under sell and then over deliver once again. Many thanks.
How long ago did you first start working on the HR program?
Have you thought about having a donations link on the download page? I'm sure many of us would be inclined to contribute a bit as thanks towards your efforts.
Hi Josh,
I have managed to get around the problems I was worried about. I think you will find the final result to your liking when it is released.
The very first version was written in late 1969 / early 1970 in the Fortran IV language. The attachment shows one of the 80-column Hollerith input punch cards from the original source code listing.
Just knowing that Hornresp serves a useful purpose and is appreciated by users, is enough for me.
Kind regards,
David
Wow. Dave you under sell and then over deliver once again. Many thanks.
I have managed to get around the problems I was worried about. I think you will find the final result to your liking when it is released.
The very first version was written in late 1969 / early 1970 in the Fortran IV language. The attachment shows one of the 80-column Hollerith input punch cards from the original source code listing.
Just knowing that Hornresp serves a useful purpose and is appreciated by users, is enough for me
.Kind regards,
David
Attachments
Last edited:
Well I've seen black earth , yellowish earth, brown earth, and red earth.
Kind of colourful really.
Hi David:
Thanks for offering to trouble shoot. I started looking at a simple sealed sub design today and immediately bumped into the problem again.
I'm now having trouble going back and forth between the two attached records and F5s don't help. I'm trying to compare equalized outputs of the two models. I tune the filters for one, F9 to save, go back to input screen, turn filter on, calculate, view output power. Then go to the other record and do the same. Then go back to first intending to do a compare previous but when I click calculate (filter is now on in input params screen) I see output power corresponding to filter off. I think for the HST18, when I view the filter settings I see its been switched to LeCleach mode. The Equalizer settings are still there but mistuned. For the UM18 record the behavior is similar.
I had been thinking I would need to go to a clean installation and recreate the records of interest from scratch. I think I might just do that tomorrow because if that works it will be a small price to pay for getting past this frustration.
Jack
Hi Jack,
This is very strange indeed.
I worked through your sequence of actions exactly as described above, using your two exported records, and everything worked perfectly for me, with filter settings being saved / retained with no issues. I then spent about an hour trying everything that I could think of in terms of operating, and interacting with, the filters. Still no problems, everything worked exactly as it should. I checked that the filter data values in your two export files were correctly recorded, and that the files were not corrupted in any way.
I am at a loss to explain the problem you are having - it makes no sense that you seem to be the only user affected. I can only imagine how frustrating it must be.
Kind regards,
David