Hi Matt and Kassen!

I'd still prefer all lower case or even being case insensitive for everything but user-defined stuff.

Some of us (me, for one) have a liking to lower case (and underscores) for some reason, which probably contributed to the existing lower case naming. However, we also felt that uppercase names for other stuff (Object, Event, UGen, STK UGens) was best, too. As we've all noted, this isn't so good for consistency. Another case of on-the-fly API design... After trying out the new uppercase system for a while (I had to convert all the examples and test them), it did grow on me. Either that or I was delusional...

So; it's not my own first choice but now it's consistent. Being consistent is good for learning syntax quickly and it decreases confusion.

Yup, I guess we should see in coming months how this works out.

One area I'd like to include in this is ugen parameters. Right now they are;

 LikeThis.likeThis

for STK ones and

LikeThis.like_this

Good idea. Since we are making api changes, we should update these as well. Thoughts from others?

All of this is just my own thoughts and I'm dyslexic so basing anything on my sugestions about writing may or may not lead to explosions, mild nausia, getting ex-communicated or sudden death.

Those risks reminds of something... oh yeah: chuck. Best, Ge!

Ge Wang escribió:

Hi Matt and Kassen!

...

I'd still prefer all lower case or even being case insensitive for everything but user-defined stuff.

Some of us (me, for one) have a liking to lower case (and underscores) for some reason, which probably contributed to the existing lower case naming. However, we also felt that uppercase names for other stuff (Object, Event, UGen, STK UGens) was best, too. As we've all noted, this isn't so good for consistency. Another case of on-the-fly API design... After trying out the new uppercase system for a while (I had to convert all the examples and test them), it did grow on me. Either that or I was delusional...

I'm totally the opposite, I like upperCase and don't like underscores, but can get used to any convention, so I'm all for convention, and the one that you suggested seems nice to me. For that respect:

...

One area I'd like to include in this is ugen parameters. Right now they are;

LikeThis.likeThis

for STK ones and

LikeThis.like_this

Good idea. Since we are making api changes, we should update these as well. Thoughts from others?

I agree with that. It's better to do it now than later. Best! -- jesús gollonet http://www.jesusgollonet.com/blog

Hi all, I am testing how ADSR UGen works and I am still not sure what do parameters to (time)members (attackTime, decayTime, etc) mean. Are they automatically casted to seconds? For instance: ADSR env; env.attackTime( .1 ); Does this mean that attackTime is 100::ms? I have tried to understand how ADSR works with the following patch: sinosc s => ADSR env => dac; env.attackTime( .01 ); env.releaseTime( 1 ); env.decayTime( 0 ); 1=>env.keyOn; <<< "begin note_on", env.state(), now/ms>>>; while( !env.state() ) { 1::samp=>now; if( env.state() ) <<< "end_of_attack", env.state(), now/ms>>>; } 1=>env.keyOff; <<< "begin note_off", env.state(), now/ms>>>; while( env.state() == 1 ) { 1::samp=>now; } <<< "end_of_decay", env.state(), now/ms>>>; while( env.state() == 2 ) { 1::samp=>now; } <<< "end_of_sustain", env.state(), now/ms>>>; while( env.state() == 3 ) { 1::samp=>now; } <<< "end_of_release", env.state(), now/ms>>>; while( env.state() != 4 ) { 1::samp=>now; } <<< "done.", env.state(), now/ms>>>; which ouput is the following: begin note_on 0 0.000000 end_of_attack 1 10.000000 begin note_off 3 10.000000 end_of_decay 3 10.000000 end_of_sustain 3 10.000000 end_of_release 4 2010.000000 done. 4 2010.000000 This would bean that attack lasts for 10::ms as env.attackTime() was set to .01. But then I don't understand why release ends at 2010::ms as releaseTime() is set to 1. Note that decayTime is set to zero and there is no sustain, as you can see from the output. Can anybody give me a hand on how to interpret the parameters to ADSR members? Thanks, eduard

Hi,

Aha. This happens because keyOff() is called before the ADSR is in the sustain state. I've fixed it so that the releaseTime is as expected even if keyOff is called way early: 1010.

