just loaded up your patch, seems to work fine for me. I always use the replace message for buffer loading as it re-sizes the buffer to match the loaded file, read won't do this. apologies if you've already tried this/know this.. Tim

Your patch is basically the waveform help file. If this patch would not be running correctly, I doubt the developers at c74 would have provided as a help file in the first place. Most likely there's something else going on (then that the patch aint workin'). What that is, is easier to pinpoint when you provide some more info. What platform/system are you running, what version of max, which type of soundfile it is you try to load, how many channels, what duration... Try also simplifying the patch and, reading the documentation is a must.

_ johan

I used the help patch as an example. It's as stripped down as it needs to be. I just loaded the waveform help in 4.6 and it works fine, i.e., as it should. This problem is occurring on my Windows XP SP2a and Max OS X 10.5 Intel machine with Max 5.02. I have tried it with the waveform help and my other patches that use the waveform object. I'm really baffled why it works for you two and in 4.6 but not for me in 5. And yes, I am using replace and not read.

It's occurring with a variety of samples at different bit rates and sample rates. The only sample that works (of the few I have to test with, here) is a 16 bit / 44.1 kHz one. However, like I said, all of the samples work in 4.6.

Try this... It's 16 bit / 16 kHz.

I tried your file on the Mac and waveform~ in Max 5 displays 826.75 ms of it, same as 4.6. Do you think you can attach a screen capture of what you are seeing on Windows?

David Z.

Thanks. Here's a screen cap.

Thanks for the screen shot. As far as I can tell, this is a problem with the waveform~ object in the help file. If you delete that object and create an entirely new one, it doesn't seem to have this problem. I'll try to figure out why and fix it soon.

David Z.

Actually, a better way of expressing the problem is that waveform~ is not updating properly when the buffer~ sample rate changes. Until this is fixed, a workaround would be to send the waveform a name message with some other buffer and then send it another name message to point to the buffer whose sample rate has changed. In 5.0.3, the waveform~ auto-update mechanism will notice sample rate changes.

David Z.

Thank you for confirming. I went ahead and paste-replaced the waveform object in the patch I'm developing and it now displays the correct buffer length in this case.

Bizarre. It seems I have to create a new waveform object every time I open the patch. I'll try the workaround, then.