[announcement] the HISStools Impulse Response Toolbox

Sep 11, 2012 at 7:40pm

[announcement] the HISStools Impulse Response Toolbox

Dear all

For those of you who were not at the ICMC today, or at the Max Expo in NYC earlier this year, here is the hard work of Alex Harker (and a bit of mine ;-)

True stereo reverb is only the beginning… spiking room and gear is the next step… automatic room correction, etc is the fun stuff… Max5 and Max6 compatible, Mac and PC

Soon to come: free 8×8 vst and audiounit (efficient, low-latency) convolver… advance tutorials for the use of all that… loads of IRs from around here…

all on http://thehiss.org/ under software.

comments welcome

pa

#64332
Sep 11, 2012 at 7:46pm

IR’s !!! i must to thank you for the announcement Sir ! really huge work … will use it with care :)

#232029
Sep 11, 2012 at 7:53pm

thanks. We had a lot of good feedback from the beta testers too, so the stuff is road ready! I use it on tour/gigs/tunes for at least 4 months now so give it a good beat!

p

#232030
Sep 11, 2012 at 8:03pm

yes Pierre im really into this kind of fashion. may i ask if there will be some papers for download too ? :)

#232031
Sep 11, 2012 at 8:27pm

yes, papers soon… the ICMC paper first, explaining each object ;) should be on the uni website in the next days, I’ll post the link here.

#232032
Sep 11, 2012 at 10:55pm

Great work guys. Looking forward to reading the paper.

#232033
Sep 12, 2012 at 12:07am

Same here.

#232034
Sep 12, 2012 at 9:18am

“…Max5 and Max6 compatible…”
- are these versions compiled 64-bit signal path ready for Max6?

#232035
Sep 12, 2012 at 9:47am

I think they are (Alex will confirm) but as buffers are still 32 bit float, there is little if no difference most of the time. All the maths inside are 64 bit for both 5 and 6, obviously.

#232036
Sep 12, 2012 at 10:33am

great work! Any newsletter sub possibility to be updated of future versions, papers, etc?

#232037
Sep 12, 2012 at 11:40am

nice idea the newsletter, I’ll put Alex on the case ;-)

#232038
Sep 12, 2012 at 5:41pm

hi, thanks for the info, yes, 32-bit buffers of course. but, from what i have read / been told, using max5 externals not compiled with 64-bit signal path in max6, causes high cpu loads for those processes as max is ‘wrapping’ the 32-bit object. that is why i do not use them, and why i always ask, sorry.

#232039
Sep 13, 2012 at 8:47am

Hi All,

@FineCutBodies – I will look into setting something up and post back here when I’m back in the UK.

@pid – The short answer is you don’t need to worry – we are not using the automatic wrapping in Max6 and any CPU usage you see is from the cost of the objects, not anything else.

The long answer (full disclosure) is:

- Many of the objects in the toolbox do not do realtime audiio processing, so it is not an issue for them.
- All the realtime ones have a 64bit perform routine, and all but one of the objects works at 64bit throughout, even for offline processing.
- The exception is the convolver which is 32bit internally but uses a custom wrapper of insignificant cost not the native wrapper.
- The reasons for not making this 64bit are that personally I think there are very few cases where you will be able to tell the difference in a convolution application, the CPU increase would be significant, and it doubles memory requirements. On balance at this point in time I (and I think others) would prefer speed and lower memory requirements to imperceivable accuracy improvements (remember also that the IRs stored in buffers are at 32bit).
- I may revisit this question in the future when there is good reason to, or the concerns of going 64bit are no longer relevant.

- Finally I would say that the native wrapper is not so inefficient in real terms. The problem arises when it is relatively expensive compared to the object you are using. For one or two instances of an object you will not see the cost. However, if you have many instances of 32bit only objects (say within a poly~) then you can see a noticeable CPU increase, especially when the object is not doing a lot of processing (because the wrapper might actually be more expensive than what you want to do, doubling the CPU usage of the object in quesion or more). For realtime convolution, even if we used the native wrapper you wouldn’t see it because as a percentage of the convolution cost it is likely to be (at a guess) less than few percent of the cost of the convolution and possibly much lower than that.

Hope that helps.

#232040
Sep 13, 2012 at 4:34pm

hi alex. thanks very much for the excellently explained info and so. wouldn’t it be great if such thorough info was in the Max6 native documentation? i really admire all the work you have done on your own library and also the hiss tools. as usual i would love your convolution objects to be part of the main distro.

regardless, if third-party developers do not explicitly state how they have dealt with the issue, i will always have to ask.

