My M4L device works in Max preview but *not* in Live

[jaschanarveson]

M4L device with:

- a buffer~ object
- indexed playback of the buffer~ object
- a js object with a script that sends indexing info to the play~ object
- some buttons to trigger playback, recording, etc...

This seems like pretty standard stuff. Without posting the device itself, is this something that is generally known about and fixable? When I preview the device in Max it works great, but when I close the window and go back to Live I don't get the triggered playback.

I *can* attach a button to simply play the buffer~ object back in Live, but my js script that's sending index info isn't working.

Odd...

Running Live 9.2.2 | Max 7.0.6 | OSX 10.10.5

[[jur]]

This is probably due to your js object. Maybe M4L lose track of it because your object is saved in an appropriate place.
Try to freeze the device once before saving it and using it has an M4L device.

[jaschanarveson]

Hi,

Thanks for the suggestion, but it hasn't worked in my case.

I should've been more detailed in my first post: I can get *some* behavior out of my js object, just not all:

- I *can* set up a button to trigger output from my [js] object of how many index points are stored in an internal array - this works in Live just fine
- I *can't* get my index points being output from the same [js] object to trigger the [buffer~] object while in Live
- I *can* get the [js] object's index points to trigger sample playback in preview mode when I open it up for editing.

Very weird - I'd expect all or nothing from the [js] output - as it is, the single-value for the array size outputs to a live.numberbox great, but the formatted [start time, end time] list isn't working except in Preview.

Any further thoughts? I tried freezing, but that didn't do it.

thanks,

j

[jaschanarveson]

Ah-ha! I found out what was wrong:

I was using the [adstatus] object to get the sampling rate and feed it to my [js] object, so that it could convert from raw samples to milliseconds.

The [adstatus] object doesn't work when it's inside a M4L device, it seems, so my [start time, end time] indeces were all off by a factor of 44.1, which meant they were trying to index way beyond where any sound was in the buffer.

Phew!

thanks again for the suggestion,

j