<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=""><span class="q"><div><br></div></span><div>I had a problem with the 'pull' model, though, in trying to craft a Ugen that</div><div>would allow me to send UI input to chuck from an external environment.</div>
<div>This was in the chuck~ object, where I hoped to be able to set up a way of</div><div>connecting data coming from max/msp objects (sliders, etc.) into an</div><div>executing chuck script.</div></div></blockquote><div>
<br><br><snip><br><br>If I understand correctly I don't think this is a "problem with the pull model" per-se but more of a issue in two very different models touching each-other.<br><br><br>I don't think linking all MAX "cables" to ChucK "Ugen connections" is the most sensible way of linking them. Some MAX cables will represent concepts closer to ChucK code or events while others will indeed be more like Ugen-connections.<br>
<br>How hard/possible would it be to represent such a slider as a variable event member and the changing of the slider as broadcasting the event? Perhaps a sort of virtual protocol could be created, something like Hid or MIDI except linked to MAX objects instead if hardware objects?<br>
<br>I would say that here "crafting a event" might be a more fertile solution then "crafting a Ugen". My knowledge of MAX is rather rudimentary though.<br><br>Hope that's at least of some help,<br>
Kas.<br></div></div>