[chuck-users] implementing a "wait for signal with timeout"

Robert Poor rdpoor at gmail.com
Mon Jun 8 17:20:14 EDT 2009


Hans:

You approach looks just fine for situations where you generate notes  
at a "musically sensible" rate.

My system isn't musically sensible: I'm generating dozens of "I just  
modified the end time of your event" messages every second, so  
sporking a shred and letting it die is not an option -- I'd be burning  
a megabyte of non-recoverable memory every second.

I suspect Dan Trueman is doing the same thing I'm doing, namely  
spawning secondary timing shreds as needed, which can be kept around  
and re-used after they've done their duty.

- Rob

On 8 Jun 2009, at 12:24, Hans Aberg wrote:

> On 8 Jun 2009, at 19:53, Robert Poor wrote:
>
>> In real-time music making, sometimes you want to wait for a signal  
>> (e.g. event.broadcast()) OR for a specific time to elapse,  
>> whichever comes first.  I've implemented ways to do this, but I'm  
>> not really satisfied with the code.
>>
>> Here's the problem: Lets say that your music is slaved to a  
>> metronome, and the metronome is allowed to change speed.  You want  
>> your music to stay sync'd to the metronome.  If you simply do:
>> 	now + (1/tempo)::second => time next_beat;
>> 	next_beat => now;
>> 	play_note();
>> you'll be in trouble if the metronome speeds up while you're  
>> waiting: your note will be late.  The fundamental problem is that  
>> once you execute "next_beat => now;", you're committed to waiting  
>> and there's now way to break out of it, short of killing the  
>> thread.  The problem with killing the thread is that you leak 88K  
>> with each thread (!!!).
>>
>> So here's the programming challenge: how would you implement a  
>> "wait for signal with timeout" that will block until it gets a  
>> signal OR a specified time has elapsed?  Since each thread costs  
>> 88K in non-reclaimed memory, you may create threads, but your  
>> solution must re-use them.
>
> You might check out the noteoff() function I implemented here:
>  https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004183.html
>
> There is a similar problem of future event rescheduling: a future  
> disconnect, that should be canceled, if there has been a new note- 
> on. So the future event gets a thread of its own, and when it  
> awakens, it checks if there has been a rescheduling - if so, it just  
> cancels the event.
>
> As 'chuck' does not have event scheduling and kill-threads was not  
> intended for massive use, this seems to be the only way. But it  
> works just fine.
>
>  Hans
>
>

--:
Robert Poor
e:	robert.poor at nbt-ventures.com
p:	+1 617 818 5115
b:	http://blog.nbt-ventures.com
--:
This message and the information it contains are the proprietary and  
confidential property of NBT Ventures and may be privileged. If you  
are not the intended recipient, please do not read, copy, disclose or  
distribute its contents to any party, and notify the sender immediately.
--:



More information about the chuck-users mailing list