right, there isn't a LiSa.read("filename"), and it would be super nice if there was one; i'll try to make that happen at some point.... for now, though, you can read a file in with SndBuf and then stuff it into a LiSa buffer for looping fun. i don't have time at the moment to hack up an example of doing this, but it should be just a matter of piping the output of SndBuf into LiSa for the appropriate amount of time; basically sampling the sample. a kludge, but should work for now! best, dan On Oct 10, 2007, at 12:25 PM, Atte André Jensen wrote:

Kassen wrote:

...

In one word; LiSa

Hmmm.

I know she's not not in the docs (but in the examples). But I couldn't find any mention (even tried, didn't work) about LiSa.load("sample.wav"). Is such a thing possible or should she sample in realtime?

-- peace, love & harmony Atte

http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 10/10/07, Daniel Trueman wrote:

for now, though, you can read a file in with SndBuf and then stuff it into a LiSa buffer for looping fun. i don't have time at the moment to hack up an example of doing this, but it should be just a matter of piping the output of SndBuf into LiSa for the appropriate amount of time; basically sampling the sample. a kludge, but should work for now!

What I tend to do is this (asuming "beat" is some musically sensible amount of time and twice that is longer then our sample); ------------------------ SndBuf buf => LiSa lisa => dac;; "my_sample.wav" => buf.read; 2::beat => lisa.duration(); //this is the important bit //notice "buf" will start with rate=1 and pos=0 meaning it will play automatically, once 1 => lisa.record; buf.samples()::samp => now; 0 => lisa.record; //clean up a little (saves some cpu) buf =< lisa; ------------------------ And that's it, from there on you can loop, granulate and remix to your heart's content. Not that hard. Hope this is of help to someone. Kas.

Hey All, Here is my boilerplate code for looping samples. Copy, paste, and enjoy. It should work until .loop becomes a language feature. I also like Dan's method of playing a sample into Lisa and then going. Is there a way to do this faster than realtime? I use a lot of long samples. --art SndBuf mysample => dac; "foo.wav" => mysample.read; fun void looper(){ while(true){ mysample.samples()::samp => now; 0 => mysample.pos; } } spork ~ looper();

On 10/11/07, Daniel Trueman wrote:

i believe that SndBuf has a valueAt() method, which you can get values with, so all LiSa would need is a similar valueAt() call to set values with and we could automatically load sounds into LiSa without passing time. i'll take a look at this soon; should be easy (whereas loading soundfiles directly into LiSa won't be so easy).

That would be nice! Especially with a get method for the same. That would be equivalent to my idea of overloading SndBuf.read() to accept arrays of floats to be assigned to it instead of pre-recorded samples. Great idea. Kas.

On 10/13/07, dan trueman wrote:

look for this in the next release:

lisa.valueAt(buf.valueAt(i), i * 1::samp);

Looks very good! Would it be possible to also support this; buf.valueAt(i) => lisa.valueAt( i::samp); or is that a given already? This second example looks slightly more ChucKian to me. Ge? Also, is LiSa interpolating? Or will we be required to specify a integer number of samples? Or will it round? Forcing integers wouldn't have to be a problem because for a arbitrary duration D we could go like this; (D / samp $ int)::samp But that could be a question here. Thanks for taking the time to do this, I look forward to morphing buffers already! Yours, Kas.

On 10/13/07, dan trueman wrote:

i knew there'd be some good questions!

Yes, it's unavoidable that things like this will lead to questions, but questions are good. Let's be happy so many aspects of ChucK are so questionable! ;¬)

i'll have to ask Ge how to do that; i don't know how to set things up so you can chuck to a function that needs two arguments. i agree it is more chuckian this way, and i first wrote the example that way before finding it didn't work. actually, is there another example of a method that has two args but will allow you to chuck to the first arg? if there is, i might be able to look at the source and figure it out. can't think of one offhand at the moment....

I tried to think of one too. but I can't come up with a very clear one. In my own opinion this write operation is somewhat like writing to a array so I think that's one reason to follow the proposed syntax... LiSa simpson => dac.chan(4); is somewhat like it as well, except that is a very different operation and we're not doing the actual writing ourselves manually. Erm... I don't know. Would like to be able to write classes that have member functions that work like that as well now that I think of it, but that is clearly Ge's area. Seems like a sub-section of "cross-chucking" in some way as well. Might be functionality we should have, funny how it only comes up now in this way.

LiSa is most definitely interpolating on read, but not on write. i'll look into the latter at some point....

