Hey cHuCksters -- I've written a ugen to deliver values coming from inlets on the max/msp [chuck~] object into the chuck executing environment. The essential part of the function looks like this: CK_DLL_CTRL( maxinlet_ctrl_inletval ) { t_CKINT inletno = GET_CK_INT(ARGS); // inletvals[] is set from max/msp RETURN->v_float = inletvals[inletno-1]; } and is set up thus: func = make_new_mfun( "float", "inletval", maxinlet_ctrl_inletval ); func->add_arg( "int", "value" ); To get this to update during execution, I can use a script like this: maxinlet maxin; sineosc a; while (true) { // gets the value coming from inlet #1 1 => maxin.inletval => a.freq; 10::ms => now; } However, ideally I'd like the function to deliver/update the incoming value whenever it came from max/msp, something like this: maxin.inletval => a.freq; 3.5::second => now; (i.e. no loop in the script, but during execution any change coming from maxin.inletval would indeed affect the sineosc frequency). I suspect that I could set it up to tick somehow at the audio rate, but that seems overkill. Is there a way to do this in chuck? brad http:://music.columbia.edu/~brad

On Sat, 19 Aug 2006, Perry R Cook wrote:

I suppose your UG could become a higher class citizen within ChucK, capable of triggering asynchronous events. But that would be up to the gods of ChucK to decide...

What is the sacrifice-du-jour? Is it lamb this week, or have we moved on to fatted calf? Seriously, it's not that big a deal. I thought perhaps I missed something Totally Obvious, and figured it was worth a net-check. brad http://music.columbia.edu/~brad

Hi Brad!

However, ideally I'd like the function to deliver/update the incoming value whenever it came from max/msp, something like this:

(i.e. no loop in the script, but during execution any change coming from maxin.inletval would indeed affect the sineosc frequency).

If I understand this correctly, then you might make maxinlet a chuckian Event (as Perry pointed out like the OSC-related objects, as well as MIDI, HID, and a few other objects in ChucK). In that case, you can write code that looks like: // infinite event loop while( true ) { // wait on event inlet => now; // set freq inlet.inletval => s.freq; } This would only fire as updates came in from the inlet object. It should work, but the code ain't pretty. Look in chuck_lang.* and midiio_rtmidi.* for MidiIn related-stuff. I think the crucial components are: 1. the class 'maxinlet' should extend "Event" in the type_engine_import_class_begin 2. the actual C++ class that does the work should extend Chuck_Event, or at least hold a pointer to a Chuck_Event to be notified on event 3. the actual C++ class may want to have a circular buffer of some kind for incoming events 4. as events come in, they get put on the buffer, and .queue_broadcast() should be called on the Chuck_Event to be notified - the rest is handled by chuck 5. the chuckian class 'maxinlet' should also implement the can_wait() function. Wow, yuck - what a disaster. Needless to say, we hope to improve this for the upcoming import mechanism... Best, Ge!

yo, that thread reads keyboard input from a console/stdin. Its certainly not completely essential--Im not positive it could even be accessed unless someone started max from the command line and typed there. spencer On Aug 20, 2006, at 11:09 AM, Bradford Garton wrote:

ChuCk-godz --

The newer ChucK (1.2.0.6) is working well! One question about KBHitManager -- what does this do? I had to disable the call KBHitManager::init() in ulib_std.cpp because stopping/starting audio quickly was causing crashes (I think it was the thread sleep in kb_loop()). This is within max/msp, though, so it may not be of general interest...

brad http://music.columbia.edu/~brad

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Hi!

...

I have made a patch for the linux makefiles here : http://gentoo-sunrise.org/svn/reviewed/media-sound/chuck/files/chuck -1.2.0.6-makefile.patch

It just allowed to specify the CC, CXX and CFLAGS with the command line. It will be great if it will be integrated in the source because I need to rewrite the patch for each version.

This is now in CVS and will be in the next release. However, now CC defaults to 'cc' instead of 'gcc' on the systems - rh9, fc4 - I tested. I reckon on most linux 'cc' is soft-linked to 'gcc', but could this cause a problem in any case? Specifying CC and friends from the command line is nifty, nonetheless! Thanks! Ge!