Forums > Max For Live

Problem with embedding files in M4L project…

March 14, 2014 | 6:45 am

Hi to all masters of Max :)

I have a M4L plugin where I can drop audio files to a buffer~, but in case the plugin is freshly dropped to the project, i want to initialize the buffer with a wav file embedded in the project… All this works fine, but it seems the M4L device needs some time to initialize the embedded files, as if I delete the "delay" object from attached patch, then i’ll get a "1.wav: can’t open" max error…

I guess it’s some kind of ordering or timing problem, but i feel "delay 200" is not a nice solution (althought it works) and leaves some uncertainty if it will work on every other computer…

Attached this small extract from the device, how I’ve tried to solve it…

Any idea for a better solution would be much appreciated!


— Pasted Max Patch, click to expand. —


March 14, 2014 | 9:55 am

what is triggering the initial load of the wave? doesn’t seem to be shown in this bit of the patch…

March 14, 2014 | 3:24 pm

sorry, maybe it’s not clear then… if you drop the M4L device to a track in ableton, or load up a project where the device was included, then the "live.drop" objects outputs "none" (init state) or the filename (if it’s already part of a project and something was dropped onto the object)…

So in this little patch "route" will decide if it’s still empty (the left outlet of the route object) or a file was dropped (right outlet)…

March 15, 2014 | 9:36 am

Hi .
im not sure what the issue might be just yet in this particular scenario , but ive got some experiences with M4L initialization where i had to use [live.thisdevice] for FINAL bang to initialize buffers and others , including Dict with pattr issue .
EDIT : as [live.thisdevice] will bang while everything is set up , a little bit differently from loadbang

March 18, 2014 | 6:37 am

not had chance to look again, but what dw says is correct – is this factored into your patch?

Viewing 5 posts - 1 through 5 (of 5 total)

Forums > Max For Live