Fluid.mlpregressor~ not returning prediction inside collapsed M4L device

Bug Reports and Issues
1

Hello,

I have a Max for Live device that is built around Ted’s “controlling a synth using a neural network tutorial” (https://www.youtube.com/watch?v=XfNZzQPdPG0) with fluid.mlpregressor~. The patch is working as expected when the patch is opened in the Max editor, but when I collapse it down to the Live device chain, it the predictpoint message does not trigger any output. fit appears to work correctly, because the object responds with a fit value and also returns a dictionary when dumped.

Expected Behavior
After training using the fit message, fluid.mlpregressor~ responds to predictpoint messages with 'predictpoint BUFFERNAME`, in both the expanded and collapsed Max for Live Device state

Actual Behavior
fluid.mlpregressor~responds to predictpoint messages in the expanded state, but does not in the collapsed state.

I’m running FluCoMa 1.0.7 inside Max 8.6.2 with Live 12.0.1.

The M4L device I’m using for testing is here: https://drive.google.com/file/d/1AEccb7jpWpfUVHQqS_MfUN010WRL9Eek/view?usp=drive_link.

Max Support Information:

{
	"version" : "Version 8.6.2 (d076223e34e) (arm64 mac)",
	"platform" : "mac",
	"arch" : "arm64",
	"osversion" : "Mac OS X Version 13.5.2 (Build 22G91) arm64",
	"samplerate" : 44100,
	"iovs" : 512,
	"sigvs" : 256,
	"scheduler_in_audio_interrupt" : "on",
	"audio_drivername" : "Core Audio",
	"audio_driver_subname" : "",
	"license" : "permanent full",
	"machine_id" : "33b2d95acdfa379d0292a15379e68b8a",
	"addons" : 	{
		"rnbo_v1" : "full license"
	}
,
	"eventinterval" : 2,
	"schedinterval" : 1.0,
	"overdrive" : "on",
	"pollthrottle" : 40,
	"queuethrottle" : 100,
	"sysqelemthrottle" : 1000,
	"refreshrate" : 30.0,
	"schedslop" : 25.0,
	"eventprobing" : 1,
	"mixerparallel" : "off",
	"mixercrossfade" : 0,
	"mixerlatency" : 30.0,
	"mixerramptime" : 10.0,
	"videoengine" : "avf",
	"gfxengine" : "glcore",
	"packages" : 	{
		"AHarker Externals" : "1.0.0",
		"AudioMix" : "1.0.3",
		"BEAP" : "1.0.4",
		"cv" : "",
		"Dots" : "",
		"ease" : "1.2.3",
		"FluidCorpusManipulation" : "1.0.7",
		"gen-filters" : "1.0.0",
		"gl3" : "0.3.3",
		"go" : "1.0.0",
		"hap" : "1.0.6",
		"jit.mo" : "1.1.6",
		"Jitter Tools" : "1.0.10",
		"JSUI Analog Knob" : "0.0.0",
		"Learn Max" : "0.1.0",
		"link" : "1.5.5",
		"Max for Live" : "1.0.9",
		"max-mxj" : "8.2.0",
		"maxdevtools" : "",
		"maxforlive-elements" : "1.0.10",
		"Meristream" : "",
		"Mira" : "1.2.1",
		"Node for Max" : "2.1.3",
		"pdm" : "0.0.0",
		"philip-meyer-max-tutorials" : "",
		"Rhythm and Time Toolkit" : "1.0.0",
		"RNBO" : "1.2.6",
		"seq-dev" : "",
		"Syphon" : "1.0.9",
		"th.scala" : "",
		"VIDDLL" : "1.2.8",
		"Vizzie" : "2.2.2"
	}

}
2

now, the world leaders of M4L are here: @jamesbradbury and @rodrigo.constanzo

I never use it so I wouldn’t know where to start :smiley:

3

thanks @tremblap! Hey James and Rodrigo -

Hmm so I tested some more and now it is working… I don’t exactly know what changed. I will keep testing and let you know what I find.

One thing that I know that was happening with the object (and also potentially causing Max / Live to crash), was this:

If I send fluid.mlpregressor~ a blank dictionary, it posts the error fluid.mlpregressor~: Invalid JSON format to the Max console (which I would expect), but also sets all of the object parameters to 0 (which isn’t the object’s default state):

Screenshot 2024-04-08 at 12.05.49 PM
Screenshot 2024-04-08 at 12.05.49 PM722×662 28.3 KB
.

I would expect the object to just return the invalid JSON error but leave the params and its existing model in tact.

At one point the m4l device was trying to load the model stored as a dict in a Live parameter to fluid.mlpregressor~, and in cases where the contents of the Live parameter were empty, this invalid JSON issue happened.

1 Like
4

Hey Phillip, can you grant access to the device?

5

I have also experienced funny business with dependencies not being declared (by Max) properly. I think I had to had the fluid.libmanipulation (I think that’s the name, I’m away from my computer at the moment) manually to all my devices that need it.

So worth double-checking that too JIC.

6

now I need to test this as I think I agree with your expectations (if it fails loading, keep the previous state)

let me come back to you later if I confirm and if I can see if easy to fix…

7

Sorry about that, permissions updated!

8

interesting - the object keeps its states inside (you’ll see that if you dump it) but freaks out on the rest… I need to check in the json loading code if it not bailing at the right moment.

9

wow, you caught something big - for those who like C++ jokes about notes to self:

good news, it is an easy fix. we just need to actually do the check :slight_smile:

I’ll push a PR with a fix and it’ll be fixed in the next public release.

10

haha, very nice. thank you pierre.