functions as arguments to other functions

[wppk]

i was wondering if it is possible to pass functions as arguments to other functions in Chuck.

Can anyone shed some light on this?

Thanks.

[Kassen]

do you mean like this?

[Kassen]

Welcome on board, BTW!

[wppk]

Thanks, I'm glad to be on board.

So basically if one writes a function that returns a specific type then any other function that returns that same type can be used as an argument?

here's what I've got going on.
it's a function for sweeping a midi cc.
I'm trying to write another function that will allow me to input this sweep function's arguments on the fly. i want to implement this new function as the sweep function's arguments.

//cc sweep

fun int sweep( int s, int e) {

s => int start;
e => int end;


for(0 => int i;;i++) {
while(true) {
e => end;
<<<start>>>;

100::ms => now;
if(start == end ) break; return start; }

while(true) {
s => start;
<<<end>>>;
100::ms => now;
if(end == start) break; return end; }}
}



MidiOut mout;
MidiMsg output;
mout.open(0);

while(true){
sweep(1, 10) => output.data3;
}



Also this sweep function works just fine when it is a void function but when i set it to return the integer then it only returns the value of the first argument.

For some reason the inc/dec operators or not showing up for <<<start>> and <<<end>> when I preview this, but they're supposed to be there. Just in case they're not when this posts.

[Kassen]

[Frostburn]

I was wondering if it's possible to pass a reference to a function as an argument to a function:

[wppk]

Thanks Kassen and Frostburn for your help. You guys are on it!

I think I understand this a bit more.

Frostburn, When i tried to run your example code I keep getting a syntax error in line 2 character 20. The Fun argument. So, I am a bit confused there. I'm using Mini audicle. Don't know if that matters or is any different from the command line.

[Kassen]

The Mini uses the same ChucK VM, compiler and parser as the commandline version.

The issue with Frost's example is that it's fictional code, a illustration of what he'd like to be able to do.

The problem here is that in ChucK functions aren't objects and so can't be referenced in that way. What you could try (I'm not sure this would fly) is make a dummy class with a single member function of type void named "do", then extend that towards new classes, one for every function you want, then write a function that takes a object of type "dummy" as a argument (I think this is legal), feed it a instance of one of the classes that extends dummy and run the .do() of that inside of the function.....

I suppose this might work but it's quite severe abuse, the idea is to have a class (which *is* a object) that's just a capsule for a single function and name all of those functions the same name so we can have them hitch a ride on the "object-ness" of the class.

I really wonder *why* functions aren't objects in ChucK, see also the topic Dewdrop World started a short while ago.

[Blue Hell]

[Frostburn]

[Kassen]

[Frostburn]

I'd have to do it like this anyway because I need vector functions.
I'm now also working on a similar scheme to create vector patches to abuse ChucK's .op functionality and SinOscs with .sync(1) to create quick and stable self modulating oscillator networks. Actually it will allow using any Ordinary Differential Equation that has only polynomial and sine terms for the phase of a SinOsc.

[heuermh]

Sweet thread.

I have been working in this direction since I found that you can't really chuck a gen into a variable. I am sorry the examples in the attachments aren't very interesting. Any help with the ease in/ease out transitions would be appreciated -- my math skills are poor.

michael

---

looper.ck
Description:		Download
Filename:	looper.ck
Filesize:	3.12 KB
Downloaded:	308 Time(s)

---

---

composite.ck
Description:		Download
Filename:	composite.ck
Filesize:	10.55 KB
Downloaded:	252 Time(s)

---

---

functor.ck
Description:		Download
Filename:	functor.ck
Filesize:	5.63 KB
Downloaded:	246 Time(s)

---

[Frostburn]

One thing I can think of is overloading the functions so that you don't have too many classes floating around that basicly do the same thing:

Your code:

[heuermh]

Thanks for the reply.

One, I like small classes. Keep it simple, do one and only one thing, etc.

Two, the point of all of the different "functor" interfaces is to allow other methods to accept them as parameters.

Note the different loop methods in looper.ck, one takes a Procedure (no parameters) and the other takes a FloatProcedure (one float parameter). The first doesn't provide any information to the "callback" procedure whereas the second provides a float between 0.0 and 1.0 that lets the "callback" procedure know how far along in the loop duration the current call is.

The first one you might use to trigger a sample, the second you might use with an interpolation function to fiddle with a parameter.

I will post an example that makes some noise shortly.

michael

[heuermh]

Here is a silly example. Note that the file would be much shorter with a proper import mechanism in ChucK.

Be sure to replace the file names with your own kick and snare samples.

Then try different interpolation functions, wire the interpolation functions to parameters other than freq, change loop rates, etc.

michael

---

example.ck
Description:		Download
Filename:	example.ck
Filesize:	3.22 KB
Downloaded:	194 Time(s)

---

[Kassen]

Looks very clean and nice!

Now, if we could only get around the namespace issues we could assign such objects to objects in running code and we'd have true updates of code without flushing all data.

[heuermh]

Not quite sure what you mean by that, but the following works as one might expect.

The procedure can be modified while the sporked function runs.

michael

---

mutable.ck
Description:		Download
Filename:	mutable.ck
Filesize:	1.26 KB
Downloaded:	169 Time(s)

---

[Kassen]

[Acoustic Interloper]

[Kassen]