Larry's idea sounds good. On SGIs I was planning to set a virtual alarm and measure whether the CPU had eaten more than 90% of the processor, in which case it would automatically sleep for 10 msec every 100 msec or so. But I don't know how this will work out under NT. The good thing is it doesn't use threads at all so should be easy to port among unixes at least, if we're given that ALARM signals can reach high-priority processes. Is that true of Linux???
On another matter, I think "duplicate" should indeed do something smarter, and also the command-1, etc, menu items, which should (perhaps) place the new object directly under the most recently created one, and, if you use the shift key, make a connection to it as well (sprouting an inlet for the purpose.) But I'm hoping to be able to stall the "comfort issue" another month so I can try out a solution for data structures first..
Miller
Miller Puckette wrote:
Larry's idea sounds good. On SGIs I was planning to set a virtual alarm and measure whether the CPU had eaten more than 90% of the processor, in which case it would automatically sleep for 10 msec every 100 msec or so. But I don't know how this will work out under NT. The good thing is it doesn't use threads at all so should be easy to port among unixes at least, if we're given that ALARM signals can reach high-priority processes. Is that true of Linux???
I don't know too much yet about signals on Unix, but I haven't heard anything about problems with signals on Linux with POSIX Real-time processes, and I do read the Linux newsgroups.
But I don't know anything about the ALARM signal specficicly.
Hopefully Guenter knows more...
Larry
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
Larry Troxler writes:
Miller Puckette wrote:
Larry's idea sounds good. On SGIs I was planning to set a virtual alarm and measure whether the CPU had eaten more than 90% of the processor, in which case it would automatically sleep for 10 msec every 100 msec or so. But I don't know how this will work out under NT. The good thing is it doesn't use threads at all so should be easy to port among unixes at least, if we're given that ALARM signals can reach high-priority processes. Is that true of Linux???
I think much more simpler would be do to the own watchdogging:
- the point is if pd has a higher priority than pd-gui then you can
use pd-gui to do the setting of a flag and pd to watching this, so
- if pd sees pd-gui "out of sync" then he reduces the calculationpower
by maybe:
- first reducing sending TCL/Tk stuff and as a
- second thing dropping schedules slices (DACs slips)... and as a
- third stopping pd-process.
mfg winfried ritsch
--- DI Winfried Ritsch - ritsch@iem.mhsg.ac.at --- INSTITUT FUER ELEKTRONISCHE MUSIK- University of Music and Dramatic Art Tel. ++43-316-389-7210, Fax.++43-316-389-7008
Winfried Ritsch wrote:
I think much more simpler would be do to the own watchdogging:
- the point is if pd has a higher priority than pd-gui then you can
use pd-gui to do the setting of a flag and pd to watching this, so
- if pd sees pd-gui "out of sync" then he reduces the calculationpower
by maybe:
Yes, but what if there's an infinite loop in pd, either as a bug within PD, or as an infinite messaging loop created by a user's patch?
Larry
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
-
Larry Troxler -
Miller Puckette -
Winfried Ritsch