Forums > MaxMSP

Help with datacramming

November 29, 2007 | 4:44 pm

Hi all,

discovered some irregularities in this patch.
It is a derivate from a bigger one, which crams 224 Kbyte in a char
matrix.

Even with 10 numbers this patch doesn’t work, although it should.
What am i missing here ?
-
How come a delay command sometimes does then again does not solve this ?
It’s supposed to end a thread isn’t it ?
-
On the whole i’d like to get an idea how this thread bussiness in
general works,
how much of a load you can let it have,
how to test for malfunctioning and the like.
-
Asking questions on behalf of a silent majority.
regards DO_Ray.
-> PATCH ->:
max v2;
#N vpatcher 9 44 684 521;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 313 139 108 196617 Main Patch elsewhere;
#P message 221 145 14 196617 2;
#P message 206 145 14 196617 1;
#P number 176 177 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 215 175 38 196617 gate 2;
#P message 93 156 14 196617 0;
#P message 221 227 14 196617 1;
#P message 383 57 67 196617 < for qmetro;
#P toggle 366 58 15 0;
#P message 25 157 65 196617 goto 1 , bang;
#P newex 180 376 30 196617 s DO;
#P message 180 355 14 196617 1;
#P message 11 404 412 196617 2 3 4 5 6 7 8 10 42 43;
#P newex 32 379 78 196617 prepend append;
#P message 11 131 22 196617 set;
#P newex 11 92 66 196617 t b b b b 2;
#P button 11 63 15 0;
#P message 11 45 33 196617 start;
#P message 310 229 14 196617 1;
#P newex 319 56 43 196617 route 1;
#P button 319 94 15 0;
#P newex 319 111 35 196617 s Say;
#P newex 319 37 30 196617 r DO;
#P number 271 255 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 243 141 15 0;
#N vpatcher 504 144 886 475;
#P origin 0 -2;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 60 42 48 196617 pack 0 4;
#P number 88 21 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P message 72 23 14 196617 3;
#P number 18 62 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P outlet 214 149 15 0;
#N comlet DEST;
#P outlet 310 257 15 0;
#P message 287 177 20 196617 42;
#P message 310 177 20 196617 43;
#P message 249 177 14 196617 8;
#P message 233 177 14 196617 7;
#P message 218 177 14 196617 6;
#P message 198 177 14 196617 5;
#P message 182 177 14 196617 4;
#P message 164 177 14 196617 3;
#P message 265 177 20 196617 10;
#P message 148 177 14 196617 2;
#P outlet 55 257 15 0;
#P inlet 55 22 15 0;
#P newex 173 88 40 196617 t b b b;
#P newex 159 132 30 196617 t b b;
#P newex 147 110 30 196617 t b b;
#P newex 133 88 30 196617 t b b;
#P newex 118 132 30 196617 t b b;
#P newex 106 110 30 196617 t b b;
#P newex 92 88 30 196617 t b b;
#P newex 81 132 30 196617 t b b;
#P newex 69 110 30 196617 t b b;
#P newex 55 88 30 196617 t b b;
#P newex 55 62 131 196617 spray 10 1;
#P connect 11 0 25 0;
#P connect 28 0 0 0;
#P connect 0 0 1 0;
#P connect 1 0 12 0;
#P connect 2 0 12 0;
#P connect 3 0 12 0;
#P connect 4 0 12 0;
#P connect 5 0 12 0;
#P connect 6 0 12 0;
#P connect 7 0 12 0;
#P connect 8 0 12 0;
#P connect 9 0 12 0;
#P connect 10 0 12 0;
#P connect 11 0 28 0;
#P connect 26 0 28 0;
#P connect 27 0 28 0;
#P connect 0 1 2 0;
#P connect 0 2 3 0;
#P connect 0 3 4 0;
#P connect 0 4 5 0;
#P connect 0 5 6 0;
#P connect 0 6 7 0;
#P connect 0 7 8 0;
#P connect 1 1 13 0;
#P connect 0 8 9 0;
#P connect 2 1 15 0;
#P connect 0 9 10 0;
#P connect 3 1 16 0;
#P connect 4 1 17 0;
#P connect 10 1 24 0;
#P connect 5 1 18 0;
#P connect 6 1 19 0;
#P connect 7 1 20 0;
#P connect 8 1 14 0;
#P connect 9 1 22 0;
#P connect 10 2 21 0;
#P connect 13 0 23 0;
#P connect 15 0 23 0;
#P connect 16 0 23 0;
#P connect 17 0 23 0;
#P connect 18 0 23 0;
#P connect 19 0 23 0;
#P connect 20 0 23 0;
#P connect 14 0 23 0;
#P connect 22 0 23 0;
#P connect 21 0 23 0;
#P pop;
#P newobj 180 323 41 196617 p 1-10;
#P newex 243 227 27 196617 t b i;
#P newex 222 255 27 196617 int;
#N counter 1 10;
#X flags 1 0;
#P newobj 243 205 68 196617 counter 1 10;
#P newex 222 276 48 196617 pack 0 1;
#P newex 222 296 79 196617 spray 6 1;
#P button 170 68 15 0;
#P newex 170 86 66 196617 t b b b b 0;
#P newex 170 48 35 196617 r Say;
#P newex 226 109 30 196617 s DO;
#P user lcd 310 30 128 128 1 1 0 0 0;
#P connect 18 0 19 0;
#P connect 19 0 20 0;
#P connect 20 0 21 0;
#P connect 22 0 23 0;
#P connect 21 0 23 0;
#P connect 20 1 26 0;
#P connect 10 2 22 0;
#P fasten 20 3 30 0 58 151 98 151;
#P connect 2 0 4 0;
#P connect 4 0 3 0;
#P fasten 17 0 32 0 315 252 329 252 329 165 181 165;
#P fasten 20 4 32 0 72 141 181 141;
#P connect 5 0 10 0;
#P connect 10 0 24 0;
#P connect 24 0 25 0;
#P fasten 20 4 31 0 72 140 220 140;
#P fasten 17 0 31 0 315 249 329 249 329 166 220 166;
#P connect 34 0 31 0;
#P connect 33 0 31 0;
#P fasten 20 2 29 0 44 207 226 207;
#P connect 9 0 8 0;
#P connect 8 0 6 0;
#P connect 6 0 5 0;
#P connect 3 4 1 0;
#P connect 29 0 8 1;
#P fasten 3 2 11 0 203 134 248 134;
#P connect 11 0 31 1;
#P fasten 26 0 7 0 30 202 248 202;
#P connect 31 1 7 0;
#P connect 7 0 9 0;
#P connect 9 1 6 1;
#P fasten 30 0 12 0 98 248 276 248;
#P connect 9 1 12 0;
#P connect 7 2 17 0;
#P connect 13 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 14 0;
#P connect 13 0 27 0;
#P pop;


