I want to load a new buffer into a synth, while the synth running. I thought specifying the buf as argument and then doing synth.set(\bf, ~new_buf) would do, but I get ^^ ERROR: Message 'addKr' not understood. RECEIVER: nil instead. Here is my synth definition, has any one any ideas why this can’t be done?
I simplified the example down to the following, which does work! Something must be going on in my synth which prevents resetting the buffer:
(btw. thanks for you hint, I corrected the kr rate)
So, this works:
(
x = {
var pointer;
pointer = Saw.ar((BufDur.kr(\bf.kr(b)).reciprocal)).range(0, 1);
Warp1.ar(
numChannels: 1,
bufnum: \bf.kr(b),
pointer: pointer
)
}.play;
)
I think the problem is with using \bf.kr twice - I don’t think you can do that. Instead, assign it to a variable inside the synthdef (function) and use that variable in multiple places:
var pointer;
var buffer = \bf.kr(b);
pointer = Saw.ar((BufDur.kr(buffer).reciprocal)).range(0, 1);
Warp1.ar(
numChannels: 1,
bufnum: buffer,
pointer: pointer
)
Actually that’s fine – NamedControl collapses multiple uses of the same name down to one control.
I think the key is in the stack trace – a .set call has no reason to go into addKr, except maybe in JITLib, but the example gives no indication of using JITLib. Without evidence of how that specific error is occurring, it’s just speculation.
It’s a very strange stack trace – if x is a Synth, then there’s no reason for the .set call to rebuild the SynthDef. This means there’s something about your scenario that you haven’t told, yet – is x perhaps a NodeProxy?
I note that your first code example a/ doesn’t assign anything to x (so x is unknown to forum readers) – but you’re calling x.set (the call stack confirms this) – I don’t have enough information to make sense of this – and b/ also doesn’t call .play on the function (so, as written, your code example isn’t playing anything that could be set).
I think you’ll need to explain exactly what you’re doing, and not leave steps out. Some of the situation is not visible from here.
Saw is for audio signals. Audio signals should be anti-aliased. Look up “Gibbs effect” to learn more about what that means. (There’s plenty of material online about this; I’m too tired to write my own short treatise about it here, with apologies.)
The pos input to the granulator is not an audio signal. It’s a control signal. You generally want a pure geometric shape for control signals.