print object – problem with time and deltatime messages
Hi,
A quick search doesn't seem to show that anybody else has this issue, but I think there's a slight problem with the time and delta time messages to print. For me, anything you send to the print object should show up on the max console, but now "time" and "deltatime" don't print, and any message that starts with time or deltatime not only doesn't print but may give a bad number error if the second element is not a number. Considering that the idea of print is to print everything, it's kind of unfortunate that such common messages were chosen as attributes. If the messages were "printabsolutetime" and "printdeltatime" users might never accidentally use the same names, but I can't be the only person who has tried to print "time" or "deltatime" lately...
Anyway, I don't know how long these messages have been a part of print. They might be the cause of some mysterious "bad number" messages that I have been getting in older big patches. So I imagine that they can't be changed.
I have a compromise solution though. How about checking to see if the messages time and deltatime are followed by a zero or a one for them to be considered as the time and deltatime attributes. "time 1" turns on the time attribute, "time 0" turns it off, but "time", "time to go", "time 2", "time -1" or "time 1000" all just print to the console. Same for deltatime.
I know this breaks the convention of "non zero turns on, zero turns off", but if there's one object where this is justified, it would be print. Also, definitely a message time or deltatime followed by a symbol should just print – the "bad number" in this case is kind of silly... :-)
Thanks for listening!
best,
Tom
mesage time followed by anything then 0 or 1 turns
time attribute off and throws error
unless you insert tosymbol, which is a simple fix
Hi,
Thanks for the response. Yes, tosymbol avoids the error, but it's not a real fix because it takes an extra step and also adds quotes. Ideally, there shouldn't be common attribute names in objects that are likely to receive any and all messages. I have the same problem with zl which has the attribute "mode" that never ceases to cause me to have to regexp from mode to mode_ and then back to mode. zlmode would have done the trick. Just like printtime or printdeltatime would have done for print.
Also, there's a case where tosymbol doesn't help, and that's if you send the symbol "time". The tosymbol doesn't change anything in this case.
I was doing a very straightforward thing iterating a list of parameter names to the console, and the "time" parameter was being skipped... So this was a real world issue.
Assuming changing the attribute names is not an option, which I clearly understand, I still think that time and deltatime should print, time and deltatime followed by anything that is not 0 or 1 should print, and only time and deltatime followed by 0 or 1 should change the attribute. I don't see why it's better to have a bad number error than to just print the message. I can't imagine that a huge number of patches would break with this, and I for one already lost close to an hour today between figuring this out and writing messages to the list... :-)
Thanks,
Tom
p.s. looking at the other attributes to print, "level" could easily cause the same problem. Why just not have used "alertlevel" - much less likely to use by accident than level. :-)
one way to solve it would be to use some kind of general ID
for modes and attributes in messages, like @mode 1 ,
but then someone else would chime in and complain that
such message can't be printed ...
by the way where do you see quotas added in console ?
no idea why print has such features anyway, it could have been done with timer&co where needed.
but i would solve it by making an abstraction which filters out the "time" in lists beginning with "time" and replace it with "• time" before giving it to print.
Thanks Roman, and source audio. No shortage of workarounds, for sure. But I was hoping to not have to "work" so hard... ;-)
Source audio, If I do a tosymbol, I get quotes... See image.
best,
Tom
Sure, I see it, only that in my max 8.1.11 version quotas are not visible...
As you can see on the screeshot in my first post.
must be another "improvement" in higher max versions