onar3d

Note that I've also posted this in the Max/MSP forum. I wasn't sure which would be most relevant, so I chose to bost in both.

Hopefully now someone will recognize this, so that I may be able to get around this problem and continue work on my project...

I had previously posted about a problem I've found, that may be a bug. I have now managed to recreate it in as simple a patch as possible, and so I paste it below. Attached to this post you will also find two zipped wav's to illustrate the phenomenon.

What I noticed was that, when trying to record the audio output of attached patch using the nonRealTime audio driver and sfRecord~, the audio output was considerably faster than when compared to that of using a real-time driver, such as mme. Even stranger, the speed-up is inversely related to the “Signal Vector Size” parameter of the DSP Status window, when using the nonRealTime driver.

So the smaller the signal vector size, the greater the speed-up. Also note that the speed up is not simply like when playing back an audio file faster, where the pitch also goes up. In this case, pitch stays constant.

When creating the example patch to illustrate this phenomenon, I narrowed it down to identifying the object causing it, as the “jit.3m”. When bypassing it, the audio output in nonrealtime mode is in the correct speed, independently of what value the signal vector size is set to. Unfortunately, in the actual patch that I first observed this issue, I cannot see any way of achieving the same results without using the jit.3m object.

Instructions for recreating phenomenon using example patch:

1. Make sure the “track2.mov” file from the jitter tutorials is in the same folder as the patch, or drop it in the drop region. Then start the metro to get video playback. It will work with any movie, but this is the one I used.

2. After listening to the output using the real-time audio driver, switch to the NonRealTime driver in the DSP Status window, also setting the signal vector size to something small, like 32 or 64, so that the speed up is considerable.

3. Make sure the drop down in the middle is set to its default value, “Directly”.

4. Make sure audio output is enabled, then click on the “open” message connected to the sfRecord~ object, enter a filename, and then click the toggle next to it to start recording; click it again after a minute or two to stop, and listen to the output. You will notice the speed up I mentioned.

5. If you want to verify that this is somehow caused by the jit.3m, select the drop-down option “through counter”. Now the (different) audio output in non real-time mode is in the correct speed compare to when in real time.

Is this a bug, or is there something I’ve done wrong that you know of?

What I noticed was that, when trying to record the audio output of attached patch using the nonRealTime audio driver and sfRecord~, the audio output was considerably faster than when compared to that of using a real-time driver, such as mme. Even stranger, the speed-up is inversely related to the “Signal Vector Size” parameter of the DSP Status window, when using the nonRealTime driver.
So the smaller the signal vector size, the greater the speed-up. Also note that the speed up is not simply like when playing back an audio file faster, where the pitch also goes up. In this case, pitch stays constant.

Example patch:
--------------------------------------

Possible bug example patch, using nonRealTime and sfRecord~ and jit.3m