Forums > MaxMSP

MAX/MSP bug? Scheduler? Strange script thing?

September 10, 2007 | 5:17 am

Hi everyone,

I have been debugging this patch for a week and can’t solve the problem so your help would be greatly appreciated. I included the small portion which gives me problems and gave you the algorithmic outline.

I am trying to dynamically load a buffer~, get its informations and then save them in a coll object. When the object is not in overdrive all works fine, but when I use it in overdrive, a bug occurs near the end. It has to do with a script disconnect. I can’t get it. Something do to with scheduling as the order of my patch seems correct when I trace enable.

Here is the outline of the algorithme:

1. Create new buffer for soundfile and connect it
2. Set the info~ object to match the new buffer~.
3. Load the buffer~ and get the infos from info~
4. Load the infos in a coll
5. Disconnect and bang when done.

So here is the patch in question, followed by another patch I use to test it. The second patch includes all the results I have got from my tests.

I really would appreciate some help. It’s a though one for me and I am starting to think this is a MAX/MSP bug. (by the way, I had to include a (del 5) in order to circument annoying check failed errors. Man! I hate when programming has to involve hacks because the language is faulty.

The patch:

max v2;
#N vpatcher 63 83 975 665;
#P origin 21 46;
#P newex 297 469 34 196617 del 5;
#P button 554 154 15 0;
#P newex 286 58 77 196617 prepend replace;
#P objectname tobuffer;
#P newex 584 152 221 196617 sprintf script disconnect tobuffer 0 sndbuff%i 0;
#P newex 584 129 32 196617 int;
#P newex 473 139 28 196617 * 17;
#P newex 415 163 127 196617 sprintf script new sndbuff%i newex 2 %i 131 196617 buffer~ snd%i;
#P newex 180 163 120 196617 sprintf script connect sndbuff%i 1 frombuffer 0;
#P newex 302 163 112 196617 sprintf script connect tobuffer 0 sndbuff%i 0;
#P newex 91 163 88 196617 sprintf set snd%i;
#P button 415 78 15 0;
#P newex 415 98 51 196617 counter;
#P outlet 554 199 15 0;
#P newex 417 308 82 196617 info~ none;
#P objectname frombuffer;
#N thispatcher;
#Q end;
#P newobj 584 247 58 196617 thispatcher;
#P button 297 439 15 0;
#N coll nuffbuff;
#P newobj 336 436 64 196617 coll nuffbuff;
#P newex 810 162 66 196617 sprintf snd%i;
#P button 278 349 15 0;
#P message 297 379 50 196617;
#P newex 297 350 61 196617 prepend set;
#P newex 297 403 191 196617 sprintf store %s %s %f %f;
#N comlet add path / del path;
#P inlet 415 30 15 0;
#P comment 433 30 98 196617 filepath of sound file;
#P comment 573 201 79 196617 bang when done;
#P comment 619 131 162 196617 wait till it’s all done to disconnect;
#P comment 196 128 222 196617 Dynamically create a buffer for the added sound;
#P comment 549 298 218 196617 1. Create new buffer for soundfile and connect.;
#P comment 549 314 226 196617 2. Set the info~ object to match the new buffer.;
#P comment 549 331 227 196617 3. Load the buffer~ get the infos from info~;
#P comment 549 348 121 196617 4. Load the infos in a coll;
#P comment 549 364 169 196617 5. disconnect and bang when done;
#P comment 549 273 137 196620 ALGORITHME OUTLINE;
#P comment 287 310 127 196617 get infos and load into coll;
#P comment 205 60 78 196617 name = tobuffer;
#P comment 336 471 361 196617 this del stops an error: type check failed: typemess: replace: corrupt object;
#P comment 719 446 100 196617 Whish I didn’t need this del 5 fix!!!;
#B color 14;
#P user panel 712 429 132 56;
#X brgb 232 0 0;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 430 291 100 196617 name = frombuffer;
#P fasten 27 0 29 0 420 145 96 145;
#P fasten 27 0 31 0 420 149 185 149;
#P fasten 25 0 20 0 422 331 283 331;
#P fasten 16 0 36 0 420 51 291 51;
#P fasten 25 7 18 0 492 336 302 336;
#P lcolor 13;
#P fasten 20 0 19 0 283 374 302 374;
#P connect 18 0 19 0;
#P connect 19 0 17 0;
#P connect 17 0 23 0;
#P connect 23 0 38 0;
#P fasten 27 0 30 0 420 152 307 152;
#P fasten 17 0 22 0 302 426 341 426;
#P fasten 21 0 17 1 815 397 362 397;
#P lcolor 13;
#P fasten 16 0 28 0 420 70 420 70;
#P connect 28 0 27 0;
#P fasten 27 0 32 0 420 153 420 153;
#P fasten 29 0 25 0 96 303 422 303;
#P connect 25 0 17 2;
#P fasten 27 0 33 0 420 134 478 134;
#P connect 33 0 32 1;
#P connect 25 6 17 3;
#P fasten 27 0 32 2 420 130 536 130;
#P fasten 35 0 37 0 589 173 571 173 571 150 559 150;
#P connect 37 0 26 0;
#P fasten 38 0 34 0 302 491 879 491 879 107 589 107;
#P lcolor 7;
#P connect 34 0 35 0;
#P fasten 32 0 24 0 420 235 589 235;
#P fasten 30 0 24 0 307 240 589 240;
#P fasten 31 0 24 0 185 243 589 243;
#P connect 35 0 24 0;
#P fasten 27 0 34 1 420 126 611 126;
#P fasten 27 0 21 0 420 123 815 123;
#P pop;

The testing patch:

max v2;
#N vpatcher 83 74 793 703;
#P comment 47 365 289 196617 < - click to test (make sure p.nuffsimple is freshly initialized);
#N vpatcher 40 55 220 301;
#P newex 21 70 31 196617 sel 1;
#P message 21 51 21 196617 $1;
#P button 34 101 15 0;
#P button 54 107 15 0;
#P newex 21 30 45 196617 loadbang;
#P message 54 126 14 196617 0;
#P user GSwitch 54 151 41 32 0 0;
#P message 34 126 14 196617 1;
#N comlet anything unblocks;
#P inlet 109 75 15 0;
#N comlet out;
#P outlet 39 191 16 0;
#N comlet in;
#P inlet 84 131 15 0;
#P connect 6 0 9 0;
#P connect 9 0 10 0;
#P connect 10 0 8 0;
#P fasten 2 0 8 0 114 96 39 96;
#P connect 8 0 3 0;
#P fasten 4 0 1 0 59 187 44 187;
#P fasten 4 0 7 0 59 187 104 187 104 103 59 103;
#P connect 10 1 7 0;
#P connect 7 0 5 0;
#P fasten 3 0 4 0 39 146 59 146;
#P connect 5 0 4 0;
#P connect 0 0 4 2;
#P pop;
#P newobj 18 473 50 196617 p block;
#B color 5;
#P comment 9 564 178 196617 overdrive results: – same sound is loaded in both buffers – information in coll is correct;
#P comment 9 533 106 196617 no overdrive results: – no bugs;
#P comment 10 262 374 196617 overdrive results: – internal results are similar to no overdrive – error: disconnect unable to find connection appears in max window – Strangely only the first buffer is not disconnected unlike the no overdrive test;
#P newex 95 170 81 196617 print end(test1);
#P newex 95 145 81 196617 print load(test1);
#P button 362 97 15 0;
#P message 362 117 50 196617 clear;
#N coll nuffbuff;
#P newobj 362 138 70 196617 coll nuffbuff;
#P message 513 227 50 196617 clear;
#P message 18 364 23 196617 0;
#P message 18 499 50 196617 1;
#P newex 100 441 85 196617 print load(test2);
#P newex 100 471 85 196617 print end(test2);
#P newex 9 116 66 196617 route symbol;
#P newex 18 413 66 196617 route symbol;
#N coll soundfiles;
#P newobj 18 392 73 196617 coll soundfiles;
#P newex 18 439 72 196617 p.nuffsimple;
#P comment 10 324 362 196626 TEST 2 ‘WAIT FOR END TO LOAD AGAIN’;
#P message 9 60 50 196617 dump;
#N coll soundfiles;
#P newobj 9 92 75 196617 coll soundfiles;
#P button 448 116 15 0;
#N coll soundfiles;
#P newobj 462 247 75 196617 coll soundfiles;
#P message 490 208 169 196617 store 3 :sounds:mac:Basso.aif;
#P message 476 190 169 196617 store 2 :sounds:mac:Hero.aif;
#P message 462 172 169 196617 store 1 :sounds:mac:Funk.aif;
#P newex 9 146 71 196617 p.nuffsimple;
#P message 448 154 169 196617 store 0 :sounds:mac:Frog.aif;
#P comment 478 63 194 196626 1 write your 4 soundfile paths here and save patcher!;
#P comment 5 23 190 196626 TEST 1 ‘DUMP TEST’;
#P comment 61 61 289 196617 < - click to test (make sure p.nuffsimple is freshly initialized);
#P user panel 471 54 216 91;
#X brgb 255 39 39;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P comment 10 194 286 196617 no overdrive results: – Only the last buffer to load is disconnected – Sounds stored in buffers are wrong because of this – Information stored in coll is correct – p.nuffsimple only bangs on last load;
#P comment 348 406 263 196617 A test routine for nuffsimple I have included the test results from my setup: Mac OS9 in classic mode in Tiger and MAX/MSP 4.0.5 The same results were achieved running this patch in MAC OS X MAX/MSP runtime 4.3;
#P comment 347 485 100 196617 The del object in nuffsimpl is used to stop the annoying check failed bug… explained in the object patcher;
#P connect 15 0 14 0;
#P connect 14 0 20 0;
#P connect 20 0 8 0;
#P connect 24 0 18 0;
#P fasten 23 0 18 0 23 520 10 520 10 385 23 385;
#P connect 18 0 19 0;
#P connect 19 0 17 0;
#P connect 17 0 34 0;
#P connect 34 0 23 0;
#P connect 24 0 34 1;
#P fasten 20 0 29 0 14 138 100 138;
#P fasten 8 0 30 0 14 167 100 167;
#P fasten 19 0 22 0 23 433 105 433;
#P lcolor 15;
#P fasten 17 0 21 0 23 465 105 465;
#P fasten 15 0 28 0 14 80 367 80;
#P connect 24 0 28 0;
#P connect 28 0 27 0;
#P connect 27 0 26 0;
#P fasten 15 0 13 0 14 80 453 80;
#P connect 24 0 13 0;
#P connect 13 0 7 0;
#P connect 13 0 9 0;
#P connect 7 0 12 0;
#P connect 9 0 12 0;
#P connect 10 0 12 0;
#P connect 11 0 12 0;
#P connect 25 0 12 0;
#P connect 13 0 10 0;
#P connect 13 0 11 0;
#P connect 13 0 25 0;
#P pop;

Thanks a bunch!


September 11, 2007 | 2:13 am

I need you! I need you MAX/MSP wizards!

* bump *


September 11, 2007 | 2:30 am

It’s probably just me, but I have never had much luck using
overdrive. I just leave it off. Maybe someone else has a different
perspective on this…?

> I am trying to dynamically load a buffer~, get its informations and
> then save them in a coll object. When the object is not in
> overdrive all works fine, but when I use it in overdrive, a bug
> occurs near the end. It has to do with a script disconnect. I can’t
> get it. Something do to with scheduling as the order of my patch
> seems correct when I trace enable.


September 11, 2007 | 2:40 am

i tested your first patch and didn’t run into any problems with or without overdrive. however i’m on os x and running max 4.6.

if you hate the delay so much, you can replace it with a deferlow, but if it works, i don’t see what the problem is.
when you are scripting patches, deferlow, or delay are both your friends.

another suggestion might be to replace all the gui objects with their non-gui equivalents (bang buttons with bang or better yet, trigger, Ggate with gate, etc.)


September 11, 2007 | 3:16 am

At 7:30 PM -0700 9/10/07, MarkDavid Hosale wrote:
>It’s probably just me, but I have never had much luck using overdrive. I just leave it off. Maybe someone else has a different perspective on this…?

I use it all the time, although I don’t do much in the way of scripting in Max.

With overdrive on event timing is tighter than without. Still not as tight as an audio rate approach, but certainly better than with no overdrive.

-C


Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno


September 11, 2007 | 8:29 am


September 12, 2007 | 8:16 am

Thanks!

I’ll give it a shot tonight and send you all my autoload buffer patches when I finish them.. The engine was my only problem just now.

Thanks a million… Hope it works in classic ;-( Don’t laugh!


September 12, 2007 | 8:50 am

On 12 sept. 07, at 10:16, Pierre-Emmanuel Levesque wrote:

> I’ll give it a shot tonight and send you all my autoload buffer
> patches when I finish them.. The engine was my only problem just now.
>
> Thanks a million… Hope it works in classic ;-( Don’t laugh!

I won’t laught: I still have an OS8.6 running on a Mac clone, and
sometimes uses Max3 to buid standalones for my PB145b…
I’m not sure [deferlow] was in the standard distribution before 4.3.
You can download a copy here:

http://www.cycling74.com/twiki/bin/view/Share/JoshuaKitClayton

p

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://www.crfmw.be/max


September 13, 2007 | 3:31 am

I tried your patch and it didn’t work because I don’t have the [deferlow] object in MAx 4.0.3. (You were right)

I tried to use the [defer] object instead but the whole system crashed hard core.

I’ll download [deferlow] and try again…

thanks.


September 13, 2007 | 7:36 am


September 13, 2007 | 7:45 am

On 13 sept. 07, at 09:36, Patrick Delges wrote:

> I just tried with 4.1 and it worked, but I don’t have a 4.0 version
> installed anymore!

By the way, 4.1 was a free update for people who own 4.0.x. You can
download this version here:

http://www.cycling74.com/downloads/maxmsp

ej


September 13, 2007 | 6:46 pm

MarkDavid Hosale schrieb:
> It’s probably just me, but I have never had much luck using overdrive. I
> just leave it off. Maybe someone else has a different perspective on
> this…?

Yes, for me its the opposite, if overdive is off, the timing goes
nuts… I didn’t had problems with overdrive since I switched to OS X…

Deferlow is definitely helping with scripting. I have some patches which
require that. Especially if they are embedded in a very big patch…

Stefan


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


September 15, 2007 | 2:18 am

Thanks, it works!

You guys are gods! I had been banging my head for quite a while on this.

As a weekend programmer, I have to say I am a little distressed concerning MAX. I originally thought that overdrive would simply give priority to the system over the interface. I now come to realize that it’s more complex and that the order of things can get messed up with overdrive.

Hmmm… MAX is great, but I always was bothered by the complexity of ordering commands inherant in the language. When a patch becomes huge, this can be a problem. And now I realize that with overdrive and scripting things can get even messier.

One shouldn’t have to resort to ‘sprinkling’ deferlow objects here and there to make sure the ordering of commands is respected.

I wish there was a MAX object ressembling Pyrite in which a lot of stuff could be coded by line. I don’t know if this is possible, but it would sure help and things wouldn’t be so messy.

Also, coll is a 2-D array. Is there a 3D one?


September 15, 2007 | 1:47 pm

Pierre-Emmanuel Levesque skrev:
> I wish there was a MAX object ressembling Pyrite in which a lot of stuff could be coded by line. I don’t know if this is possible, but it would sure help and things wouldn’t be so messy.
>
java and javascript?
> Also, coll is a 2-D array. Is there a 3D one?
jit.cellblock and matrixctrl are max objects that spring to mind, as
well as all the very very lovely jitter objects.


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