I’d be placing there all over the instrument to see what’s going on. If you have silence for the first sequence it might indicate that the sequencer is not actually running, a print statement in that code would confirm or illiminate this as a problem. By process of deducation you should be able to find the problem.
Returning to CsoundUnity and updating old project
okay - a bit of an update. there were already two commented out print statements that you had put in - one of them by the instrument selection block with all of the kInst elseif statements, and the other one in the block with the if changed(kChanged) statement.
so running this on a single Layer, it appears the second one spits out relatively accurate data during the silent run, but the initial one here does not:
printks "amps %d, %d, %d, %d, %d, %d, %d, %d", 0, kNotesAmps[0],kNotesAmps[1],kNotesAmps[2],kNotesAmps[3],kNotesAmps[4],kNotesAmps[5],kNotesAmps[6],kNotesAmps[7]
so on an initial first run of the sequence it appears that this print statement does NOT print until the next repeat of the sequence. here’s a guess. is it possible that kNotesAmps SHOULD be filled with something other than 0? i just checked the older script version with 8 rows of 8 notes and it looks like it fills the same array with 0s as well.
gonna try with 100s and just see…
Okay that’s definitely NOT the solution - it just played every note constantly.
so i’m still a bit mystified as to what’s going on. when testing, i usually don’t put notes in directly but instead i randomize the notes. the randomization process is a bit weird - i was unable to simply generate an array of notes at the fastest speed so i gave it a brief waiting time in coroutine.
all of that isn’t as important, but what might be is that i had to disable immediate playback during that randomization process which might mean that the amp array for each step goes unfilled in Csound until after it reads that data from the array step by step in Unity. the only thing i find a bit weird is that i think it should be printing 0s even if nothing is there and that doesn’t happen.
ah, i think that’s it, actually. because Csound is moving the playbar in Unity my guess is that the amp value arrives just AFTER that position is encountered in the loop. so it reads it as 0 or null on the first pass but by then the entire array is filled properly by the second pass.
oh and i think the print statement is not up to date as it only prints 8 values and not 16. not a big deal really.
will work a bit more on this. i think maybe what is needed is a way of updating the amp array outside of the main sequencer loop, and probably independent of tempo before playback starts. maybe we can do it in the block i created for tempo == 0?
okay i did try a bit of messing around making the random scan send an intensity value to the array. what that did on playback was have it make a huge cluster of notes immediately then go silent for the rest of the sequence and pick up on the second run through. so i’m not sure that i can solve this in Unity. will keep plugging away…
Sorry, I was in meetings all day long 
So on the initial run the print statement isn’t triggered. But what part of the sequence of if statements are? I’d add a print statement after each if statement to see where the control flows break with expectations.
meetings all day - UGH. sorry about that…not fun and draining usually.
all those if statements are pertaining to the instrument selected (there’s 8 defined). they do exactly the same thing but each output is assigned to a different instrument. i don’t think there’s any sense in putting print statements there especially since at the end of those elseifs is the statement that doesn’t print on the first run. that would suggest a problem further outside of the branching section. i probably unneccessarily bruteforced it by being explicit, and there might be a more compact route in Csound towards branching but i do think that Csound can’t use switch statements.
anyway in the section below that a bit further down appears a ksprint statement that DOES print on first run. so it seems to me the problem lies between them. i’ll put ksprints in those areas.