Problem using nonRealTime and sfRecord~. Is it a bug or am I doing something wrong?

Mar 18, 2007 at 3:58am

Problem using nonRealTime and sfRecord~. Is it a bug or am I doing something wrong?

Greetings!

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.

#30891
Mar 18, 2007 at 11:11am

Am 18.03.2007 um 04:58 schrieb Ilias Bergstrom:
> 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…

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.

#99429
Mar 18, 2007 at 11:55am

grg,

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.

#99430
Mar 18, 2007 at 12:57pm

Am 18.03.2007 um 12:55 schrieb Ilias Bergstrom:
>
> 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!

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.

#99431
Mar 18, 2007 at 1:16pm

grg,

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.

#99432
Mar 19, 2007 at 4:52pm

Georg Bosch schrieb:
> Btw questions like this are much clearer if one can see a patch ;)

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

#99433
Mar 19, 2007 at 5:10pm

Georg,

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.

#99434
Mar 19, 2007 at 5:15pm

…sorry Stefan, got your name wrong in my previous post, the “Georg Bosch schrieb:” header confused me :)

#99435

You must be logged in to reply to this topic.