[announcement] the HISStools Impulse Response Toolbox
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.
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!
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.
"…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.
@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?
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.
thank you ! and again this is a huge gift from you guys . gold
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)
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.
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
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 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.
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 – 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.
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.
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
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.
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.
Yes, I would be very interested in this as well.
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.
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. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 4782.3oc6cssbiial9Z2OEXU1qR4QCwYxI2r8jd6LckYlLU2cRpJSlxEsDkM GSQphjxt8jJckGjce4xSxhSjhT7Dnknj8lbikAHIH9+vO9w+I.92d0EytN4S AYy.eE3GAWbwe6UWbgpJYEWXJewr09eZQjel51lsHY85f37YWpuVdvmxU0+l O7Cfj3uLY0phKEuccx17nfb0C5XpcURbdV3uDHqChlWT8lzfLQy5mGlDeUZv hbceh3Ql6PvHN4R.2kOmdI.RcDOE.I9K3mJZzzatV8R10d94KtML9lZsEU9f bOm4DhCwC1daUsmn5jl5CWpnyjq+4ufSmUgZh8WqnlYuNMzOpB0GFWP7PYc+ 8W8J4et7.A5uyOKOHE7mRh1JduGSrlSjfAiR6EerBqYXUawcbk+7TgYxI.lW Gjk4eSPCXF1NzB6GZ02Y9iaBz3vrY6H3lnDm3oPIBW9CFoXucq.RUACzHACz S.LxhBWFjVzbkzWI40NVzGQ2AqFAOGRbb3LA+lCujeCo3SDWoJiRSbChbcli 4tLF5RQaUxb03QGlGi4Lq78jJ.UwTqqBh8uNJn5Do5bYEiCQI94BZey17iMy myIf4i4wzLedCy7Q8NALewAOHdWMvBAJu7Z+3aNNPhpk5cNIBJQBtCtjqj0T 5UUrw4LtXvGuMLCH3ZuMYI3gjz6xtDb81bfnx3jbvlfzUBBaN30QAeRVSP1W 8Wi+qwuSbuaiVB7WdeXV.3wjsf7DPTRxc.+bP9sAfkAKRhueUXjboF+77zPQ yF.7ixRtD3GuDr1+t.P11z.Pn50kEjCxR.9YxVx+9jPQqG+HvOMOXk+h7Lvp zj0.wvQlPBCHYk5sj8PPvFPpXHIXdAoEEFKd2aiUzmWahQpcGtGyE.0KZ4Aw JQIbj5GHYrK9QIP0S5w0K9oaNDebRlHtmQ9p2DlsIx+Qv2FDeS9sGSsLXTTo FcXsrGumpRFUZJBgLG6534Bas8r.uojmA38GxEyXNlvM0oAby8dZvc0lpJb2 R6YAbi4m.3VrDsnMZGOQibkC0x8ytrwRHcf6ULbwf6soDbKnbkGrJJ+zTglx FFksWwmWTi.U0wbTi.UevivH.+LOBzkHm+RRx5iojFtPeRghSXwpdLnmCzSf dzmljFWrZoWBhb.VOhYm.ALBshxE8fwYdzf5f5JjzVZdiVKBMTfHsqCJx6nQ QcnEtYtm0pfiGZZrszOUS4ZSjE5l2J8C4m.6SFsnL7nEkcqDuWjDkjpuOm4t bGpq6ks9evNlPzbRIAtaRIE0.IacJXEKrEqvWJDrkmd34hH3wTHXAuYZX1Be yMN26HZ9cbR5Z+HwvH3+Ddb34smcmn7XlKSaAQ6r6X74yb7q2tZUP5mAhK+t 2Osqq2BRo80im.dJLN2k1mw4PGmynODeHMLO3j3JGEH3gUnCVy6zgqb7NEtx oKcNnyGgFGtCowAjRlyo6nakc10Ly1JsMFtYrPBmG7LZ83eVxmA9Z0LSo+WD VSdGXURJ3a8k9u4OlEzp2UPC5cEj0iVXmgFsPn4Hpb9pZEDrVsFdUEZjzyOu MKObU3hFXsUCkC+NrYnD8BQwwNlU3AUffmmZkDJs3u85Q8geHK.N7ogS+XZ0 BjQ0DNycWTub3MVS4v4Ms8MYCPeJbU0F+3fn9g5gjKS0N.E4V9SIUd8M0Tyk nzlUob6d501i75dZda.wxf3lJD2sLPcEL8Y.7gkpr6h2E.BBzQVEhg5BAMfm 5OTgZ9L3vvncuFaPR1jhjcIK3aCyxChAuI8wu7OGbTcZJhpbWDiwqLSEMAxD r7EYyXvoPOWoKpu1Oses9ap5pPy9v37AW3xUmx.dZ2IyfycoddHhE1pZ2CZg u5fS9BXeah+RfO3iAY4fOl5u3tYGeUrnZahvdJMYINSgJV87NrIyN3mQskIG UiP3JQuLztYvOU6PrpkrAb8dYq+piJMuXBMR8L3fk5vZ2CNL.5RNMhATBAxG mPfgW7RKMb5W6xt2iMvM8Ys1rlokUyJtirBsV9FrAJmVMw5xOWeX6hEhK8e. 9l.YBgjIynjTv6d+7SfuuH5vOiYl7+pWmeQomQmegmDmeg0yCOTmeg8N.meQ wmQmrlEjeJXyz4FD1DRRFr2zk6Tjqlm+Ii8lEUDlXdI0i53IgKTiYkciwDsS QZ8grHsoNm929G1lcqJy19N+aBW.diJK5RhtW5b1p5Kc9cCKFhpn+9z3F1dd G1LPx++Etgkn8E83bCKgd.tgkL8tgcGi8T3KVhf+4z3KVB5f8EKg9hvWrDG2 ozWrDH4P7EKYZ0a8A+6CVkjt9ysCgrACLcO+STXl5WaWWrPeMpBi4Lyhj1rt Xkzvn6G2hDipzUg5X4WxyVKj9Kt0ONY0Jo1UckHFzyfawQdiws3Jl4cbzV4Q 7AeC1vOiNKdD+6SxC9JvGuUz+.qBiBx.qEhIAWKTCLF.lKlFHiJ7Z+74xaBr L8QUt7+fL28uUui.hxRT2+RQ6KjtFIexHURfqy6eodIfsa.4gqC9hGj6dfGt MPbK9OJz1bY6YwOcPEbnG+r3GZjHwZFCX61sf5lAsiYnslxFdgy49CQ4mISD R.eve8FISwaCSyxmB+Ni6xkvixyx3Cvwx3y4ll.cTMvGYbkA7fruevVwFPEc FAU3D3s9CDSGpQrARgunMtAoi9Cj6JWdzNaaF9YrHOROQdlemzxIHrxRclcZ 2diwDz3dZFaPR1yZyVJDaQPSgUKVz51.g7IUIuIOBaiZ16vOyv.Fz6jouyDL 60kTaVG5It0VFpUrAGYu.BX1DM0c3F2F.DeVBSVZvlH+EmjDBmoMdoRpFp2D UcEwhyY.KNcvhYyUXOr3d92mE5eenqfbMc60hBdnJtCA5z6Igvovg8VgVKSe 7TiVErVUPKcpT2EXwNef0Fome9xGNVwMMK7lXQmtesGj6JTjYKNo4hnd8AOn wN0CW8sGjZPECrHZkvnf6CRypunvEy72roR0WT4QjX4OqWjx3fXYUgw5pfkU kFbeXwyu6F8SEXPt..1lp64exkMSeQw32qJdzB.xoL+cY5s3DwsBvHWwLJYw c5EpbJpLYSPbX79q2Ud4kAq72FkeU6ii0u9Jo.3td3VQ+KlcSZ3xjXYmn1SJ qt30ICPfVempDi5Nh82zxCmInisYW6mJwTyl.DUbw7jjn5WpbXTLOvONbsed fzwjpmxorQCWuIMLNu1KRuGCuMaQZRTTslRek6a4JKEizKBdHbY9s0zySdEw sGtoXHXVIFsL7lfr750k6eSV8ZpcHrUkEr5D7Z022D88ROB4VjTzWUBuEZWI 92p2WqS86Y5+.q51o..yFZTO0G5zXS60PEMzr85KsyE1PN.qndkrRy7soFVU H6Y.VwBCHndTtCdTXK74M19q+7jvjt25TcGRSZgIFzhMSYeno6SDLQ+q.XZT u1D5yAwR9y.rT0p1AXGFpXN25nE+sKPAA6jtqNDU3RD0JKurvCyTNqADxKV. o9YeQm9mD6MG4wconQ.JryJnnoztQEm9oXOk2EQHkLWKHVdmDKbDD6NURkQi tCMvT8V40aGExR1ltnX30rd.ndGWncXdXboB5+3NZXua71vkKqqPrVGxLoFo Zc+sZHarcY9Kutrjc2p9rTQxWb8Y3ym9Lwx9r6ymtLzxt7yGt4VXR6tKCedz kgifw3XzkA+zqp58jYY92Gr7JwaPrHxUkGQoY663mC0KGC6EkQX5eqchdd4c 8RuIJ4Z+HiqtJe1V7vvq1Ahiz2gKq3nsxtfiyXOJn2+v9p27IX764OKePKBI zyxyAZk+wl93h.cvv4DnKk6sKq848dJBc9BLR1J41P+yGGG7aLPwFO7WyG1X cFDP50G1rwljOnJh1Lcve02K6bkzrZ2zq1ffNdLoKi00L62LSKd73smpDxr6 4H953x9IOajKQVWXQVV1M6G6Ld.nobnh6YJzIF1NTurcmgM43896VFxeadxs AQatZo+hqjv1OB+olbXxC5Xf+1kgI8tonrHyMfRWfBc4iZCf3PY6PUOnNy7M GD9sipmh.1E7KBL6yCApUvyQkXFlTZly0dao7u1y94x65Is3KsPY3giRV3WM xJGN2XsjUoJroXydHL9gkIObk5tFD7tNIcYPZsDTA6gfTtL.c7x+CB4LBud9 pz7H4o1e5GmEqkrCmQUhVRMUYz8tpyPpBwtScniWKTENrXue8YwZDPvuDjlb 5jFVcoBBrxNlGy6Ul3nOSLJ1FLU4CTwnE6gc3npipGyHy+1so4Bc5u58A9KC 65idwPIvVq6SK5bnA2PLyNj.16Qm4HQLm1PLLUnZIRkZWpchCkRwLVKyFdwE wdj9i7.Rm+2LSBowb+2QsOpdepYT6cNdQs2oyn1677Op800gp8cX6VYuC7V8 Ghke3V+xixyA7wdOwxqgBRcKznRRpZRY09hdGs+n2AdWteT3ht8b+QLbD8As e2bvWmrcws9oKuD7g4fe2bv2mjJXbxxz6wMQEudN3CIaiRVlFbI3e9O9edWr TliZW0IFHDvDPv7HVtBrMSVvGHnCAibzWrQNDADZcbivDpUaiWnF+Te7aRCt YajeZ3unlze4+7e7+J2bcuVpBL3+N9Fg1u5V9CIKBCxeD7aEL.xcgm34gHU1 2ImdvpEL2Z5LiOcbFbdEVChdKaQ38jxANOwH6dpXJ9CyA+9vz6Bt9wKA+vbv 62ds+cp+SvI78AQYhALEugn3aEigw9J1h2nYBRVATrOegfA+NvB+3EAQQpQY gMz4puKSfqezvqrxOK278UxL8dbrBNhkOo.nmm2yHNA8WeMhwx.9wOaINU7A uUN5TS36oVdq4CYWSky5JmsOhhaaMfn+aGueRc7dGlF7Mu68e7pZLlW85cX+ wyLAmRyqP5yCc4V9oGyDvi8rH14HiI5i87qTmLzSCjTwxISN1w50uuD3yCHQ ZC4TiHPtUHx4lI4iB6Kt56jNuXSTnPStog6P+YX.h608rHzjaX8QbC0cfrOV dFz4AKk5.0YIHmYN8EZ22D8r6..ecT8STyoYybsb2Y6kJNI61nNCsITltP2U MLnHHp2M70oHBJWW3Zm98VcabDBAsESqnpyZOrNCxYzNnmcexbKnE0D+eaZv xv7r4h90lZe.qlDYMhQ9cNG8+RyhrLP9gcz4D84qsF+.GUwAobRud6i97xAo G74DzS3XBxcTGSPG9oDD945Wf.y9ieJOyas8UXygdq2y5OjCTFY7eHGF0IV0 fuAa.wm1gYf5UTO6Y0X59oSlAYajFYxOGU6RirtxGR4WwqJ2UiDHa15vkaRB iyM8BtCQhBd5OgytDuxR6dS6mtYMXKrlDvVPB6QmCRARKMjGrdPGlNCmzoEw dE8P5ijJC4V6Tn4HRfVPeL33nOnivRSuhTNxD8D4gLArLCallQKWhMiVijXf 5gApQoUXyRLyWkMG8stWQri9HcoFn33MM.fMilii9oTc566ZN0R2U5L0+onC g.je.fmPBfirYDfORIdT0AyBmQqxWsWQJ2bXf4PZqnayYgp5l.LfYiLETsTG 1log3c8bhYGmJSXfZ0METCcBFQqONnO6AaV2YkZfOUpQel8KFuv0qaJnFaVc l0k.enEbZXuBpYu5lBpAdHTiMiMDHrA0np6bQMH2CfZvLVSMKXSjT.GaFani bdCx0atKuddgI+7C3zrHAaF4p36DBdRnUpcpsOVs1o50vbqcBIWsDSmAhHOk BupRSA0wsf5vij5jGD7LhiCmI+3HPqnnAolSsNhjAyVx.YOYvbD8YBFwIx.8 pGTbT1WoJMEjgMqGI+rOLl4UDWk9RliYVpKqrz4hBPiTpccJvUHhtPLwjQFH aGHFCYnmCXLArZoofBfSford5OjlHsuFTyHpUf6VyrP2VMKDSao3oztXpMqd wGocUbCMSzIdtwFEB47QATumHEn+wrBEYZjzQrQWUD9o4IIpdyJQPdZkEpUx bzl61RIlN9+07MgptI..v3IXg2phFMjVcx1ThniPRwhx7ogKEYklS7CfDKj8 rWUSAs3ZqFuOY6dQs3ShohZrwyfiT.nQQUjV0bpNBG0KAc0edjLoYasRlL0m w0NjhMQrj1LqCRO.G7xMFU1ntofZfSfxVt3JVgAUA5z0S60rZkLJ1Wcx2Toc uUzIbjtooFc5n0kY+plBZwFcOF2HVwbFsKcqV5L0+GqOoqS.b8Waf5kLBKLq XoJMADGzlUrbeRQLAoydLp4asR8RZYeEtlehj8AsxTe7ArbrNP2MpZJnEqbb K9PjiS30BuP8hXilh0bD5DoonUzJkd3zpWwWuvpkLesTMR62qDUqTow7b5z3 hJnistNEMZsULQtjgpFGSSoBW2arPcuhkAcgL1ftnSjf81aeRheu8z2d6mul 6kut1Geh2ye+U+ePWMafR -----------end_max5_patcher-----------
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?
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.
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?
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.
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.
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.
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).
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…
Forums > MaxMSP