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

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

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

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.

Great work guys. Looking forward to reading the paper.

Same here.

"...Max5 and Max6 compatible..." - are these versions compiled 64-bit signal path ready for Max6?

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.

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

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

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.

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.

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...

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

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

Sweet!

Dear all

the paper is now online.

have a good read!

pa

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

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)).

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

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).

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

That sounds good/promising on the representative sound.

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

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

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

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

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

@ 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

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.

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.

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

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!

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

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

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.

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

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

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

fixed.

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

Hello,

I'm trying to correct a first order ambisonic rig using the MIMO option of the irinvert~ object, and it seems I don't manage to understand how it works cause I'm constantly having a "can't allocate matrix storage" error.

I have 8 speakers + 1 sub = 9 speakers and 4 measurement mics. I assume, from what I understand by reading the help patch, that the "sources" are the speakers and the "receivers" are the microphones. But when I send this kind of message to the irinvert~ object ...

mimoto 9 spk1-mic1 spk1-mic2 spk1-mic3 spk1-mic4 spk2-mic1 spk2-mic2 spk2-mic3 spk2-mic4 ... spk9-mic1 spk9-mic2 spk9-mic3 spk9-mic4

... I get a "can't allocate matrix storage" error. (Same with the in-place message) So I am wondering, how does this particular option works?

Hope someone can teach me ^^

sorry Philippe, also jumping on this thread...

multiconvolve~ in Max 7 (either 32 or 64 bit) seems to be broken, bufconvolve~ seems to be working ok. Had to go back to 6.1 to use multiconvolve~. Is there a fix on the horizon?

Philippe - that sounds like you can't allocate enough RAM - try booting Max in 64 bit mode and see if that works for you. Might depend also on how long you IRs are. The message you are sending looks fine. Let me know how you get on. Sorry for the programmer's type error.... maybe I could make that a bit more user friendly.

Jason - you're going to have to help me to help you. I am not aware of any differences of behaviour between max6 and max 7 for multiconvolve~. Can you explain what "seems to be broken" so I can determine what the issue might be?

Alex

Alex,

Sorry, some more info: it's wholly not functioning, I'm getting no output from multiconvolve~ with any of the three analysis settings, fixed IR attribute toggled, or any number of channels/IRs. This is also the case with the example setup in the help file. No errors thrown to the Max window. Everything is working perfectly in 6.1 though.

Jason

My best guess is that your vector size in max 7 is set to 1 or 2. It should say in the help file that this is unsupported, but it doesn't. The same behaviour will happen in Max 6.

It will be supported soon (next few months) along with a release with a few small bug fixes.

Let me know if that is the issue or not.

Alex

Alex, That was the problem – I bumped the signal vector up to 4 and it's working fine now. Thanks for continuing to work on these objects, they're great. Jason

Hi Alex and thank you for your answer,

So you confirm that the issue is linked to the memory usage. I don't think it's the size of the buffers since they were quite small (around 300 ms) as I trimmed them the step before. But I've been trying to use the Multi-In-Multi-out technic for quite a long time now (at least one year) and never managed to get it right. I think I must have tried everything: big buffers, small buffers, in-place, out-of-place etc... and always got this error. It may also come from my Max installation as my RAM is always full , also I'm dealing with a lot of buffers throughout the process (around 100). But Now that I have a lead, I'll investigate on this matter and give a feedback if I find something.

Thank you for your help. I'll keep on investigating...

FWIW - the actual RAM size is not so important. Every app is assigned a virtual address space and some of that may be virtual (on the Hard Disk). In 32 bit the max space is 4 gig of which you can allocate around 3.6G, and the Max app before any patches will take between 2-3 Gig. In 64 bit the limits to the virtual space are basically ignorable.

I am concerned thought that the matrices here should be relatively small (and actually don't depend on the length of the IR).

Can you email me a zip with a patch and some examples IRs off list? I've noticed that the memory handling might not be perfect in this case, and I want to check there is not some other issue (as there is a release due with small fixes).

Alex

Hello Alex, sorry for the delay of my answer.

I didn't indicate it before but my MAX app is already setup in 64bits I've been testing the processed on another MAC and the result is the same. I've noticed though that it works normally with 1 or 2 sources which of course reduces the size of the matrix, then it can't allocate memory anymore.

Don't know if that is important but both computers are under OSX 10.9.5. and I'm using MAX 6.1.9. It also fails to allocate memory with MAX 7.0.4 (trial version).

I will try to send you some irs and a patch to execute the mimo command...