Another solution could be to reduce the maximum number of messages sent to the gui per tick. IIRC this is a #define somewhere in the sources and you'd have to recompile pd, but I did this once on an advice of Miller and it worked very well (except for the slow gui framerate).
Apart from that there is an external called speedlim (you could also build that as an abstraction using vanilla) which might be more elegant than using a global metro.
-- Orm
Am Donnerstag, den 06. April 2017 um 12:12:42 Uhr (+0200) schrieb martin brinkmann:
On 05/04/17 16:15, Billy Stiltner wrote:
what is the global gui refresh metro ?
that is/was my (temporary) solution for the slow gui: a metro at 8 hz sending bangs to a global send and a [f] receiving these bangs before every slider/number/ which is updated via midi-ctl, counters, sequencers, whatever. while directly connecting a few midi-controllers to sliders could easily stall the gui (when the knobs are moved), this solution looked not very beautiful, but caused no dramatic cpu-spikes, even without 2d hardware acceleration.
and do other graphics cards have different options besides ShadowPrimary that allows fast access to pixel data?
i suppose so...
Can look it up but seeing that you have recently been dabbling in it...
only with my radeon card under linux, until i had success with the settings in xorg.conf.
Option "AccelMethod" "glamor" Option "ShadowPrimary" "on"
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list