firstArg question

Questions
2

Over the years, I came to feel pretty strongly that a clear and direct coding style is better in the long run than a terse, clever coding style. For a simple example, I used to write things like

if((variable = expression).notNil) {
	do something with variable
}

… because it would save a bytecode to access the variable. Now, I would rather write it like this:

variable = expression;
if(variable.notNil) {
	do something with variable
}

It’s slightly more verbose, but it’s also absolutely clear what is intended. Readability helps a lot when you come back to the code later.

When I read your third line, I have no idea what is the order of operations that you expect. The code doesn’t communicate well :laughing: and I find myself, to be honest, unable to answer the question of whether it’s possible or not because I don’t even know what is the “it” that may or may not be possible.

So, I suspect here that the solution is to write the order of operations that you mean, and avoid unnecessary cleverness.

firstArg is intended particularly for unit generators, when you want to force one UGen to come earlier than another in the graph, but you don’t need this UGen’s output, e.g.:

var sig = SinOsc.ar;
var phase = Phasor.ar(0, 1, 0, BufFrames.kr(buf));
var writer = BufWr.ar(sig, buf, phase);
var reader = BufRd.ar(1, buf, phase - 44100, loop: 1);

In this case, it’s possible, even likely, that BufWr might end up after BufRd. To force the writer first, it should be an input to reader but the reader doesn’t need BufWr’s output. So:

var sig = SinOsc.ar;
var phase = Phasor.ar(0, 1, 0, BufFrames.kr(buf));
var writer = BufWr.ar(sig, buf, phase);
var reader = BufRd.ar(1, buf <! writer, phase - 44100, loop: 1);

Now reader depends on a <! binary op, which depends on BufWr, so BufWr must be sorted first.

Since you aren’t doing that in this case, probably firstArg is not doing anything useful, and there should be a simpler way to write it.

hjh

1 Like