thanks

The changes in CVS and will be included in 1.2.0.7.

When building chuck from cvs in macintel got the following: make -f makefile.osx bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_temp.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything make[1]: *** [chuck_instr.o] Error 1 make: [osx] Error 2 (ignored) No probs on ppc. If I'm not mistaken this was the very same error which happened when building tapestrea (first release) on macintels. any ideas how to fix it? thanks, eduard

Hi Ge, same thing after updating, 23:52:39 - :/CHUCK/chuck_dev/src$ make clean rm -f *.o chuck.tab.c chuck.tab.h chuck.yy.c chuck.output 23:52:45 - eaylon@jupiter:/CHUCK/chuck_dev/src$ make osx make -f makefile.osx bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_temp.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything make[1]: *** [chuck_instr.o] Error 1 make: [osx] Error 2 (ignored) ############### gcc version is 4.0.1 ############### 23:52:59 - /CHUCK/chuck_dev/src$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ################### chuck-1.2.0.6 builds ok. ################### 23:55:35 - /CHUCK/chuck-1.2.0.6/src$ make clean rm -f *.o chuck.tab.c chuck.tab.h chuck.yy.c chuck.output chuck 23:55:39 - /CHUCK/chuck-1.2.0.6/src$ make osx-intel make -f makefile.osx-intel bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_parse.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_vm.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_instr.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_scan.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_compile.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_dl.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_oo.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_lang.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_ugen.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_otf.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_stats.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_bbq.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_shell.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_console.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_globals.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c digiio_rtaudio.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c hidio_sdl.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c midiio_rtmidi.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c rtaudio.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c rtmidi.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_osc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_filter.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_stk.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_xxx.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_machine.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_math.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_std.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_opsc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_buffers.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_console.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_math.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_network.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_raw.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_string.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_thread.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_xforms.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_opsc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_hid.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_sndfile.c g++ -o chuck chuck.tab.o chuck.yy.o chuck_absyn.o chuck_parse.o chuck_errmsg.o chuck_frame.o chuck_symbol.o chuck_table.o chuck_utils.o chuck_vm.o chuck_instr.o chuck_scan.o chuck_type.o chuck_emit.o chuck_compile.o chuck_dl.o chuck_oo.o chuck_lang.o chuck_ugen.o chuck_main.o chuck_otf.o chuck_stats.o chuck_bbq.o chuck_shell.o chuck_console.o chuck_globals.o digiio_rtaudio.o hidio_sdl.o midiio_rtmidi.o rtaudio.o rtmidi.o ugen_osc.o ugen_filter.o ugen_stk.o ugen_xxx.o ulib_machine.o ulib_math.o ulib_std.o ulib_opsc.o util_buffers.o util_console.o util_math.o util_network.o util_raw.o util_string.o util_thread.o util_xforms.o util_opsc.o util_hid.o util_sndfile.o -framework CoreAudio -framework CoreMIDI -framework CoreFoundation -framework IOKit -framework Carbon -lstdc++ -lm ########################## I remember I had the same error when compiling taps for the first time. But then Ananya sent an update and the problem was solved. Below is the email sent at the time: On Jul 29, 2006, at 2:59 AM, Ananya Misra wrote:

There is an updated version of TAPESTREA (version 0.1.0.1) now available:

http://taps.cs.princeton.edu/release/

It fixes some problems we found with the MacOS X executable and also with compiling the code on osx.

If you come across any problems with this version, please let us know.

Thanks.

taps team

On Sep 11, 2006, at 11:06 PM, Ge Wang wrote:

Hi Eduard!

...

When building chuck from cvs in macintel got the following:

gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything

This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again?

Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error?

Anyone else encounter the same problem?

Thanks!

Ge!

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

Thanks, that fixes it. Sorry for wasting your time... eduard On Sep 12, 2006, at 3:39 AM, Ge Wang wrote:

Hi Eduard and Jukka!

I think we've found the "source" of the problem:

...

23:52:45 - eaylon@jupiter:/CHUCK/chuck_dev/src$ make osx

