[chuck-users] easy random numbers
signal.automatique at gmail.com
Tue Nov 20 22:43:49 EST 2007
On 21/11/2007, Scott Wheeler <wheeler at kde.org> wrote:
Well, but the trick in that question is, "What if daylight savings time
> 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
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
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....
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users