Message vs value for storing numbers
Hi all.
I have a big patch wich i started working with since my first keystrokes with max.
i used a lot of messages to store and retrieve numbers.
the quiestion is. Should i change them for value objects Or bag?
what is the difference?
pros and cons?
thanks
message is a GUI object and even though it isnt animated (like numbers are) when a message passes, this requires a lot more CPU compared to v/pvar/i/f/zl reg.
so if you used hundreds and stuff is running in overdrive, you can change it and retrieve some karma points form the optimisation god. it is a matter of believe...
i have written myself a non-GUI message object but then found it too complicated to implement the prepend and append feature. :)
for me [zl reg] does most of it. and for contants, [t] is your friend.
Thanks for answering.
Question. What is the optimum way to store a list of fixed numbers to be sent by a bang?
For a single value?
and a fixed symbol list like ¨property value¨ ?
I used messages but i dont know...
I mean is the an object tha has the message funtion but is not gui?
i know you mentioned some, but whats the proper way to go?
you could use zl reg-- it stores lists (right inlet) and a bang in the left inlet pops the list out (but it is still stored until it receives a zlclear message) so it works pretty much just like a message object without the gui burden
message is a GUI object and even though it isnt animated (like numbers are) when a message passes, this requires a lot more CPU compared to v/pvar/i/f/zl reg.
This is somewhat right. If you store a message in a message object and click it the contents will be sent in the low priority thread (assuming overdrive is active). This is because all GUI changes are drawn in the low priority thread. If a metro object were to send a bang to that message object it would send its contents in the high priority thread because its not a GUI interaction, but a control rate execution. There is no GUI action from the latter, and so the CPU usage would be marginal or exactly the same as another method such as t/v/zl.reg.
If you're looking at ways you can create configurations for your patch. I would highly recommend getting your head around dicts. You can create key pairs in a dict, so its ripe for creating configurations files in a json style format with names associated to values which you can then extract in your patch.
on my machine avoiding message boxes has measurable benefits (about 80-90% faster):
That's interesting to see. It still wouldn't deter me from using message boxes to store stuff as this is 10000 bangs with an absolute difference of 2ms. I wouldn't typically generate a list with uzi like this in real time, and even then the performance hit is negligible to say the least.
Still I think thats quite a lot slower relatively and you might expect it to be similar.
I see is not a settled matter.
Even if the difference is so little, Wouldn it have the potential to interfere with the logical progression of events?
I really want to be negligible cause i wouldnt be able to live with it , and i would have to modifie a patch with so many messages. i mean. I love truth, but in this case, it would hurt so much.
In that timer patch, if you use Trigger, the difference is almost 2/3.
Again, can those differences interfere in the chain of events?
optimisation madness aside, what is shorter to write: "t" or "i" or "message"? "pak 0 0 0 0 0. 0. 0. 0." or "message $1 $2 $3 $4 $5 $6 $7 $8"?
and what are you going to do when you need more than 9 variables in messagebox?
would you waste 80% more of your CPU for a reverb when there is an identical reverb for less? if no, why do it for messages?
messageboxes are great during programming, but doesnt the class spezification "has a GUI" suggest to use it only in a GUI?
(i am artificially making up reasons now, because i am bored.)
>>Again, can those differences interfere in the chain of events?>>
if a millisecond in overdrive is "full", it is full.
the (tick) delay something causes is not the problem. but everything what drains CPU, loweres the limit of possible realtime jobs in total - even in other threads.
try running a bunch of metros at 1ms and see what happens to formerly fluid moving sliders.
“Optimization madness”
thats the point
i wanted to make music
seems like im studing for a math exam...
feels like the machine owns me
just for the record, I wasn't advocating one thing over the other, just illustrating the nature of the difference people are talking about: if you count the number of message boxes in your patch that you could replace with non-gui objects, you'd save around 0.00016 ms of cpu time per message box (if you were using my machine), so unless you have a patch with hundreds of message boxes each being triggered hundreds of times a second you're probably not going to notice any difference
Even if the difference is so little, Wouldn it have the potential to interfere with the logical progression of events?
Found this thread after a conversation with Ableton support regarding one of my M4L devices. While figuring out the issue, I came across a situation related to this topic. Inside a poly~, I used a combination of int + message box with $ for formatting a string to get a dict-value (ex 1). Now, when two different instances of the device on separate tracks in the set received a note from my sequencer simultaneously, the resulting message would around 50% of the time be false in the device that responded first: the message box would produce a string with the number stored in the second device, although the output of the int in the first device is correct. Thus, the message box is the guilty one. I first fixed it with another message box in between (see patcher ex 3), but reply from support pointed out the UI-aspect of message boxes, saying that using messages might cause the interference , and they suggested the solution with combine and prepends (ex 2). Finally, I implemented that idea with a zl.reg (ex 4). It's functioning properly now. Because of this I started searching, read this thread and decided to go through the task of replacing also all message-situations in my sequencer patch (no M4L, but also a big poly~ core). I replaced almost all message box situations with zl.reg/prepend/append/i/f/t etc. and that indeed seems to offer an improvement in performance (have to do more playing to verify how much this is ). But the conclusion here: yes, apparently using message boxes can mess up the logic too.
of course it shouldnt so if it is the object, it is a bug.
did you check these two versions against each other outside a poly~, too?
order issues are mostly known in a context with poly~ and bpatcher.
Checked the false version, when the error appears inside poly~, the outside version is still correct. Compare output in the image after the selected line with the ones above.
looked in your patch now.
you use the r/s in the poly, too?
r/s is a common source of user errors to scramble message order.
Yes, I’m aware of that, but I use t’s to make sure that is avoided. It would also not explain the false outcomes compared to the correct ones. The two message box solution also works properly. And there is no s/r in between the int (always correct) and the false message box (false sometimes on simultaneous hits, not when apart). I can only explain the error in the string formatting with the message box in poly, or am I missing something here?