of course all this changes when (!) cycling74 release a full 64-bit application version of max. i expect as a developer you are really looking forward to that recompilation marathon…

#232041
Sep 13, 2012 at 5:13pm

Hey Pierre and Alex, thanks again for sharing this.
These are massive tools!

So am I right in understanding that I would be able to do EQ
room correction with these tools? In my mind that means I have some
sine wave sweep that I play inside the performance space. That would
create a frequency profile of the room. I then create an IR that compensates
for any deficiencies in the spectral profile. I then use that IR to convolve
audio output to create the optimal sound for that space.

Is that correct? Is this possible with HISStools?

Anthony

#232042
Sep 13, 2012 at 5:47pm

Hi Anthony,

Maybe it is not obvious from the help files but YES – that is exactly the demo we did here at ICMC on tuesday.

We hope to add documentation/patches for this soon! The paper also covers an outline approach for this.

Alex

#232043
Sep 13, 2012 at 7:17pm

Sweet!

#232044
Sep 13, 2012 at 9:29pm

Dear all

the paper is now online.

http://eprints.hud.ac.uk/14897/

have a good read!

pa

#232045
Sep 13, 2012 at 10:01pm

thank you ! and again this is a huge gift from you guys . gold

#232046
Sep 14, 2012 at 12:35am

Good read!

Is multiconvolve~ more efficient than the timeconvolve/partconvolve abstraction? The footnote says that the use of “SIMD instructions throughout” but it’s unclear if that’s referring to multiconvolve~ or the abstraction it’s based on (or both).

What are the plans for the this toolset and the standard Harker externals (there seems to be some overlap). Will one get folded into the other or will they be maintained as separate entities?

Quite excited about the availability of compensation IRs for common mics (will this trickle down to sm57/58 quality?). In terms of correcting close acoustic capture, will the techniques described work with more unusual sources? (ie a piezo microphone on a canvas or other relatively quiet source material (ie an electric guitar)).

#232047
Sep 14, 2012 at 7:41am

Rod: Alex will reply for the tech stuff. You might want to read Bassuet (in French in the references of the paper) on the compensation but our early tests with piezo pickup on an acoustic bass (vs a dpa air mic) was quite conclusive, though you still get the different dynamic patern (spectromorphologically speaking)

p

#232048
Sep 14, 2012 at 8:05am

I’ll have a read. My concern (although I have no practical experience with deconvolution) is that an acoustic bass still produces a relatively loud and representative acoustic signal whereas a canvas (or anything else quiet) wouldn’t have that point of reference. (A canvas is actually decently loud in terms of mids/highs but little to no bass is audible in the room).

#232049
Sep 15, 2012 at 2:20pm

As with all recording it is the SNR, not the actual volume that matters. You don’t need loud output across 100% of the frequency range, just something reasonably representative in the relevant range, and then you should be able to get something useable – anyway Rod we can talk in person about this soon.

I have measured SM58s and SM57s yes.

Right now multiconvolve~ is probably comparable to the abstraction – that may alter in the future, but basically the underlying code is more-or-less the same. The HIRT release proper removes any overlap with AHarker Externals. I plan to keep them separate, but AHarker Externals work is now supported by the HISSTools project. Future releases of tools (max or otherwise) will be in relevant groupings under the HISSTools name (so HISSTools is an umbrella project for various more specific projects – such as the HIRT.

HTH

#232050
Sep 15, 2012 at 5:34pm

That sounds good/promising on the representative sound.

Interesting on the hisstools/ahe/hirt. Looking forward to what other stuff comes out of that.

#232051
Sep 17, 2012 at 6:03pm

Hello Alex and Pierre,

First of all let me thank you a lot for this amazing set of tools, I am starting to design a calibration tool for an ambisonics rig and your externals are already of great help….but please expect questions…:)

Regarding your tools, I would have some comments, if I may, and would really appreciate to discuss them with you.
As Alex knows, I have worked on a similar PD patch with Katja Vetter and we have looked into the chirp formulation deeply.

I can see you are using a fade-out window of 10 ms as a template standard for your sweep.
Reading Farina paper “IR measurements” http://pcfarina.eng.unipr.it/Public/Papers/238-NordicSound2007.pdf, in section 5 he mention that a fade-out windows create pre-ringing artifacts to the IR that can be avoided but not using fade-out and by cutting manually the chirp at the latest zero-crossing at nyquist.
This is also something that Katja and myself have discussed in our PD tool and we have decided to use a different formulation of the chirp to eliminate this problem.

Did you find that with your chirp formulation this pre-ringing artifact is negligible when performing all the IR processing for room correction?

