Closed timmb closed 1 year ago
This was resolved by adding the torch dll files to the system path.
Hi, I'm also experiencing this behavior, I'm currently in touch with the M4L team to figure out what happens !
Hi, I'm also experiencing this behavior, I'm currently in touch with the M4L team to figure out what happens !
just fyi - if you use a M4L device with nn~ inside it, you will need to place the .dlls into the folder of the max version bundled with ableton . you can also put the dlls next to ableton exe but thats not useful if you want to edit the .amxd M4L device that uses nn~ since ableton live will open max separately. also watch out for audio buffers - it seems when you open an m4l device within the bundled version of max there is some extra buffer added automatically as virtual audio paths are created, and once you close the max editor, your m4l device will use the assigned buffer of your audio card and not anything youve set inside nn~ so better use a buffer of 2048 on your audio card!
This is true for windows only, as the buffering mechanism is disabled (see here) as a result of a libtorch bug.
This mechanism is not what the external setting "forward (buffer size)" is related to correct? I hear a difference when leaving out those arguements or including them.
When I try to load
nn~
or related externals in Max for Live, it fails to load and prints to the Max console:However, the external works if I load it directly in Max.
Any idea what could be causing this?