[chuck-users] delay times of STK delays seem to be 1 sample off?

Kassen signal.automatique at gmail.com
Mon Mar 3 14:25:16 EST 2008

On 03/03/2008, Brad Garton <garton at columbia.edu> wrote:
> On Mar 3, 2008, at 11:55 AM, Kassen wrote:
> Could be -- how is chuck set up to respond to 'events' during script
> execution?  I'm missing something, I think.  Although this is max-oriented,
> I suspect that the pd chuck~ probably has a similar situation.

Well, typically in order to respond to a event (be it a custom one or Hid/
Midi) you need a shred that is waiting for that event. from there on this
shred may do any number of things depending on  what's needed but most
likely in this case would be updating a variable, then resume waiting.

What you could do is extend event to hold both the name of the variable and
it's new value, then have some shred wait for this and update variables as
new values come in? I wouldn't do anything else in that shred as likely
there will be quite a few such events and we wouldn't want to miss them or
cause CPU strain.

I have no idea how this would work out in practice, but at least this would
make it easier to also communicate integers, strings and triggering pulses.
Ugens only do float, after all. Perhaps the cleanest way is to have a MaxIn
object in ChucK that would work exactly like MidiIn, except referring to
virtual ports of the "~ChucK" object instead of MIDI ports?

It's only logical that you run into this as the two systems are quite
different but I would imagine it to be quite worthwhile. If you just make
ChucK conform to the way MAX does things there is much less benefit of
having a ~ChucK object, I imagine.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080303/d02f98f8/attachment.htm 

More information about the chuck-users mailing list