Importing files into a buffer - only the left channel loads!
Hi all!
I'm having a bit of trouble with a patch and would appreciate any help! I've searched the forum but can't find an answer, though I'm sure it's something small and stupid I'm doing wrong. as is always the way.
So I'm trying to load stereo files into a buffer~. I can do this with a "read" message and get the buffer to load both the left and the right channels of the audio file correctly. I can then use a play~ object to play the file back in stereo, exactly as they should sound. This is what I want, but this only works for a limited range of file types (wav, aiff, etc).
What I want is to use the import message instead, which allows many more files types to be loaded, including mp3. Problem is, all I seem to be able to do is import the left channel of the audio file into the two channels of the buffer~. So two channels load up when using the "import" message, but they're both identical; they're both the file's left channel, and the right channel is always missing. I read the help file for buffer~ but can't seem to make sense of it. If there was an example of how I should format my import message going into the buffer~, I might be able to fix the problem.
Any ideas?
I think it might help if you were to provide a sample patch that demonstrates the problem, and to tell us what platform, Max version, and OS version you're running.
Of course! I'm using the latest version of OSX (10.8.2) with up to date MaxMSP (6.0.8).
The patch is just something simple:
Was wondering if I'm getting my import messages wrong; maybe it should be more like "import test.wav 0 0 2". I've read the help file to know that the number of channels is the third value to specify, and I have to also specify start point and duration. I ended up getting confused when testing it out and was not sure if I was doing something wrong or it was a glitch.
That's a bug (which could be in the max object or in Quicktime), I tested it and you are right. It only imports channel 1, what's worse the copy that ends up in channel two is 1 sample earlier than channel 1. This is true for importing .mp3 and .aif I didn't try .wav
the numbers after the import message stand for the start point / end point / channels if you want to import the whole file use -1. for the second argument.
I'd stick to .wav and .aif for now as they work fine. And you might as well use replace or read instead of import.
That's quite an annoying bug... A bit of a pain but oh well, I'll just use a "read" message instead, not a massive deal. Thanks for taking the time to look at it and clearing that up!