[Sc-devel] Re: [enhancement] SC thread priority?

[James Harkins]

I think it would have to be done somewhere around the getheap call c.  
line 428 in PyrSched.cpp. But the task retrieved would have to know  
what its priority is, which would involve structure changes  
elsewhere. Too much for me... (for today, anyway)

hjh


On Jul 29, 2007, at 2:32 PM, James Harkins wrote:

> I was thinking about this the other day as a "nice to have," but  
> this morning I was debugging a problem in my current piece (pretty  
> nasty one, in which stopping a process would leave a playing synth  
> behind, making unwanted noise), and I found that the cause of the  
> problem was a workaround that I use in my process code for SC's  
> lack of priority for items scheduled on a clock.
>
> Basically I would like to see a way to attach an integer to things  
> that are scheduled on one of SC's clocks, indicating that item's  
> priority relative to other things that are scheduled for exactly  
> the same logical time. Say, 0 could be the default, which would  
> keep the current behavior: if you have ten items scheduled for  
> logical time 100.0 and they all have priority 0, they would wake up  
> in arbitrary order (just as they do now). But if one of those  
> events had priority 1, it would wake up first and the remaining 9  
> would wake up in arbitrary order.
>
> I'm not talking about making SC threads preemptive. This is only  
> about giving the user some control over the order in which things run.
>
> I have a couple of reasons why this would be valuable:
>
> 1- Stopping threads at a precise time in the future. Say you have a  
> thread playing quarter notes at logical beats 1, 2, 3, 4 etc. You  
> know that it should play up to, but not including, beat 12, so no  
> problem, you schedule the "p.stop" function for, say, 11.9.
>
> Now you want to make this a general protocol applicable to every  
> process. That's fine as long as you never have any events between  
> 11.9 and 12.0. But is that a safe assumption? In theory, there is  
> no negative offset small enough to guarantee that you won't cut off  
> events that you want to keep, but if you schedule the stop for  
> 12.0, there is a 50 percent chance that the stop would wake up  
> after the 12.0 event is already played. But if the stop had a  
> priority of 1000000, then there would be no problem and no kludgy  
> workaround of offsetting the stop.
>
> 2- Communication between threads, where one thread depends on  
> information produced by another and the two threads might sometimes  
> gets scheduled for the same logical time. This can be a big deal,  
> especially as generative algorithms get more complicated.
>
> I've considered some alternate solutions. One is to schedule not  
> the two processes, but rather a dispatcher that would trigger the  
> subprocesses in the right order. That's trivial if there is a one  
> to one correspondence between events in the two processes, much  
> harder if the event deltas are independent. Also, this is harder if  
> I want to stop and start the children independently.
>
> The other, which I currently use in chucklib, is to schedule with  
> latency in terms of beats rather than seconds, so it becomes  
> possible to have a bass process with 0.6 beats latency and a chord  
> process with 0.5 beats latency. But the more I think about it, the  
> more it seems like a pretty fragile kludge, something that will  
> make it harder for other users to approach chucklib.
>
> So really seems that the most elegant solution is for the user to  
> decide what priority the threads ought to have. (Certainly it's not  
> too hard to imagine that someone *not* using my library would also  
> want to have inter-thread communication, and I don't see how to  
> support it in the common library at present.)
>
> I took a quick look at PyrSched.cpp, just enough to know that this  
> is not something you can figure out with only a quick look! But I  
> wanted to pose the question anyway... is this worth looking into? I  
> think it could be done in a way that wouldn't change existing  
> behavior unless the user explicitly sets the parameter.
>
> Thoughts or comments?
> hjh
>
>
> : H. James Harkins
> : jamshark70 at dewdrop-world.net
> : http://www.dewdrop-world.net
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
>


: H. James Harkins
: jamshark70 at dewdrop-world.net
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.create.ucsb.edu/pipermail/sc-devel/attachments/20070729/b27623ea/attachment.htm