Error - gen_domain: dsp.gen: [string "gen2.Module"]:151: invalid replacement value (a nil)
Hello,
I have a gen~ patch that contains several copies of a gen abstraction, which is a bank of codebox filters in series, and the abstractions sum together before they are output into the MSP world. I can have three copies of the abstraction in a gen~ patch with no problem, but when I add a fourth I get an error message;
“gen_domain: dsp.gen: [string "gen2.Module"]:151: invalid replacement value (a nil)”. I presume this means I have one of the filters throwing nan. I have a bunch of filters.
If I’m on the right track then the rest of the message should tell me where this is happening. Can anyone help me decode the message? I have been using Gen for a while but this is new to me.
OSX 10.10
Max 7.3.5
Thanks in advance,
Hi I've been getting the same error message and I'm curious if you figured this out. Thanks!
Hi Robert,
Sorry, I am not going to be much help because this was so long ago. If I remember right, I rewrote the patch to solve it. I never did find a reason this was happening.
Interestingly, I believe that this tricky to track down problem was solved in a recent update of Max 9. @Robert Rethwisch, please try the latest Max 9.0.5 and let us know if you are still experiencing this problem. And if so, please provide an example patcher that exhibits the issue.
Hi Joshua!
Just updated. I was doing a whole bunch of trial and error when I popped in here so this was just one of many cryptic error messages I wanted to understand. I am no longer getting this one, however I am still getting the other main error message that was giving me issues "gen_domain: dsp.gen: [string "gen2.Module"]:1347: attempt to index local 'I' (a nil value)"
I have this very useful antialiasing gen patch that I got from the GO book. The problem is that it doesn't like being called up within codebox, which is something I'd like to be able to do. My hunch is that it has something to do with buffer hierarchy / visibility but I haven't devoted enough time to really figure it out. The patch works perfect in regular gen~ though!
Hi,
When I open this patch, the Max console shows the error: "sample: variable sinc is not defined"
Your patch is missing the buffer sinc. You'll need to add buffer sinc to your gen~ patcher (so that the sample knows what sinc refers to) , and in the main Max patcher, buffer~ sinc go.sinc8 , to provide the actual sinc waveform.
Your patch is also missing a wavetable to read from. You'll need to add a buffer wavetable to the gen~ patcher (so that the peek knows what wavetable means) and have a buffer~ wavetable in the Max patch, to provide the actual wavetable information. E.g. buffer~ wavetable wavetable64.wav.
With those additions, there are no errors.
Graham
Hi Graham!
Thanks for getting back to me. I didn't have the buffers in the gen~ patcher since I've only needed to use this patch inside other gen~ patchers & having the buffer operators only in the top level gen~ patch has always worked for me. But yes, the patch now works within codebox without errors after adding the buffer operators to the actual subpatch! I was under the impression that the subpatch should be able to reference the top layer buffer operators in codebox (Buffer wavetable; Buffer sinc;) the same way it can in a regular gen~ patch. So the takeaway here is that buffers need to be defined at every "level" of genexpr code even though they only need to be defined at the top level in regular gen~ patches?
By the way, I hope there is a volume 2 in our near future! The GO book is an amazing resource.
Thanks
Hmm, I think it should work so long as those buffers are defined at the top level gen patcher.
And thanks for the kind words! We are working hard on GO2, there's a ton of material ready and some new things I'm very excited to share, but it always takes longer than expected to shape them into the best final form...
I'll do some tests to see if other patches have this problem too, with this patch at least it seems the buffers need to be specified at both levels. Do you know if there would be any consequences to having the same buffers defined at multiple levels of a gen patch?
Cannot wait, happy to hear it's under way!!