Klockner

I'm trying to automate the multistep process involved in using HISS tools' IR Measurement Device room profiling within a max project, but I'm running into an issue where the parameter I'm using to save my impulse response (message "Save 1", multi-second delay followed by message "Save 0") seems to operate differently than when I manually press the device's "Save" button that needs to get pressed.

I'm noting my issue in the difference of the way that the Convolution Reverb Pro interprets the IR file (whose name stays the same but is re-written upon each save with the IR Measurement Device): The bang-initiated "Save 1"/"Save 0" message saves the IR from the sine sweep and interprets it poorly, as only a .03 sec response, but when I physically click the "Save" button, it interprets accurately, as a .33 sec response. Weirdly, it seems that physically clicking the bang button also finds the device interpreting it accurately -- (would a delay object somehow produce a different type of bang?)

Furthermore, while I'm unable to predict when this happens, sometimes I also receive an error message: iraverage~: not enough room in buffer 001IRA -- which I think I understand as the trim+normalize feature of the IR measurement just being filled larger than is allotted. -- it doesn't appear to 100% correlate with the more obscure issue above.

I should mention that I'm quite a beginner, so my working knowledge of objects/etc may be missing a very basic oversight by trying to crash course my way into something like this project.

amxd~

scope~

comment

message

button

number~

toggle

play~

ezadc~

record~

buffer~

gate~

ezdac~

print

I'm noting my issue in the difference of the way that the Convolution Reverb Pro interprets the IR file (whose name stays the same but is re-written upon each save with the IR Measurement Device): The bang-initiated "Save 1"/"Save 0" message saves the IR from the sine sweep and interprets it poorly, as only a .03 sec response, but when I physically click the "Save" button, it interprets accurately, as a .33 sec response.  Weirdly, it seems that physically clicking the bang button also finds the device interpreting it accurately -- (would a delay object somehow produce a different type of bang?)

I'm trying to automate the multistep process involved in using HISS tools' IR Measurement Device room profiling within a max project, but I'

issue-interfacing-with-max4live-device-parameters-ir-measurement-automation

[deferlow] is better to wait for disk operations to complete. [delay] output is high priority which is not suitable for save/load operations. If you connect a defer / deferlow after the delay the bang will be triggered in the "normal" main thread of Max and not in the timer thread. That also depends on overdrive on/off setting of Max. But there are some explanation about this in the Max docs.

I did not try your patcher but it sounds like it is related to this.

[deferlow] is better to wait for disk operations to complete. [delay] output is high priority which is not suitable for save/load operations. If you connect a defer / deferlow after the delay the bang will be triggered in the "normal" main thread of Max and not in the timer thread. That also depends on overdrive on/off setting of Max. But there are some explanation about this in the Max docs.
I did not try your patcher but it sounds like it is related to this.  

I forgot to thank you for this response! your answer was exactly the solution; I was unfamiliar with those different thread aspects you succinctly described and I spent more time with the documentation there afterwards.

Issue interfacing with Max4Live device parameters (IR Measurement Automation)