Forums > MaxMSP

Possible bug example patch, using nonRealTime and sfRecord~

March 19, 2007 | 3:21 pm

Hi again!

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?

Thanks,
Ilias B.

Example patch:
————————————–

max v2;
#N vpatcher 385 40 1190 952;
#P origin 19 -163;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 278 282 18 9109513 16;
#P message 27 366 14 9109513 2;
#P number 27 423 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 27 396 100 9109543 1 64 412 1;
#X add silent;
#X add through counter;
#X add directly;
#P newex 130 464 42 9109513 switch 2;
#P newex 85 118 62 9109513 prepend read;
#P newex 278 441 37 9109513 / 200.;
#P slider 278 303 15 128 0 1;
#P newex 130 489 27 9109513 * 5;
#P window setfont "Proportional Serif" 10.;
#P comment 136 511 55 9175050 Frequency;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 130 553 80 9240586 cycle~ 1000.;
#P flonum 130 525 62 10 0 0 0 141 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont "Sans Serif" 9.;
#P newex 222 431 27 9109513 + 55;
#N counter 0 55 75;
#X flags 0 0;
#P newobj 146 431 73 9109513 counter 0 55 75;
#P newex 190 364 70 9109513 unpack 0 0 0 0;
#P newex 176 340 53 9109513 jit.3m;
#P number 210 394 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 53 590 15 0;
#P message 72 590 28 9109513 open;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 53 658 74 9240586 sfrecord~ 1;
#B color 5;
#P user ezdac~ 138 690 182 723 0;
#P window setfont "Sans Serif" 9.;
#P newex 148 594 38 9109513 *~ 0.05;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 90 150 53 9240586 loadbang;
#P user jit.pwindow 19 249 82 62 0 1 0 0 1 0;
#P window setfont "Sans Serif" 9.;
#P newex 14 49 45 9109513 metro 40;
#P toggle 14 28 15 0;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 20 228 80 9240586 jit.qt.movie;
#P window setfont "Sans Serif" 9.;
#P message 57 197 77 9109513 read track2.mov;
#P user dropfile 85 45 141 105 0;
#P user panel 83 43 61 66;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 83 27 100 9109513 Drop region for files;
#P window linecount 34;
#P comment 318 50 236 9109513 Instructions for recreating phenomenon: 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? Thanks , Ilias B.;
#P connect 6 0 7 0;
#P fasten 7 0 5 0 19 220 25 220;
#P fasten 26 0 5 0 90 141 25 141;
#P fasten 4 0 5 0 62 220 25 220;
#P connect 5 0 8 0;
#P fasten 9 0 30 0 95 193 137 193 137 351 32 351;
#P connect 30 0 28 0;
#P connect 28 0 29 0;
#P fasten 10 0 12 0 153 636 113 636 113 650 58 650;
#P connect 14 0 12 0;
#P connect 13 0 12 0;
#P fasten 9 0 4 0 95 179 62 179;
#P connect 3 0 26 0;
#P fasten 29 0 27 0 32 451 135 451;
#P connect 27 0 23 0;
#P connect 23 0 20 0;
#P connect 20 0 21 0;
#P fasten 10 0 11 0 153 651 143 651;
#P connect 15 0 18 0;
#P connect 18 0 27 1;
#P connect 21 0 10 0;
#P fasten 19 0 27 2 227 457 167 457;
#P fasten 10 0 11 1 153 651 177 651;
#P fasten 8 0 16 0 25 335 181 335;
#P fasten 25 0 10 1 283 582 181 582;
#P connect 16 1 17 0;
#P connect 17 1 15 0;
#P connect 15 0 19 0;
#P fasten 9 0 31 0 95 185 283 185;
#P connect 31 0 24 0;
#P connect 24 0 25 0;
#P pop;

————————————–

Hope you can help!

Thanks,
Ilias B.



grg
March 20, 2007 | 10:20 pm

On 19.03.2007, at 16:21, Ilias Bergstrom wrote:
> Is this a bug, or is there something I’ve done wrong that you
> know of?

Hi Ilias,

its not a bug. What happens is you have 3 timing sources in your patch:
MSP running steady at you sample rate, metro outputting a bang every
time the scheduler thinks 40 ms have passed, and quicktime, playing the
movie all by itself, unaware of you current audio driver. Even if metro
and the audio clock sync with interupt on in nonrealtime (no idea, but
I wouldn’t rely on it), quicktime still plays by itself, the bang only
lets jit.qt.mov output the current frame.
What you want to do is follow the illustrated wisdom of maoist jitter
minister of information nesa:
http://jit.playground.googlepages.com/onemetro.jpg
Use one source for timing, in this case train~, as you want to sync to
MSP, and use it to count through the movie frames "manually". See
patch.

