<br><br><div><span class="gmail_quote">On 03/03/2008, <b class="gmail_sendername">Brad Garton</b> <<a href="mailto:garton@columbia.edu">garton@columbia.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><span class="q"><div>On Mar 3, 2008, at 11:55 AM, Kassen wrote:</div><br></span></div><div>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.</div>
</div></blockquote><div><br><br>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.<br>
<br>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.<br>
</div><br><br>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?<br>
<br><br>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.<br>
<br><br>Yours,<br>Kas.<br></div>