gen failed to compile - someone able to give me some fresh eyes?
There isn't a parameter definition for "playrate.". If you want to send a parameter to gen~ via messages, it's gotta be defined.
That's what the error message in the Max windows says.
was taking a look at this too, and aside from the playrate message problem Max mentioned above, while i didn't have time to find the exact prob, i notice that if i delete your "gen life_algorithm" subpatcher, within your main gen patcher for the pfft~(and connect up params and open inputs to any random thing left over... also creating a param called 'playrate' just to get rid of that error), i won't get any error message(the 'failed to compile' error won't happen either), so whatever's wrong can at least be localized to the playrate param missing and something within the "gen life_algorithm" subpatcher...
(although, i also notice you have two buffer ops of the same name in the outer/main gen patcher when you only need one(this is not including the third nested within the inner 'gen life_algorithm' subpatcher))
my first guess, though(sorry i don't have further time to test), is that you are defining a buffer within the function "LiveOrDead".... until that function is actually called, the buffer is undefined for your codebox while everything else gets defined where things usually do(i'm not even sure you can define buffers in functions to start with like that)... i could be wrong, because i can't test this out more thoroughly, but i might start looking at how you access buffer in your codebox there.
[Edits:
-also, there's no need for semicolon after the function declaration of "LiveOrDead"
-your function "LiveOrDead" should return something, as it is it doesn't change outer variables, just changes inner ones(arguments to functions are like inner variables referring to outer ones, but not the same... to help keep track, it's often better to name the arguments in your function declaration differently than the actual arguments you'll eventually pass in) and doesn't communicate anything back to the outside....
-your 'peek' op within the function references a 4-channel buffer but the 'if' statement can only use one of those channels(what's the expected input/output there?)...
-once you get this to compile without error, i'm not sure the code will do the proper game-of-life situation: maybe the 'position' and 'L/R_lifecount' variables need to be written to a history? (otherwise they always default back to what they are defined as at the start of the code?)]
anyways, hope it helps 🍻
Wow, thank you so much! This was my first time using the forum after it was enthusiastically suggested to me and I have to say I really wasn't expecting such a fast or thorough response! I'll go though and digest all this, many thanks again!
Ok, so I've taken out the playrate parameter and rewritten the code within the function meaning that no external variables are being changed. I've also fixed the issue on which channels I was referring to but I'm struggling to know where to place the 'Buffer spectralBuffer' so that it can be referenced in both the function and the main code.
In response to your last point, yes, you're right the game-of-life varient should work afresh for each sample so at this point I'm really just expecting noise to come out of this until I introduce more parameters at a later stage.
Perhaps due to the buffer issue, I'm getting:
'clang: use of undeclared identifier 'in4'; did you mean 'int'?'
Any ideas?
pass in the buffer and input4 as arguments... i think gen~ likes function-declarations to behave as templates, where you don't instantiate anything within them beyond local variables that don't already exist outside the function(this includes inputs like 'in4' and buffer/data-ops, etc...)....
i didn't even realize we could return multiple things(haha, i know that's how it works in other languages but assumed for some reason gen~ might be finnicky), your code does the right thing with the return 👍... something like this might work, notice the buffer and input4 are now the last 2 args in the function-declaration:
LiveOrDead(position, L_lifecount, R_lifecount, specbuf, io4) {
L_add = 0;
R_add = 0;
if (cartopol((peek(specbuf, position, 0, channels = 1) / 1024), (peek(specbuf, position, 0, channels = 2) / 1024)) >= io4) {
L_add = 1;
} else {
L_add = 0;
};
if (cartopol((peek(specbuf, position, 0, channels = 3) / 1024), (peek(specbuf, position, 0, channels = 4) / 1024)) >= io4) {
R_add = 1;
} else {
R_add = 0;
};
return (L_lifecount + L_add), (R_lifecount + R_add);
}
Buffer spectralbuffer("spectralbuffer");
L_lifecount = 0;
R_lifecount = 0;
one more thing, you're writing 'peek' with 'channels' as though they're channel-offsets(it's confusing compared with 'poke', they have similarly named arguments), but the 'channels' argument to peek is actually defining how many channels to output... instead i think you want to just offset using the third argument... for example, to address channels in succession with multiple peeks, would be like this:
peek(specbuf, position, 0)
peek(specbuf, position, 1)
peek(specbuf, position, 2)<-channel offset is the third argument to peek
[Edit: i wrote something extra about your 'if' statements, but now i see they're probably correct(they're not attempting multiple evaluations within one which is what i thought at first)... just watch out for the channel-offset issue i mentioned above in regards to peek and it should be all good]
one last thing... on second thought(still got a funny feeling about the 'if' statements in the function-declaration)... if you connect up a 'cartopol' and click the 'C' icon in the right-toolbar to see the code generated, you'll notice it returns two values which need to be assigned to something in order to return properly within any other context(including 'if' statements)... so you might have to create separate ifs for each cartopol output.