And please don’t make so many new threads, it’s confusing me ;)

Good luck, g.

PS: See how posting a patch helps, Stefan? ;P

max v2;
#N vpatcher 53 44 858 764;
#P origin 19 -145;
#P window setfont "Sans Serif" 20.;
#P window linecount 1;
#P comment 161 273 34 196628 3.;
#P comment 211 40 34 196628 2.;
#P comment 353 542 34 196628 1.;
#P window setfont "Sans Serif" 9.;
#P message 129 91 31 196617 66.6;
#P number 129 216 53 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 142 272 14 196617 1;
#P newex 25 437 31 196617 dac~;
#P message 25 337 14 196617 0;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 25 304 64 1441802 past 5000;
#P newex 25 280 58 1441802 dsptime~;
#P button 146 26 56 0;
#P window setfont "Sans Serif" 9.;
#P message 185 105 33 196617 set 0;
#N counter;
#X flags 0 0;
#P newobj 230 180 66 196617 counter;
#P message 189 213 104 196617 frame_true $1 , bang;
#P newex 69 121 62 196617 train~ 66.6;
#P message 500 313 18 196617 16;
#P newex 307 149 76 196617 prepend read;
#P newex 500 472 37 196617 / 200.;
#P slider 500 334 15 128 0 1;
#P newex 409 471 27 196617 * 5;
#P window setfont "Proportional Serif" 10.;
#P comment 415 493 55 131727370 Frequency;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 409 535 80 1441802 cycle~ 1000.;
#P flonum 409 507 62 10 0 0 0 22 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont "Sans Serif" 9.;
#P newex 432 444 27 196617 + 55;
#P newex 412 395 84 196617 unpack 0 0 0 0;
#P newex 398 371 53 196617 jit.3m;
#P number 432 425 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 229 514 15 0;
#P message 351 572 28 196617 open;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 332 640 74 1441802 sfrecord~ 1;
#B color 5;
#P user ezdac~ 417 672 461 705 0;
#P window setfont "Sans Serif" 9.;
#P newex 427 576 52 196617 *~ 0.05;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 318 213 53 1441802 loadbang;
#P user jit.pwindow 241 307 82 62 0 1 0 0 1 0;
#P newex 242 275 160 1441802 jit.qt.movie @autostart 0;
#P window setfont "Sans Serif" 9.;
#P message 279 247 91 196617 read track2.mov;
#P user dropfile 307 76 363 136 0;
#P user panel 305 74 61 66;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 305 58 100 196617 Drop region for files;
#P comment 35 355 100 196617 make it stop again;
#P connect 25 1 30 0;
#P connect 30 0 31 0;
#P connect 31 0 32 0;
#P connect 34 0 33 0;
#P connect 32 0 33 0;
#P connect 36 0 25 0;
#P connect 29 0 36 0;
#P connect 27 0 35 0;
#P connect 29 0 28 0;
#P connect 27 0 26 0;
#P connect 32 0 12 0;
#P connect 34 0 12 0;
#P connect 28 0 27 0;
#P connect 25 1 27 0;
#P connect 26 0 5 0;
#P fasten 23 0 5 0 312 241 247 241;
#P fasten 4 0 5 0 284 270 247 270;
#P connect 5 0 6 0;
#P fasten 7 0 4 0 323 237 284 237;
#P connect 3 0 23 0;
#P fasten 8 0 10 0 432 618 392 618 392 632 337 632;
#P connect 12 0 10 0;
#P connect 11 0 10 0;
#P fasten 5 0 14 0 247 298 403 298;
#P connect 16 0 20 0;
#P connect 20 0 17 0;
#P connect 17 0 18 0;
#P connect 14 1 15 0;
#P fasten 8 0 9 0 432 633 422 633;
#P connect 18 0 8 0;
#P connect 15 1 13 0;
#P connect 13 0 16 0;
#P fasten 8 0 9 1 432 633 456 633;
#P fasten 22 0 8 1 505 561 474 561;
#P fasten 7 0 24 0 323 242 505 242;
#P connect 24 0 21 0;
#P connect 21 0 22 0;
#P pop;


March 20, 2007 | 10:33 pm

grg,

Wow!

Clearly you went through a lot of effort to debug my patch, thank you for that!

To show that my computer science degree is just the first step towards understanding computers :)

Even better you even explain why it happens, and reading it now it makes perfect sense.

The reason for the multiple posting was partly because I couldn’t rename my older posts, I’ll make sure I give them a good name from the start next time :)

Regards,
Ilias B.


March 21, 2007 | 12:23 pm

grg,

I have to thank you once more :)

I transferred your example to my "real" project, and it works like a charm!

I especially like the clever, sample accurate record start & stop timing that you set up :P

Greetings,
Ilias B.


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