'debugging' in gen
is there a away to debug my gen statements. obviously I do not want to see all the signal data on a per sample basis (hmm well that could be nice actually).
right now I'm calculating some values based upon input parameters and then multiplying with the signal. but I'd like to see what the values I've calculated are?
The best way to "debug" is to just connect whatever signal you want to see to an outlet. You could temporarily add an extra outlet to the gen patcher for this purpose.
Exactly. And from there, all the usual suspects of debugging MSP programming, from number~, snapshot~ and particularly capture~ (if you want to see all the signal data on a per sample basis...)
Unfortunately this can be extremely tedious, especially with complex [codebox]s and such. Some sort of print function would be a godsend. Obviously it would need some sort of limits on it to avoid overflowing the Max window, like only printing out the first x samples worth of values that get sent to it, x being an argument you could set.
When you're dealing with nested subpatches in Gen~ it'is quite tedious to debug stuff...
It would be awesome to have some sort of "probing" like in MSP!
What's helpful is creating buffer, it doesnt need to be very large, I usually set them with 'sizeinsamps 128.' Say you create a buffer and call it 'debug.' Then all you need in gen is:
Buffer debug("debug")
at the top of the code or function, then if you want to know the value of x, you call
debug.poke(x, 1);
Then in your main patch, you set a qmetro to bang a '1' into a "peek debug" object every 50 milliseconds or whatever, and you can expand it to see as many values as you like. But remember many values are transient. So what I do is put a few utility histories at the top:
History zx1, zx2, zx3, zx4;
Then when I want to know the value of something inside a conditional statement or other place where it changes:
zx1 = x1;
The benefit of using peek is you can see inside functions without adding code to get something out of them, and as I noted in another thread, functions with multiple return values have bugs. This is in fact how I got functions with multiple return values working at all.
Also you don't need to worry about outlets disconnecting themselves on compile errors.
Ernest, that's a great technique! Thanks for sharing.
that's clever!! Thanks Ernest!