>> And I see no reason why drawing a colorful GUI should require realtime >> privileges -- it's the other way round: the audio processing should >> have priority over the GUI. >> > >If the GUI is not running in realtime, then things like changing the >patch number from the midi stream won't be reflected instantaniously on >screen. To the contrary: You can almost imagine SuperMario running up >and down the interface with his little brushes, slowly repainting each >and every knob and slider :-) This happens even if the realtime audio >engine is near idle. > >The audio engine can still have priority over the GUI. That is to say: >The GUI is another realtime process albeit with a much lower priority >(than the audio engine.)
i think this is sort of absurd. yes, technically its true but "much lower priority" means "so much lower" that talking about the GUI as though its RT doesn't make any sense. look, there are only 60-80 *physical* redraws of a monitor screen per second. you have, therefore, *at least* 1/100 of a second before you've "missed" a "graphics deadline". not only that, but because of the properties of the human visual system, missing the deadline won't matter in anything like the way missing an audio deadline does. this has none of the characteristics of "real time" from my perspective. now, if the audio thread is burning so much CPU time that the GUI doesn't get to run, its certainly a problem. but step back - is it a problem you want to fix by raising the priority of the GUI thread so that it steals time from the audio thread? or even from a "disk butler" thread. no, i don't think so. it simply means that the user is asking too much from their current hardware (and/or that the s/w is badly implemented, but thats a different story). do you want the GUI thread to have higher priority than cron? sure. but if cron running is causing super mario to be a little sluggish, you've got deeper problems to solve first. --p