That would be good, I think, because with this particular write operation there would be a implicit cast from float to int so that's implicit data-loss. I don't think it's all that obvious exactly *what* interpolation would mean in the case of writing single values and it gets more complicated; buf.valueAt(i) +=> lisa.valueAt( i::samp); That doesn't sound unreasonable to me either (basically it's a sort of mixing over-dub). Perhaps we should simply round to the nearest integer sample so people who have their own opinion on what interpolated writes mean in this context can implement that themselves in ChucK? Yours, Kas.

Hi list, On the same direction as my previous posts from yesterday, I'd like to know if anyone has a good tip (i.e. articles, pdfs, books, personal experience) for spectral transformations. Not only what you can do with spectrums but more in the direction of what could happen when you alter the mag-spectrum or phase-spectrum or both and how to solve possible problems (i.e. artifacts). Below I have attached a quick vocoder example written in chuck. So for those who want to enjoy it, just set a sustained music file to be read by "carrier" and speak thru your computer's mic. Again, artifacts will be present and quite noticeable! :-( Eduard ---------------------------- vocoder.ck SndBuf carrier => FFT fft_c => blackhole; // music signal "/Volumes/data/samples/music.wav" => carrier.read; adc => FFT fft_m => blackhole; // voice signal IFFT ifft => WvOut file => dac; 0.5 => carrier.gain ; // fft/ifft constants 2048 => int FFT_SIZE => fft_c.size => fft_m.size => ifft.size; FFT_SIZE/2 => int WIN_SIZE; WIN_SIZE/2 => int HOP_SIZE; // windowing: Windowing.blackmanHarris( WIN_SIZE ); // spectrum array: complex spectrum_c[WIN_SIZE]; complex spectrum_m[WIN_SIZE]; // temp variables: polar temp_polar_m, temp_polar_c; 1 => carrier.loop; while( true ) { // take ffts: fft_m.upchuck(); fft_c.upchuck(); fft_m.spectrum( spectrum_m ); fft_c.spectrum( spectrum_c ); // convert complex form to polar, assign magnitudes & back to complex: for( 0 => int i; i < WIN_SIZE; i++ ) { spectrum_m[i]$polar => temp_polar_m; spectrum_c[i]$polar => temp_polar_c; temp_polar_m.mag => temp_polar_c.mag; // store values. Re-use carrier's spectrum: temp_polar_c$complex => spectrum_c[i]; } ifft.transform( spectrum_c ); HOP_SIZE::samp => now; }

This seems something I should have done in the past, but I can't figure out how to return an array from a function. Couldn't find documentation nor examples. case 1: compiling error. This seems the more natural way to me. fun int return_array( int a[] ) { return a; } case 2: works, but the returned array is empty fun int[] return_array( int a[] ) { return a; } thanks, eduard

Yes, you are right it does work. Don't know why I was getting empty arrays... Thanks Cesare, Eduard On Oct 14, 2007, at 12:04 AM, Cesare Marilungo wrote:

eduard aylon wrote:

...

This seems something I should have done in the past, but I can't figure out how to return an array from a function. Couldn't find documentation nor examples.

case 1: compiling error. This seems the more natural way to me.

fun int return_array( int a[] ) { return a; }

case 2: works, but the returned array is empty

fun int[] return_array( int a[] ) { return a; }

Hi, case 2 works here:

[ 1,2,3 ] @=> int anarray[];

fun int[] return_array( int a[] ) { return a; }

<<< return_array( anarray )[0] >>>; //prints: 1: (int)

...

thanks,

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

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

Yes, it's unavoidable that things like this will lead to questions, butquestions are good. Let's be happy so many aspects of ChucK are so questionable! ;¬)

and occasionally upchuckable!

Seems like a sub-section of "cross-chucking" in some way as well. Might be functionality we should have, funny how it only comes up now in this way.

jah, it's interesting i agree, and would be nice to be able to do. it might also cause great internal chuck misery for Ge to implement! i'm sure he'll let us know....

would mean in the case of writing single values and it gets more complicated;

buf.valueAt(i) +=> lisa.valueAt( i::samp);

that's pretty cool....

That doesn't sound unreasonable to me either (basically it's a sort of mixing over-dub). Perhaps we should simply round to the nearest integersample so people who have their own opinion on what interpolated writes mean in this context can implement that themselves in ChucK?

i think for now that's the way it'll have to be, but there is at least a basic linear interpolation (or exterpolation) i could add for the writing function that wouldn't be hard. hopefully before the next release.... thanks! dan

Yours, Kas.

tor 2007-10-11 klockan 10:11 -0600 skrev Adam Tindale:

Hey All,

I also like Dan's method of playing a sample into Lisa and then going. Is there a way to do this faster than realtime? I use a lot of long samples.

Nope, not at the moment. Earlier, I have proposed a feature that would enable that, like this: 100::samp => blackhole; which means "throw the next 100 samples in into the hole", ie forward the shred timespace 100 samples. As pointed out, this wouldn't work with complicated oscillator-patches (we don't have the hardware to calculate five layers of frequency modulations and filters in a fraction of a samp, so lets not beat a dead horse. Gasten