ComfortableInClouds

Hi. I am trying to create a click triggered line~ whose variables can be changed at a signal rate (for interfacing with wave~ or play~ in an audio rate sequencer). I am in the process of debugging and have encountered a bizarre problem.

If you look at the while loop of my perform method, you'll see that every time a click is received (a 0 to 1 transition), the variable int 'count' is set to 0 (count = 0) and the short 'counting' is set to 1 (counting = 1; acts as a boolean variable). When count exceeds the value given to the second inlet (the variable lengthms, which is converted to lengthsr in the perform method), count is set to 0 again, and counting is set to 0 as well. In my output, I have the value of the boolean count.

Take a look at my example patch, a metro is sending a click every 1000 ms. My counter counts for 5000 ms (the value given to the second inlet). Therefore, the output should stay at 1, because the count is constantly reset before it ever reaches its destination value. But if you look at the scope connected to the outlet, you'll see that brief clicks are showing up rather than a continuous 1. This deeply confuses and bewilders me.

Any help is very much appreciated. A zip of my XCode project (including a compiled mxo) and example patch can be found here:

www.music.mcgill.ca/~kkapla/waveclick~.zip

bizarre-debugging-problems-with-simple-msp-code

looks like your array access x->connected[] uses indices 1, 2, 3 rather than 0, 1, 2? Perhaps this is causing bizarre stuff?

float lengthms = x->connected[1] ? *(float *)(w[3]) : x->t_length;
float start = x->connected[2] ? *(float *)(w[4]) : x->t_start;
float end = x->connected[3] ? *(float *)(w[5]) : x->t_end;


good catch, and that would seem to account for it, but i just made the changees, compiled, and tried it out. still the same error. strangely, when i hover above the MSP cords so that the value is displayed, the outgoing signal sometimes sustains at 1, as expected, but not perpetually like it should. perhaps tomorrow ill try compiling in 4.6, see if this problem might have to do with 5's SDK (i guess this because the hovering over the patch cord seems to change the behavior of the object, and this is something new to 5).

is local to your waveclick_perform() function!

Have you figured out how to debug using MaxRuntime?

thank you martin! the object is now fully functional. so many details in programming, it's easy for something so simple to be overlooked and thus undermine all the other code.

i have not figured out how to debug using max runtime. how can i do this?

Finally c74.. is it possible to pass the .mxo and possibly a .maxpat to MaxMSPRutime as an argument to the executable from within Xcode? That would be useful (like passing a .trak file to AULab when testing AUs for example).

go into menu Project -> New Custom Executable...


set the Executable Path to MaxMSPRuntime (you can't use MaxMSP due to the Pace protection so you need a test patch built already)


it's a good idea to go into Xcode -> Preferences... -> Text Editing, and turn on Show Gutter and Show Line Numbers and click OK


now you can set a breakpoint by clicking on a line number (e.g., somewhere in your perform() function would have been a good place for debugging this)


now do a "Build and Go" or "Build and Debug" and MaxMSPRuntime will launch, attaching to the debugger


drag your .mxo from the products group in Xcode onto MaxMSPRuntime on the dock


test it out and the debugger will stop when it hits your break point


go back into Xcode and choose menu item Run -> Debugger


at the top of the list on the left you should see the name of the function in which your breakpoint stopped the program


click on this function name and the code display should show the code and highlight the line where the code stopped


the list on the top right shows the contents of variables and memory etc


you can now step through your code (using step over/in/out buttons) a line at a time to see what it actually does and the changes this makes to variables etc


"continue" resumes the program until it hits the breakpoint again (which of course will be pretty soon if your breakpoint is in the perform routine! - especially so if it's in the while loop so place the breakpoint carefully...)



Bizarre Debugging Problems With Simple MSP Code