hello stefan & list
cc-ing reply to list as this may well break code (henning & alex?)
>>> in general i think it would be better anyway to
>>> type the timetag field in the Bundle constructor more strongly, but
>>> maybe it would break too much existing code?
>>
>> as in
>>
>> data OSCTime = UTCr Double | NTPr Double | NTPi Integer
>>
>> that'd be ok. generally i'm happy with breaking things so long as
>> after the change the old code will become a type error.
>
> yes, personally i think it's much clearer (and less error-prone) like
> that.
following prompting by stefan, and i think earlier by henning, have
changed the timestamp for osc bundles from Double to a data type Time
with constructors UTCr, NTPr and NTPi for utc real, ntp real and ntp
integer timestamps respectively.
to port existing code change 'utc' time requests to 'utcr', and wrap
existing bundle timestamps in 'UTCr'. to write the scsynth 'now' time
use 'NTPi 1'. for real time rendering wrap zero based time stamps in
'NTPr' (not yet tested, will do so and add note to tutorial).
i tagged previous state as 0.4 and shifted the current hosc and hsc3
to 0.5. will upload 0.4 to hackage at some stage.
hope this is not too problematic.
>>> another issue i had with hosc btw: since timestamps are based on UTC
>>> seconds, it's impossible to send a bundle with a timestamp signifying
>>> now' (0x00000001).
>>
>> i think the 'now' time is zero, which you can send as below:
>
> IIRC the spec mentions 0x1 for 'immediately'.
>
>> withSC3 (\fd -> do { send fd (Bundle (-2208988800) [Message "/
>> status" []])
>> ; (Message _ d) <- wait fd "status.reply"
>> ; putStrLn (show d) })
>>
>> at least i get no 'late' error for the above. (-2208988800) is the
>> ntp/utc epoch difference, ie. (70 * 365 + 17) * 24 * 60 * 60
>>
>> that is not obvious though!
>
> yes, that's what i did, but as you say, it's not so obvious ;)
from brief testing using 'now = NTPi 1' seems to work correctly for
scsynth, and is hopefully less obscure!
regards,
rohan
_______________________________________________
haskell-art mailing list
[email protected]
http://lists.lurk.org/mailman/listinfo/haskell-art