in your help file you never use deconvolution attributes, can I assume that you have already implemented the best setting in your experience already in the FFT based convolution engine and that the attributes are there for completeness?

Also would it be possible to have an example of use of the attributes?

I am very excited about this seminal addition to Max objects and I am looking forward to your answer.

Again, thank you very much

Bassik

#232052
Sep 17, 2012 at 10:20pm

OK – so……

As far as I can see the fade-out does not directly create pre-ring, what creates pre-ring is the implicit linear phase deconvolution filter that results from using the inverse sweep formulation. The lower fade also theoretically creates pre-ring (actually equal pre and post ring being linear phase), but perhaps one is more obvious than the other. Anyway, in the HIRT I implicitly move the sweep end point to a zero-crossing, so for the behaviour you describe you just set the fade out to 0. If you wanted to evaluate how the fade affects things in itmeasure~ it would be great to know what you find. One advancement of the HIRT is to allow the filter phase of the deconvolution to be altered to minimum phase (amongst other options), even when using the same bandlimiting effects of the inverse sweep. Thus, you can choose to have the filter post ring only, without any pre-ring (defult behaviour). For sweep measurements using the inverse sweep, the fade in and fade out are essentially methods of controlling the steepness of the bandlimiting filter at low and high frequencies respectively.

how is your chirp formulated?

I’d be happy to explain this more through another medium, but beyond this some extra formulas etc would probably help.

The way we do room correction means that pre-ring (if it happens and I have not seen it in practice) is not an issue.

There are a few uses of the deconvolution attribs (for instance in irtransaural~ / irinvert~), although not all of them. As we look to add tutorials for the HIRT there will be more on these at some point. If I have some time I could post a patch here to demonstrate the effects of some of these.

And at some point in the not too distant future source will be up for all of this……
Alex

#232053
Sep 18, 2012 at 8:29am

Alex forgot an important bit: we are to release the code under 3-clause BSD very soon, so a direct pd port (like the pd people have done of my ipoke~) will be easy! We can even pair up to make versioning consistent if you feel it is relevant.

p

#232054
Sep 18, 2012 at 2:09pm

Hello Alex,

Thank you for your response, it is very explicative.
Please see attached a screenshot of a simple max patch based on your irmeasure~ object where I have derived a self IR through a measurement loop in order to evaluate the results of two different behavior for the chirp:

1) Fade: the chirp has a fade-in of 0.1 ms and fade out of 15 ms
2)nofade: the chirp has fade-in of 0.1 ms and no fade-out
3) ES: this is the self IR derived in our PD software Exochirp.

My point is that it can be easily seen that both nofade and ES shows an almost perfect DIRAC in time domain while fade does not.
this is due to the effect of the fade-out filter as described by Farina in his papers.

