bug: [train~] in 4.6.1?

Aug 29, 2006 at 4:23pm

bug: [train~] in 4.6.1?

Summary:

[train~] seems to be ignoring its arguments, has an unexpected
default pulse width, and outputs a value of 0 for 2000 ms after dsp
is started.

Expected Results:

[train~] generates a pulse wave with a period of 1000 ms, a pulse
width of 0.5.
[train~ 5000 0.5] generates a pulse wave with a period of 5000 ms and
a pulse width of 0.5.

Opening the patch using different methods should yield the same
results. Behavior should be consistent after closing and reopening
the patch.

Actual Results:

[train~] and [train~ 5000 0.5] both generate a pulse wave with a
period of 1000 ms, a pulse width of 0.99, and an initial period of
2000 ms at a value of 0.

Opening the patch using different methods yields different results:

Copy text -> New Patcher -> Paste will yield the results listed above.

Copy text -> New from clipboard results in all [train~]s generating a
pulse wave with a period of around 15ms, with the exception of
[train~ 50], which will generate a pulse wave with a period of 1000 ms.

After the patch has been saved, closing the patch and reopening,
without quitting MaxMSP, yields another set of results: After
reopening the patch, all [train~]s generate a pulse wave with a
period of around 50ms.

Specs:

Mac OS 10.4.7, PB G4 1.5, MaxMSP 4.6.1/Jitter 1.6.1

I have tried un/reinstalling MaxMSP. No change in behavior.

So – can anyone else confirm this, or is it my problem?

-David

———–

max v2;
#N vpatcher 7 48 506 429;
#P window setfont “Sans Serif” 9.;
#P window linecount 4;
#P comment 373 94 100 196617 initial period after dsp is started is
2000 instead of 1000.;
#P window linecount 3;
#P comment 147 187 100 196617 pulse width appears to be something
like 0.99 , not 0.5;
#P number 334 117 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 334 97 35 196617 timer;
#P window linecount 2;
#P message 421 181 47 196617 ; dsp stop;
#P message 420 146 55 196617 ; dsp start;
#P number 315 171 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 315 151 35 196617 timer;
#P button 315 43 15 0;
#P user scope~ 4 227 134 357 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P user scope~ 138 227 268 357 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P button 160 117 15 0;
#P button 178 156 15 0;
#P button 160 79 15 0;
#P button 159 41 15 0;
#P newex 117 98 53 196617 train~ 50;
#P newex 105 136 83 196617 train~ 5000 0.5;
#P newex 117 60 53 196617 train~ 10;
#P newex 129 22 40 196617 train~;
#P comment 334 45 100 196617 click to start;
#P window linecount 3;
#P comment 303 190 100 196617 regardless of the argument , the
period is 1000.;
#P connect 2 0 11 0;
#P connect 4 0 10 0;
#P connect 2 1 6 0;
#P connect 3 1 7 0;
#P connect 5 1 9 0;
#P connect 4 1 8 0;
#P connect 12 0 13 0;
#P connect 7 0 13 0;
#P connect 13 0 14 0;
#P connect 12 0 17 0;
#P connect 6 0 17 0;
#P connect 17 0 18 0;
#P connect 7 0 13 1;
#P connect 6 0 17 1;
#P connect 12 0 15 0;
#P pop;

#27373
Aug 29, 2006 at 9:34pm

Quote: David Stanford wrote on Tue, 29 August 2006 09:23
—————————————————-
> Summary:
>
> [train~] seems to be ignoring its arguments, has an unexpected
> default pulse width, and outputs a value of 0 for 2000 ms after dsp
> is started.
>

I am not having this problem. I tried a few different ways of making this patch, and they all work the way I would expect from the help file.

Macbook Pro, 2 gig, 10.4.7,Max 4.6.1

mz

#82737
Aug 30, 2006 at 3:29am

Thanks for the report, we’re looking at it.

-A

#82738

You must be logged in to reply to this topic.