Forums > Max For Live

Problem with embedding files in M4L project…

Mar 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. --


Mar 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…

Mar 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)…

Mar 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

Mar 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