On 21/11/2007, Scott Wheeler
starts tonight?" I should have made that more clear.
That may sound like a contrived example, but to put it in context, let's say that you have a multimedia installation that's doing something connected with time. You've got ChucK running and it may sit there running for a week. Every day it's supposed to do something at noon that is synchronized to other parts of the piece. So you compute a duration until noon tomorrow and chuck that to now. But then it doesn't work.
Yes, that's a good question. I myself should clearly have been more clear too because I tried to at least point out that I admired that issue. I have no idea how to solve this, we could use a sort of homunculus solution and trust computers are getting their time/date and info on changing opinions about time and date depending on location from a internet server but audio is quite possibly the worst field to apply that to because it's fairly normal to keep dedicated audio computers offline.
There are faculties on the systems to handle those things -- either via system APIs or using something like boost in the background, it's more a question of how much of that would need to be exposed in a time class for ChucK.
Yes, I agree.
Well, I suppose the question that I'm really hinting at is, "What problem are you trying to solve?" That's really the question behind API design. For a lot of potential answers to that question the answer results in an API that's a bit of work to implement. "ChucK doesn't support time." isn't really a good starting point. "I'd like to be able to do ..." is better. For the one proposed case so far (seeding the random number generator) that seems to be more of a problem that there's a bug in ChucK's code somewhere and there I feel like the right solution is fixing the bug. :-)
I agree there too, this seems a bit too serious to blame Windows for it, my bet is that in the Windows version of the random generator something is going wrong and this should be our first priority. Most of the things I would like to do with time would work just fine with a series of calls that would report hours, minutes, seconds and ms since the last midnight in my timezone and according to the system/bios clock. A single call to just report the amount of samples since the last midnight would be fine as well, disregarding daylight savings time is no major issue to me. This would be enough for installations to change the mood of the piece depending on the time of the day or to make sure you stop playing at exactly 11:30 as promised to the stage manager, etc. Clearly it wouldn't be enough on it's own to have a gradual development from noon to noon and not glitch if the clock is put a hour back in the meantime but if we know at what date we start the installation and we know when the clock change will happen it would still be enough to work around that with some exceptions and extra rules/counters. You're right that I don't have any specific clearly defined issues that need solving right now. I'm after this because I found that toying around with ChucK code and sounds tends to become more evocative when it's somehow linked to the "real" world. Adding support for MIDI or HID often makes a program more interesting because it seems linked more directly to "our reality". It's from that perspective that I think some link between "ChucK time" and "real time" might help create things of amusement or artistic value. As of yet I don't believe international banking systems depend on ChucK to make sure the world economy will keep running and to make sure interest rates are adjusted for leap-seconds. At this point it might be interesting to wonder how long a ChucK program has ever been run at all.... Yours, Kas.