November 29, 2007 | 6:06 pm

It’s unclear to me what you’re trying to accomplish, but assuming you are trying to gather numbers in the bottom message box, I notice one thing. When you hit the start button, the last thing you hit this message box with is a "set" message. "set" with nothing following it will clear the box.

At 5:46 PM +0100 11/29/07, DO_Ray wrote:
>Hi all,
>
>discovered some irregularities in this patch.
>It is a derivate from a bigger one, which crams 224 Kbyte in a char matrix.
>
>Even with 10 numbers this patch doesn’t work, although it should.
>What am i missing here ?
>-
>How come a delay command sometimes does then again does not solve this ?
>It’s supposed to end a thread isn’t it ?
>-
>On the whole i’d like to get an idea how this thread bussiness in general works,
>how much of a load you can let it have,
>how to test for malfunctioning and the like.
>-
>Asking questions on behalf of a silent majority.
>regards DO_Ray.


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


November 29, 2007 | 6:17 pm

Quote: DO_Ray wrote on Thu, 29 November 2007 08:44
—————————————————-
> Hi all,
>
> discovered some irregularities in this patch.
> It is a derivate from a bigger one, which crams 224 Kbyte in a char
> matrix.
>
> Even with 10 numbers this patch doesn’t work, although it should.
> What am i missing here ?
>
>

It seems to work fine for me. Did you mean for the last bang from your "start" trigger to bang the message set to the message box? What this patch does is fill up a message box with a list (in a fairly Byzantine manner) and then erases it, real quick. Either disconnect that set message, or hang a print from [prepend append] to see that everything is working.