Also there is a difference between nofade and ES in frequency domain at very high freq. (close to Nyquist) that is due to the different formulations of the chirps (all info about Expochirp can be found here: http://expochirp.tumblr.com/)

Now the discussion I reckon shall be on the difference this does make in the real world for room correction purposes and if a difference is perceived by the user between the two different IRs.

You says: “The way we do room correction means that pre-ring (if it happens and I have not seen it in practice) is not an issue.”
This is enough for me to answer my previous question but I would really love to discuss the above further and I will try to do more tests in real world cases to understand if with your method for room eq there is real difference between the 3 cases shown above.

I also agree with you that probably C74 forum is not the right place to discuss about math on this topic but I really appreciate the fact that you are willing to discuss more in detail, thank you.

Re deconvolution, I am not an expert in this and I really appreciate your offer to prepare sample patches.

I wish you a very nice day

Bassik

[attachment=204019,4419]

Attachments:
  1. MeasuretestHIRT.png
#232055
Sep 19, 2012 at 1:35am

@ Bassik – Thanks for the tests.

Yes – these look more or less as expected – you’ll see that the ring is all post ring (no pre-ring) due to the filter phase.

I’ll check the expochirp stuff when it is not so late.

I am not sure that the differences will be very significant once you are above 19/20k especially as for real world purposes the energy content is likely to be low in this area, and at 44.1k SR the anti-aliasing filter of the soundcard also comes into play. I am also interested to look at the non-linear measurements.

As you can do *true* deconvolution in the object you can actually retrieve almost an exact dirac delta if you turn off the bandlimiting attribute, and set the deconvfilter attribute to -1000. However, this means you have no bandlimiting filter which whilst useful for linear digital systems creates severe problems for measuring non-inear systems and for out of range freq content in real-world scenarios. I guess I am not convinced that retrieving a dirac delta is a good measure of optimal behaviour.

Anyway – perhaps we should speak outside of the forum sometime soonish? Drop me an email if this sounds good.

Best

Alex

#232056
Sep 19, 2012 at 6:09am

I’ve had a look through the expochirp paper. A couple more things.

1 – irmeasure~ implements Novak’s phase aligned ESS (to allow proper non-linear system identification).

2 – I’ be interested to know what happens to the frequency graphs in the following two scenarios:

a – when you set irmeasure~ to use only a given number of octaves (which I believe would then match the signal from expochirp – correct?)
b – when you use no fade out for the ESS but then fade the resultant IR

I’m wondering if the ripple you see with no fade out is in fact the result of truncating an infinitely long FIR filter, as I suspect the implicit brickwall filter has a very long (or infinite) impulse. If this is the cause, then applying a fade might improve the amplitude response, as in the window method of FIR design.

A.

#232057
Sep 21, 2012 at 1:43pm

Hello Alex,

Thank you for your response and sorry for the late reply but I am currently dealing with a broken leg…:(

I have performed the additional test you describe in your 2nd post bu only 2a.
I have simulated 3 x 12 octave chirps ending at Nyquist (taking the start freq. from the calcs in ExpoChirp).

For 2b it is not clear to me which type of fade I should apply to the resultant IR.
Do you mean fading the resultant IR in time of freq domain?
If in time domain how long would you like the fade to be?
if in freq. domain, which freq. should be faded?

Please have a look at the screenshot attached.
I have sent you an email to your private adress as well.
Speak to you soon

S.

[attachment=204274,4429]

Attachments:
  1. Measuretest12oct.png
#232058
Sep 22, 2012 at 1:51pm

Hello again,
new post topic this time…:)

I am working on the calibration tool for my ambisonics rig and I have managed to create a routine that measures each speaker per position and then creates inverse filters but one question is stuck in my mind.

In your experience, is there a way to understand or calculate the cropping values in the last change of the creation of the inverse filters?

I have considered the approach to room correction shown on your paper and have decided to trim/crop/fade/normalize at the end of the process as last operation.
I have assumed that an inverse IR cropped at 500 ms should be enough to include most cases for live performances and to eliminate the effect of the room’s reverberation (late reverberation I have assumed but including first reflections).

I would really appreciate advise from anyone who has experience in this practise.

Thank you
Bassik

#232059
Feb 26, 2014 at 12:15pm

Hey,

I have a good sized library of IRs that I’ve taken for Altiverb. Does anyone have any experience importing these for use in Max? Any idea how I might go about doing that?

Any help is appreciated.

Thanks!

#282222
Feb 27, 2014 at 9:29am

Yes, I would be very interested in this as well.

#282345
Feb 27, 2014 at 9:36am

Hola!

I was able to email Alex, and get the answer directly. I’m on the move right now, but to try and pay it forward I’ll post a patch/directions later today.

K

#282347
Feb 27, 2014 at 11:44am

Here is a patch I wrote that makes it stupidly easy to convert your prerecorded IR sweeps into Max using the HISS toolkit. As long as you have the dry reference track, and the wet track recorded in the space this should work, albeit kludgy at times. Forgive me if I formatted this wrong. This is my first time posting a patch.

<code>

– Pasted Max Patch, click to expand. –

</code>

OH GOD I’M SORRY. I just saw the replies. Hope this fixes everything.

#282371
Feb 27, 2014 at 3:17pm

Hey, please use copy compressed! The forum text formatting makes completely pasted patches like this unreadable by Max

#282403
Feb 27, 2014 at 5:45pm

Looks like copy paste does not work. Can you please copy compressed?

#282416
Mar 2, 2014 at 11:02am

fixed.

#282609
Mar 3, 2014 at 3:05am

To clarify – mostly the technique used for deconvolving sine sweeps involves convolving against an inverse sweep (generated analytically) rather than deconvolving directly (as here). The nice thing about the inverse sweep method is that the result is correctly band limited (this is the default option available in irmeasure~), as the inverse sweep acts an appropriate deconvolution filter. In order to use the method in this patch you should set a deconvolution filter appropriate to the sweep used, with a lot of regularisation in the areas outside of the sweep range.

In one view the inverse sweep is equivalent to deconvolving exactly and then applying a filter to the result. Whether this filter is optional is a matter for debate, but it saves the hassle of designing a filter by hand to remove components that are not reliable in the deconvolution due to the band limited nature of the sweep.

HTH

Alex

#282653

You must be logged in to reply to this topic.