Forums > MaxMSP

Update contents of UI object immediately?


dhjdhjdhj
May 14 2014 | 8:33 am

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

Thanks


Lee
May 14 2014 | 10:01 am

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.


dhjdhjdhj
May 15 2014 | 4:46 am

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.


Christopher Dobrian
May 15 2014 | 6:18 am

You might try [delay 0] in lieu of [deferlow]. Also, for showing different text, the [umenu] object in ‘Label’ mode works well.



-- Pasted Max  Patch, click to expand. --

Emmanuel Jourdan
May 15 2014 | 6:35 am

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.


dhjdhjdhj
May 15 2014 | 7:11 am

@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.


Christopher Dobrian
May 15 2014 | 8:06 am

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.


dhjdhjdhj
May 15 2014 | 8:15 am

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.

Thanks

Viewing 8 posts - 1 through 8 (of 8 total)
Forums > MaxMSP