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 audio files recorded are sped up considerably (something like 4x) 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:
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.

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 also tried the option of using record~ and buffer~, just for debugging, resulting in 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 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…

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!

Regards,
Ilias B.

P.S. Note that I have previously posted about this, but since the title may have been misleading, I got no replies and the post had been bumped off the front page of the forum, so I decided to try once more.

Hi Ilias,

search the forum for nonrealtime and sfrecord, similar issues have been
discussed before. As you are non realtime anyway, why not use the
working buffer~solution, stop every once in a while (every x frames),
save the buffers with an indexed name & glue them together afterwards.
Btw questions like this are much clearer if one can see a patch ;)

g, g.

The reason I posted is of course that I did search the forum but didn’t find anything. There are mentions of a slowdown using nonrealtime, but that is of the recording procedure, not the audio as played back from the recorded file!

The patch is very elaborate, and involves an external VST, which is why I didn’t post it. Should try to recreate the problem in a much smaller scale and post it though, in that you’re right.

The buffer solution is not viable because i have close to a hundred channels of audio, and want to record for a long time, that is, a few minutes… I’d have to cut the work up in very small chunks to do this :(

Thanks!

Ilias B.

I just though some of the hints (large disk buffer size for sfrecord,
audio in interupt on etc) might help.

> The buffer solution is not viable because i have close to a hundred
> channels of audio, and want to record for a long time, that is, a few
> minutes… I’d have to cut the work up in very small chunks to do this
> :(

I though you had nine, not hunderts. Anyway, my idea was to automate
the saving & glueing, so it wouldn’t really matter how many chunks you
have. Or just let your patch record one channel after another and let
it run over night?

No idea why the signal vector size changes the pitch in nonrealtime
tough.

Cheers, g.

The automating is actually a good idea for now, if the result is seamless it’s well worth a try!

You were right about my being ambiguous on the channel count; the final product will have many more channels than the 9 I’m currently experimenting with.

Thank you for the tip about automating the buffer-writing, given that you mention it I assume the output is seamless, which then serves my purpose fine till I figure out why sfRecord is acting up!

Regards,
Ilias B.

In this case no patch required, if you have scheduler events controling
your timing (like metro, delay…) you HAVE TO switch on scheduler in
audiointerupt. Elsewise the scheduler runs in realtime and the audio in
non-realtime…
sfrecord is bad in non realtime, you end up rendering much slower than
realtime. Your buffer~/record~ solution is better to speed things up…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

Thank you for your reply!

Setting it so that the scheduler is in Audio interrupt (and with Max scheduling in Overdrive of course) makes no difference.

Also, I have just posted a very simplified example to illustrate this, as a new thread, named: “Possible bug example patch, using nonRealTime and sfRecord~”

I will try to see if i can make a solution that is satisfactory using the buffer technique next up. The problem is, given I will have so many channels, for any longer recording time I will have to do a lot of gluing of wav files together, if i find no way of automating this as well. I am also uncertain whether this option will really result in completely seamless audio in the recording; remains to be seen in practice :)

Also note that I get the same behaviour when using this buffer technique, but this time only for signal vector sizes smaller than i think 256 or 512, i don’t remember. Using sfRecord would I assume also be fine, if nonRealTime allowed buffers of more than 512, because with 512 the speedup seems to be 2x, so with 1024 there might be none :) …unfortunately though the maximum that the window allows is 512, so i will never find out…

…Under this light the ideal solution would still be to find what it is that causes this behavior, rather than trying to circumvent it…

Thank you for your help!
Ilias B.