answer me this pid. i have a granular patch with absolutely tonnes of these things going off all the time, continuously, and it runs like clockwork. so where is this ‘ever growing amount of resources’ actually going? just checking activity monitor for max, all values are constant and don’t seem to be increasing at all.

now i’m not saying you’re wrong, as i don’t know the ins and outs of Max’s symbol tables and the like, but for every ‘no don’t do this’ post i usually find i’m doing exactly that, with no problems at all.

The efficiency of sprintf depends on what you’re doing with it. Every unique symbol in max is stored in RAM, and never free-ed until you close max. So if you’re using it for general formatting of input values, you’re likely going to be adding a large number of unique symbols to RAM, which in theory could begin to waste your memory resources – I don’t know if this applies in the same way to floats and integers………….If you’re using it for message parsing to grab file names or something similar, it’s a more appropriate object to use because you won’t be generating symbols very often.

So for general purpose things like formatting for line/line~ it’s not the best object to use.

-edit: With sprintf, if you’re using it to format the same things over and over, then it doesn’t really matter that it’s storing into RAM, as you’ll be replacing the same symbols over and over, not adding to it. The reason it does this is to speed up processing of things if done a second time, so in MikeS’s patch, it might be totally appropriate, if it’s not causing problems then why change it :) That’s not to say that there aren’t multiple ways of doing just about everything in max/msp, none of them are "best" in every situation. –

Since coffencigs is wanting to control audio playback, line~ is far more appropriate to use than line. You want to be controlling audio-rate processes at audio rate most of the time, or you’ll end up with clicks and glitches.

The pack>message>line~ method is a perfectly good way of doing it; simple and it works. If you want to be really pedantic, you could say that it’s inefficient because the message object will have to visually refresh often, wasting resources. However this is not something to worry about unless you start running into cpu-limits. I think also, that if you put it in a sub-patch/made it not visible in some other way, then it being a GUI object wouldn’t matter, as it wouldn’t have to refresh.

My advice is to just use pack>message>line~ and not think about all these little worries until you think they might be causing a problem, which is unlikely to happen. If you don’t like message, you could do it like this:

— Pasted Max Patch, click to expand. —

Copy all of the following text. Then, in Max, select New From Clipboard.

maybe i am mistaken, but when i hear something about "line format" i am
thinking of the MSP line~ object, where "float, float float" would the normal
way to trigger it.
and consecutive messages are not to be packed into a list ;)

Cheers for clearing that up Raja – I thought it would work!…………..I mis-understood Roman’s reply and double-checked the ($1, $2 $3) way with it outputting to the right inlet of another message, which of course screwed with the comma – making me think it wouldn’t work with line/line~…………….I’m silly :)

The comma in a message box is just shorthand for separating things. In the discussed case of line~, it is used to send an 0, followed by a list of value time pairs. This is no different from starting your list of pairs with 0 0.