The CVS source is actually not in src, which has the old v1 code, but in chuck_dev/v2/. Please update in v2 and 'make osx'. Hopefully that should work.

We need to do something about src... what a disaster on our part.

---

make osx --> compiles for either ppc or intel make osx-ub --> universal binary

I think this should allow us to have cake and devour it too. Yum...

Please let us know if this works.

Best, Ge!

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

Did the ADSR work as expected?

Yes it did. Thanks. Now that we are speaking about envelopes I'd like to point out (correct me if I am wrong) the fact that Envelope UGen has only 1 time member, meaning attack and release will be always equal. Wouldn't make more sense to be able to define attack and release times separately for an AR envelope? Anyway, it can be accomplished by ADSR without decay nor sustain. Nothing to worry about, just being picky. cheers, eduard

An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine.

Are you suggesting to build the (universal)binary on a ppc and use that instead of compiling it on the intel? I kind of dislike it ...

Eduard/Jukka, Could you edit line 7 your makefile like to look like this: FLAGS=-D__MACOSX_CORE__ -D__LITTLE_ENDIAN__ -c and try recompiling? On our PPC systems, __LITTLE_ENDIAN__ is predefined when cross- compiling for x86, and I had thought that that would be the case on x86 systems also. However, judging by the nature of your build errors, it seems that this preprocessor macro might not be present. spencer On Sep 11, 2006, at 7:20 PM, Jukka Akkanen wrote:

On Sep 11, 2006, at 5:06 PM, Ge Wang wrote:

...

Hi Eduard!

...

When building chuck from cvs in macintel got the following:

gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything

This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again?

Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error?

Anyone else encounter the same problem?

I am seeing this, too. First, a disclaimer. I've barely gotten into using ChucK and hadn't looked at source until I heard about this problem. Somehow it wasn't very easy for me to find information about how to check out the source from CVS, but I found it in the chuck-dev mailing list archive, eventually. Maybe it's time I subscribe there, too.

The problem is that chuck_instr.h has this:

#define uint unsigned long

and sys/types.h has:

#ifndef _POSIX_C_SOURCE ... typedef unsigned int uint; /* Sys V compatibility */ #endif

which results in a:

typedef unsigned int unsigned long;

Fixing this is not the only hurdle, later on you'll see things like:

/var/tmp//ccAPkhiP.s:20471:no such 386 instruction: `fctiw' /var/tmp//ccAPkhiP.s:20472:no such 386 instruction: `stfd'

which is caused by inline assembly for the wrong architecure getting picked up from util_sndfile.h (looks like OS X does have lrint() and lrintf() so there should be no need for asm at all).

An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine.

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

On 9/10/06, Graham Coleman wrote: It seems like a cool way to do this would be implementing VST support.

Then chuck could talk to lots of plugins.

Not sure how difficult it us, but the "standardness" of it might make it worth it.

That would be nice, if asking for trouble; I think the VST standard isn't as standardised as one would like standards to be. For one thing we would need a way of getting a VST to report on it's parameters. This would also break the cross-platform nature of ChucK code. I imagine there would also be questions about some malfunction with plugin X where X costs 500 bucks and would be unavailable to the developers... The destroyFX stuff by itself makes little sense to me to port; many of those things could also be done with some tactfull controll of SndBuf (getting in the new habit there...). If we'dlike to get yet closer the first step IMHO should be a record mode for the SndBuf as a alternative for loading audio files? With a MIDI loopback driver and a straditional VST/AU/LADSPA/My_format host much of the same could be acomplished. Just my thoughts... Kas.

I guess, a good solution would be if ChucK could be extended with a "Plugin" UGen, that would support both LAPSDA and VST (and maybe the Mac format too), thereby allowing it to be crossplatform. Of course, I have no idea how difficult this sort of thing is.

you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~). whats so wrong with JACK again? :)

On Mon, 11 Sep 2006, carmen wrote:

you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~).

