M.J.W.

I am still a bit new to Max 7, and I am currently working on a bit larger project and all in all it seems to go fairly well, but there is still something wrong in my program. I am trying to trace the program flow by putting "print" objects everywhere. The problem for me is mainly that these number boxes in my project seem not to update their actual value on the outside. The strange behaviour is that some number boxes actually do update their numbers shown on the outside, while other's don't. Why is that? And how do you debug your program's? I find it fairly difficult to trace the behaviour of my program, because these number boxes are misleading me. If I attach a "print" object I get different values then what is shown on the number box itself.

So I am really looking for more info about this update behaviour of these number boxes and tips on how to trace program flow and debug it.

Edit: To be clear, my real bug is something else than these number boxes that are not updating, but because of these number boxes not updating makes it hard for me to find the real bug.

I am still a bit new to Max 7, and I am currently working on a bit larger project and all in all it seems to go fairly well, but there is still something wrong in my program. I am trying to trace the program flow by putting "print" objects everywhere. The problem for me is mainly that these number boxes in my project seem not to update their actual value on the outside. The strange behaviour is that some number boxes actually do update their numbers shown on the outside, while other's don't. Why is that? And how do you debug your program's? I find it fairly difficult to trace the behaviour of my program, because these number boxes are misleading me. If I attach a "print"  object I get different values then what is shown on the number box itself.

Edit: To be clear, my real bug is something else than these number boxes that are not updating, but because of these number boxes not updating makes it hard for me to find the real bug.


trying-to-debug-but-number-boxes-not-updating-their-value-make-it-difficult

Actually I think there might be a problem because my number boxes should be updating. I am using the "zl iter" and I thought it would create some kind of for loop for me, but that is maybe not really the case? The numbers are all put out immediately with zl iter? Even though you treat them as elements in a loop?

I could also create some kind of for loop without the iter object... maybe that will help?

the [zl iter] will just break a list in individual numbers, and output them one after the other immediately. You can do use them as they are output, but if you send them to a numberbox for example, you will only see the last one.

The [print] will print all of the values received (not only the last), so that is probably why there is a difference between the values you see at the console window and the numberboxes.

If you post that part of your patch it might be easier to find the actual problem.

The [print] will print all of the values received (not only the last), so that is probably why there is a difference between the values you see at the console window and the numberboxes. 

I was experimenting a bit with metro and now I am actually able to get the number box to change while it is iterating through the list. This can be seen in the attached patch: 'metro_iteration.maxpat'. This behaviour is something I would like to have in my other patch named 'canPlay.maxpat.

However, with [zl iter] in my 'canPlay.maxpat' I am not able to see the changes in the number boxes while [zl iter] should be iterating through the lists. So now I am wondering whether the only difference between iterating with metro or with [zl iter] is only visual or if this also has consequences for the program order/functionality? (note that you cannot really run 'canPlay.maxpat' becaues it depends on other patches)

Because in my 'canPlay.maxpat' I am doing a lot of processing for each 'iter' step. But maybe the 'zl iter' goes way faster than my calculations steps I do after that? With metro you can change the speed. So would metro be better?

I am used to program in Java and really used to make for loops etc, but I do not really know what the best method for these kind of loops is in Max. There seem to be several options, like the zl iter or metro, or uzi. etc.

Because in my 'canPlay.maxpat' I am doing a lot of processing for each 'iter'  step. But maybe the 'zl iter' goes way faster than my calculations steps I do after that? With metro you can change the speed. So would metro be better?

I am used to program in Java and really used to make for loops etc, but I do not really know what the best method for these kind of loops is in Max. There seem to be several options, like the zl iter or metro, or uzi. etc.


The [metro] has a 5ms period, so its it not "instant". The [zl iter] is instant, so you will not see the value "moving" in the numberbox.

The calculations you do after the [zl iter] will be fine, and done for each one of the values, even if passed through a numberbox.

Simply, the numberbox can't update its graphics so fast, so you only see the last value it gets.

Metro would be useful to iter through number lists maybe if your calculations were too heavy, so you don't get a "frozen" patcher.

I don't recommend using metro unless you specifically want/need to.

With [zl iter] even if your calculations are so heavy that each one "lags" you patch, they will still be done, with only downside that you get a lagged experience!

The [metro] has a 5ms period, so its it not "instant". The [zl iter] is instant, so you will not see the value "moving" in the numberbox.
The calculations you do after the [zl iter] will be fine, and done for each one of the values, even if passed through a numberbox.

Simply, the numberbox can't update its graphics so fast, so you only see the last value it gets.
Metro would be useful to iter through number lists maybe if your calculations were too heavy, so you don't get a "frozen" patcher.
I don't recommend using metro unless you specifically want/need to.

Thank you Nikolas! That is exactly what I wanted to know.

you can also do [print this] and [print that] in case you dont already know, and you should check out the third party object [printit] if it is available for your max runtime.

and to see the actual dataflow in your patch, check out the tracing mode menu, where you can go step by step through your process.

Thanks. About the print object I already know and I am also using that. However, I thought initially that something was wrong because the number boxes were not updating. But that appears to be normal with [zl iter]. After replacing all my [zl iter] objects with a similar configuration with [metro] objects the number boxes are changing.

I did not know about the tracing mode menu, will have a look at that.

Trying to debug but number boxes not updating their value make it difficult