dhjdhjdhj

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.

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?)

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'

update-contents-of-ui-object-immediately

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.

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.

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.

Update contents of UI object immediately?