Forums > MaxMSP

NonRealTime, sfRecord~ and metro

March 16, 2007 | 11:48 am


I’ve bumped into a problem while trying to render the audio output of my Max/MSP/Jitter patch using sfRecord, when in NonRealTime mode.

The problem is the audio files recorded are sped up considerably compared to the real-time output, and what’s even stranger is the amount of speed up is dependent on the "signal vector size" value when in nonrealtime mode. The larger the "Signal vector size", the closer the speed is to that of the real-time output. Unfortunately with the maximum allowed value of 512, the speed is still too high.

The patch:
In short, MIDI (note on, note off, control) messages are sent to the Kontakt 2 sampler VST, that are triggered by events detected in a qucktime movie, the playback of which is driven with a tempo(40) object. The 9 audio output channels from Kontakt are then recorded to disc using an individual sfRecord~ object for each. When doing this in real time, the real time audio output, as well as the recorded files, are fine, both with the same timing. When in nonrealtimemode, the sfRecord output is sped up considerably.

Finally note that the pitch of the audio is correct in the files generated when in nonrealtime mode; it doesn’t sound like when playing a tape too fast for example, when the pitches go up, so it’s not simply a matter of playing back the audio files slower to get the correct speed.

I have looked for information in all documentation and all forum posts I could find, but there seems to be no reference of a similar problem on the web.

Does this sound familiar to you, so that you may have a suggestion on how it may be solved?

Thank you!

Ilias B.

March 16, 2007 | 2:23 pm

I have now also tried the option of using record~ and buffer~, just for debugging.

I still get the same problem, but this time around it is a slowdown, in the case when "Signal Vector Size" is 512. When setting this to 128, the speed seems to be fine, but unfortunately the solution of using the record~ and buffer~ combination does not really suit my purposes, since i would like to record for much longer time than this solution allows; so I will still need to use sfRecord~ in the final version.

Hope this additional information can better help in understanding what may be causing this!

Ilias B

Viewing 2 posts - 1 through 2 (of 2 total)