Yes -- I have built a few chuck~ instruments (and used 'em!) with pluggo, and audio i/o and MIDI i/o work fine and dandy. I guess you can bundle the run-time VST wrapper if you want to distribute the plugins. rewire also works well with chuck~. brad http://music.columbia.edu/~brad

It shouldn't be too difficult to get chuck~ running on WinXP, but I don't have time to do it now. Maybe over the semester intersession... brad http://music.columbia.edu/~brad On Mon, 11 Sep 2006, David Powers wrote:

Not everyone has a Mac ... Now if only I could run chuck in Pure Data, on WinXP, I'd be quite happy.

~David

On 9/11/06, Bradford Garton wrote:

...

On Mon, 11 Sep 2006, carmen wrote:

...

you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~).

Yes -- I have built a few chuck~ instruments (and used 'em!) with pluggo, and audio i/o and MIDI i/o work fine and dandy. I guess you can bundle the run-time VST wrapper if you want to distribute the plugins.

rewire also works well with chuck~.

brad http://music.columbia.edu/~brad _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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

2. Relying on MIDI means that one loses a great deal of resolution as

...

far as parameters go, being stuck with 0-127.

that's not true.. you can combine MSB and LSB frames, for 14 bit resolution. in theory you could do more but you'd be deviating from existing implementations.

Furthermore, not every

...

host makes it easy to address a particular parameter of a plugin through MIDI.

sounds like a host issue, or a plugin issue, or a plugin spec issue. the host i use allows to address any plugin parameter with OSC floats, and query for addressable parameters.. Chuck supports OSC doesnt it?

On 9/11/06, Kassen wrote:

For that exact functionality you'd be bussy for quite a while but the general gist of those and similar plugins isn't that hard to get with some tactfull SndBuf manipulation. You just periodically set the buffer position to some known value and the world is you oister for IDM/drill&bass style stuttering. I suppose you could get yet closer by using one of the delays but I didn't quite get into those yet.

Playing randomly from the buffer is easy enough, but I think there are some other things going on in the plugins I like most. However, I'm sure as ChucK develops it won't be so hard to do these things natively in ChucK. Much more important are the bread and butter tools, like compression and the like. Having the oscillators and filters is a good start.

If it were all up to me I'd like real OSC support in the major hosts and something like Jack for Windows. That should take care of the whole thing and on some days I wonder why those things aren't here already.

Kas.

I agree 100% - Jack for Windows would solve the problem nicely. As would OSC support in the major hosts. Plogue Bidule is a decent alternative I guess, with OSC support and plugin hosting, though it tends to be somewhat CPU hungry.

Hi!

I've just checked the Feature Request list on the Wiki and couldn't find anything related to Fourier analysis... are there plans to include it at some point?

FFT and friends are most assuredly on the list. The feature request page hasn't been organized in a while, I hope to sort it at some point. In fact, we are looking at providing audio analysis framework from within chuck. George Tzanetakis, author of MARSYAS, and us chuck folks have been brainstorming about this very thing. We will definitely keep you posted. Best, Ge!

How will frames flow through a chuck wire, with respect to time?

From picking the Brain of Mr. Tzanetakis and combining ideas with the existing ChucK time framework: The idea is to associate arbitrary meta-data with arbitrary samples in the chuck wire, including FFT frames and feature vectors as the program is specified. There would also probably be an extra 'wire' (a new sink like dac or blackhole, except it's for the timed meta-data). For example, to set up a STFT of 128 fft size, with 64 hop size, you could hook up a FFT unit which accumulates the past 128 samples, and every 64::samp take the FFT, and put the result frame on the meta-data stream, associated with the current time/sample. This stream could then flow through other analysis units that can query and take what's on the stream and add or modify the stream. The analysis units could at the same time serve as regular UGen's if you connect them to a dac driven UGen chain, making both analysis and synthesis cooperative and synchronized. Also, this, like the synthesis system, is demand driven, and should scale without additional overhead. This may sound like we know what we're doing, which is not quite the case until we can identify hurdles and work up a good implementation plan or something. This is similar to how things flow in MARSYAS 2. We've started plotting and designing for this in ChucK, though it's unclear when a prototype would be ready to try. Best, Ge!