For your bigger problem, you might need to work with Overdrive on, rather than off. And, search the Max manuals for "queue throttle." Max has different lists of things to do: the queue for things that happen "right now", the scheduler for things that happen at a certain time (eg metro; usually higher priority), servicing things like drawing the UI and checking on the mouse state, etc. They all are in a delicate balance, which can be tweaked. Look in the Options menu at "Performance Options…". Objects such as defer, deferlow, qmetro are helpful, as is delay (which moves bangs from the queue to the scheduler) and other timing objects.

Cheers,

mz


November 30, 2007 | 8:58 am

DO_Ray schrieb:
> Even with 10 numbers this patch doesn’t work, although it should.
> What am i missing here ?

I miss a description what "doesn’t work" as well as "should" mean.
Don’t consider others are being able to read thougts. I can’t… ;-)
(You could place it as comment into the patch…)

> How come a delay command sometimes does then again does not solve this ?
> It’s supposed to end a thread isn’t it ?

Most likely you have an order of execution problem. Best is to use trace
to find out how each step of your patch works…

Good luck

To make this thread helpfull for others, try to figure out yourself
(take your time…). If it helps give us a quick note what the problem
was. If it doesn’t, come back with a better description what you want to
achive…

Stefan


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


November 30, 2007 | 1:00 pm

On 30 Nov 2007, at 09:58, Stefan Tiedje wrote:

> DO_Ray schrieb:
>> Even with 10 numbers this patch doesn’t work, although it should.
>> What am i missing here ?
>
> I miss a description what "doesn’t work" as well as "should" mean.
> Don’t consider others are being able to read thougts. I can’t… ;-)
> (You could place it as comment into the patch…)
>
a general explanation of these terms and how they relate towards one
and other would be most welcome:
difficult words from deferlow: queue, high priority, low priority queue.
difficult words from qlim: interrupt, scheduler, overdrive,
‘interrupt safe’.
difficult words from qmetro: backlog the queue
these come from the max reference manual.

>> How come a delay command sometimes does then again does not solve
>> this ?
>> It’s supposed to end a thread isn’t it ?
>
> Most likely you have an order of execution problem. Best is to use
> trace to find out how each step of your patch works…
>
> Good luck
>
> To make this thread helpfull for others, try to figure out yourself
> (take your time…). If it helps give us a quick note what the
> problem was. If it doesn’t, come back with a better description
> what you want to achive…
>
What i achieved is: using jit.matrix,jit.spill and iter to quickly
compute an expression and put the result in an other matrix.
What happend is a major stutter whilst computing, but no crash
Thanks for the help Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>


November 30, 2007 | 1:01 pm

On 29 Nov 2007, at 19:17, mzed wrote:

>
> Quote: DO_Ray wrote on Thu, 29 November 2007 08:44
> —————————————————-
>> Hi all,
>>
>> discovered some irregularities in this patch.
>> It is a derivate from a bigger one, which crams 224 Kbyte in a char
>> matrix.
>>
>> Even with 10 numbers this patch doesn’t work, although it should.
>> What am i missing here ?
>>
>>
>
> It seems to work fine for me. Did you mean for the last bang from
> your "start" trigger to bang the message set to the message box?
> What this patch does is fill up a message box with a list (in a
> fairly Byzantine manner) and then erases it, real quick. Either
> disconnect that set message, or hang a print from [prepend append]
> to see that everything is working.
>
the last ‘set’ is a mistake .
> For your bigger problem, you might need to work with Overdrive on,
> rather than off. And, search the Max manuals for "queue
> throttle." Max has different lists of things to do: the queue for
> things that happen "right now", the scheduler for things that
> happen at a certain time (eg metro; usually higher priority),
> servicing things like drawing the UI and checking on the mouse
> state, etc. They all are in a delicate balance, which can be
> tweaked. Look in the Options menu at "Performance Options…".
> Objects such as defer, deferlow, qmetro are helpful, as is delay
> (which moves bangs from the queue to the scheduler) and other
> timing objects.
>
I looked in reference manual and found explanations for qlim,
deferlow and qmetro using the word queue, so other objects don’t use
the queue ?
see relpy on stefans reply for the issue.
Thanks for the help , mz
>
> –
> || michael f. zbyszynski — molecular gastronimist
> || http://www.cnmat.berkeley.edu/
> || http://www.mikezed.com/
>
>
>


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