Array output in script: why incorrect length?

Hello people,

I am writing a script that should output a multidimensional array as channels, but for some reason the multidimensional array is not complete in he output.

So far, I have a script chop, containig these lines of code, derived from the example that can be found here on the derivative site

def onCook(scriptOp):
	# scriptOp.clear()
	
	npArray = np.zeros((32, 16), dtype=np.float32)
		
	for x in range(32):
		npArray[31 - x][2] = 255
        
	npArray[int(op('math8')['chan1'])][12] = 255
	
	# copy the NumPy array into CHOP channels
	scriptOp.copyNumpyArray(npArray)
	return  

But, the channel output of this script is 32 channels, with 8 values. I was expecting 32 channels with 16 channels.

It seems as if somehow the amount of bytes used for the individual variables in the array is incorrect. If I change the declararion into:

npArray = np.zeros((32, 32), dtype=np.float32)

I do get 32 channels with 16 values. What am I overlooking here?

Hi @pyromancer,

what version are you using and could you post a minimal working example that shows this behavior? I can’t replicate here in 2025.32050 and with your sample script get 32 channels with 16 samples.

cheers
Markus

Hi @snaut,

Thank you for addressing this so quick!

I am using version 2023.12370. And the issue is getting a bit weird. I cut the relevant operators into a new file and when I opened that one directly by double clicking the file, it all did work normally, so with 16 samples in each channel. When I create a new project and use the tox in there, it also works as intendend.

working.tox (1.4 KB)

However, in the original file audiopatterns.6.toe it doesn’t work. I uploaded this one as well, for reference. You will see the script in here twice. The second one I copied, to collapse it and create working.tox.

Maybe I stumbled onto a strange bug?

audiopatterns.6.toe (7.9 KB)

Hi @pyromancer,

in the file audiopatterns.6.toe it also creates the samples correctly for me. One confusion might be that the Script CHOP is running at 60fps while your timeline is set to 25 fps. This results in 16 samples created on 6.67 frames. So all the data is there also as confirmed by the Shuffle CHOP which holds 512 samples… From a data standpoint this is then mostly a display issue as the bottom scale n the CHOP viewers is frames and with the main timeline being 25 fps and the CHOP processing at 60 fps, you see the scale range of 1 - 7.25 frames. Middle mouse click onto the CHOP and it will show the number of samples created.

To make sure the Script CHOP is running at the appropriate rate, please add a scriptOp.rate = me.time.rate call after the scriptOp.copyNumpyArray(npArray) line.

I’ll inquire though why the default behavior for the .copyNumpyArray() is not to set the operators rate to the component rate.

The changed timeline framerate also explains why you see the different display in the .toe file vs the .tox file.

cheers
Markus

Bravo! Changing the framerate on the timeline indeed solves the problem. Thank you for finding this so quick.

I did indeed change the timeline from 60fps to 25fps.

Some thoughts: one would assume that the script framerate would change together the timeline framerate. Although this could of course be intended behaviour. I can imagnine that makining scripts run faster than the timeline could make sense in complicated designs. But still I’d say when unspecified, the script framerate should change together with the timeline framerate.

Thanks,

David

Hi @pyromancer,

I should have said that the Script CHOP has it’s rate set to 60 samples per second to differentiate it a bit more from the general notion of frames per second and thinking of speed…

For example a audio file has often a sample rate of 44100 samples per second which doesn’t mean that the CHOP is running at a different speed, it is just processing more samples per frame.

But I think that the .copyNumPyArray() method should set the CHOPs sample rate to the timeline’s rate unless specifically specified.

cheers
Markus

Thank you for claryfying!

Problem solved.