[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Timers



Well, yes. The usual way of handling timers in other languages are
that you create a timer instance, that is either one-shot or
repeating, and has a timeout value and a callback function. This
instance can then be cancelled. In some environments they might even
be paused and restarted, etc..

This is pretty useful in many cases. For example, you fire a one-shot
timer each time the user presses a button on your midi controller
(polyphonically) and if they release the button before the timeout,
the timer must be cancelled so it doesn't fire after the user released
a button. Since it's polyphonic, you need control over each timer
individually.

On Sun, Dec 30, 2012 at 5:41 PM, Scott Wilson <s.d.wilson@xxxxxxxxxx> wrote:
>
>
> On 30 Dec 2012, at 08:01, Scott Wilson <s.d.wilson@xxxxxxxxxx> wrote:
>
>>
>>
>> On 30 Dec 2012, at 03:58, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
>>
>>> There's also the case of stopping a periodic timer, then it's not only
>>> enough to disable the evaluation of a function.
>>
>> I'm not sure I understand. You'd just do periodic timers in the traditional fashion, by returning a rescheduling value. That's perhaps not the most intuitive method, but it's very flexible, and users must learn about it anyway, as it can trip them up otherwise.
>
> Oh I see, you want to be able to cancel just one item of a repeating timer? I wonder is that really common enough a need to require a class in Common?
>
> But I'm not especially bothered either way.
>
> S.
>
>>
>> S.
>>>
>>> Surely one can combine stuff to get a cancelable timer, but that would
>>> never be as straight forward as a dedicated timer class.
>>>
>>> Another solution would be to add the ability to unschedule an item
>>> previously scheduled on a clock. I think it would work by popping all
>>> items from the prioQ, and discard the one to be removed, and push the
>>> rest back again. This might be a good thing to have anyway, even if we
>>> add a dedicated simple timer class.
>>>
>>>
>>> On Sun, Dec 30, 2012 at 4:58 AM, Scott Wilson <s.d.wilson@xxxxxxxxxx> wrote:
>>>> Perhaps something more general would be useful, i.e. a wrapper which evaluates only conditionally would give the cancel-ability and also be useful for other purposes.
>>>>
>>>> Fdef could be used for this already I suppose.
>>>>
>>>> S.
>>>>
>>>> On 29 Dec 2012, at 15:11, Jonatan Liljedahl wrote:
>>>>
>>>>> SkipJack has a few differences:
>>>>> - the name of the class has nothing to do with "timer"
>>>>> - survives cmdPeriod (as you said)
>>>>> - most importantly, it always repeats, no one-shot timers
>>>>>
>>>>> Also it's rather complex compared to a simple lightweight timer, due
>>>>> to the cmdperiod-survival and storing skipjacks by name, etc. I think
>>>>> SkipJack has a clear and useful purpose (periodic timer that survives
>>>>> cmdPeriod), and that it would be nice with a separate simple and clear
>>>>> timer class similar or equal to the one I posted, instead of extending
>>>>> SkipJack.
>>>>>
>>>>> On Sat, Dec 29, 2012 at 9:31 PM, Jakob Leben <jakob.leben@xxxxxxxxx> wrote:
>>>>>> On Sat, Dec 29, 2012 at 4:54 PM, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
>>>>>>> sclang does not have Timers, in the usual sense of timers in other
>>>>>>> languages, like NSTimer in obj-c.
>>>>>>>
>>>>>>> There is someClock.sched, but those are not cancelable.
>>>>>>
>>>>>> Well, there is SkipJack. It survives CmdPeriod, but could easily be
>>>>>> extended to not...
>>>>>>
>>>>>> _______________________________________________
>>>>>> sc-dev mailing list
>>>>>>
>>>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>>>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>>>>>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> /Jonatan
>>>>> http://kymatica.com
>>>>>
>>>>> _______________________________________________
>>>>> sc-dev mailing list
>>>>>
>>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>>>>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>>>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>>
>>>
>>> --
>>> /Jonatan
>>> http://kymatica.com
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/



-- 
/Jonatan
http://kymatica.com

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/