Update contents of UI object immediately?
I’m trying to use a comment with a ‘set’ message to display progress of an operation that can take a long time, such as loading new VST objects, changing mixer values and so forth.
What I tried to do was
1) Send text to a comment object that we’re ‘loading’
2) DeferLow (I figured this would allow main thread to finish up and repaint the comment but it doesn’t seem to help)
3) Perform all the loading operations, which can take 5-10 seconds
4) Send text to comment that we’re ‘ready’
I need (I think) a way to force the equivalent of a ‘repaint’ on the object so that the new text is visible immediately.
Anyone know how to do this (or some other way to accomplish this task?)
I’ve faced the same problem and haven’t found a solution. Even thoug you deferlow, doesn’t mean that it defers after any pending ui events it seems, so I don’t think there’s any way to control this directly. I think you could only achieve this by using a js object and using a task inside it to do the work after making the ui update, but I’ve not explored this.
Bummer. Well, in the meantime, I found a simple Cocoa example for echoing UDP packets and so I’ve turned it into a little standalone message alerter. I can send it text via UDP and it displays the text instantly so I have just positioned it above my main Max patcher window. Not the greatest solution but in the short term it will get the job done.
You might try [delay 0] in lieu of [deferlow]. Also, for showing different text, the [umenu] object in ‘Label’ mode works well.
----------begin_max5_patcher---------- 576.3oc0V0ziaBCD8L7q.4yTD1AyG8Vu2S8ZU0JSvcWuBrQFy1jc09eu9Cnj MZgvljFo8PbzLdhm264YFmW78.khczNPvWC9Yfm2K9ddVWFGdC1dfFxts0jN aX.N8OhxGAgtsTzcJq6JZMYeP7neQuplpT6aotyFTR32CB90v1sD01GX76uS R2pbQ.Q4QwgAEol0jByJJNJ9e+DVkMO5b+EHZLM+VvUcrmsIAhz+FmadeCiq yuEwnImNTY8BO3D3jF6I.9ljQpAlMd022rDdYhx7xAiqVVMxr5.DaHUvFTDd d4n3ShZ.Oe0n.MUarrXj+IQLJWtSIb8cLYVsIeyRcL3Ohp.eWUAcUUkxdkRv u3oEI4irddtm.VOIgmAU5an79EKs0Wl1OKQHD10v63UZxRL5Ti+ZIR8EjhJu ixIk01sW7l1vfFQEc9dhMye6OhOEsY3gDvOnjp8FJGZV9tfToIaTTjVAtdcP 8OyBfoYYYHHdcMSgqXRiS+G+BhW7cnKeVylU0UYSNnlwO9oZKCL9eq70I5ka Gkfg9+fIJTQ6TLNQwzcfSwXdU8ffdfUUQ4GV5Tw5LUSV9G+t2iqENGkpYvys CN5LAOAZJtYnoXEZyotpZXUsBcs9P4BLGadyDlkYKmc+6pirPPqUpKRi0DFt ZbK+5yMTLbDw32fe7+A7iWQkR9MqRIYEpI9LQiajCos8Ipra3Hs.QOa9QgzX lFZMYbmo8wDfj9DaLdW.DodHqROgsW5FusKOUObSmmW8+KvIBlMS -----------end_max5_patcher-----------
You can make something like that works by setting first the text and then loading your vst~. The vst~ plugin is loaded in the main thread, and that’s also where the drawing happens. So basically while you’re loading the vst~ no drawing can happen in that thread which is doing all the work.
@Christopher —- not sure exactly what your patcher is supposed to demonstrate — from looking at it, I’m assuming the idea is to use the indices (0 and 1) to display ‘Loading’ and ‘Ready’ but on my Max 6.1.7 environment, I never see the "Loading"
@Emmanuel —- I AM first setting the text and then loading vst~….actually I’m loading a bunch of VSTs as well as restoring state for volume and other properties. There’s a deferlow in front of the vst~ loading process as I figured that would allow the main thread to finish (and display the text) but it’s not working properly. I have to look more carefully — I had this working fine under Max 5.1.9 but I’ve changed the way I do things a little in this redesign.
On the other hand, using a little external app to display state is quite useful as it gets updated the moment it received a UDP message so I can actually do better logging/printing/debugging than using the ‘print’ in the Max Window, which also can get delayed when other stuff is going on.
On my computer (MacBookPro 2.4 GHz i7 running OS 10.8.5 and Max 6.1.6 32-bit) the 16 million bangs from uzi takes about a second, so I do see the Loading… message. The example patch only works here if Overdrive is on.
Yep, works when I turn on Overdrive (which I don’t always have turned on).
However, my own stuff still doesn’t work so I’ll have to look further.
Forums > MaxMSP