seemingly basic but frustratingly challenging max problem!

Apr 4, 2013 at 5:37pm

seemingly basic but frustratingly challenging max problem!

Hi everyone, I’ve been having problems over the past couple of days with something that on the face of it seems really, really simple but is actually proving to be a real pain in the derrière, and it’s really starting to play havoc with my patch (a patch that has taken 6 months to build!).

Basically – I need to import an audio file into a buffer without resizing the buffer. The buffer needs to stay 60000ms long, but I also need to report the length of the audio file I just imported into the buffer, and I can’t guarentee that the audio file will have originated within the max search path (which I guess rules out sfinfo~!). “Use the read command” I hear you shout! Unfortunately there also appears to be a bug on macintosh that prevents you from using [dropfile] and the read command, and the read command on its own doesn’t report the file path so I can’t get the file length – these problems are all detailed within this example patch:

– Pasted Max Patch, click to expand. –

Your challenge then, should you choose to accept it (and please do cause this is driving me absolutely mental!):

Load a sound file into [buffer~] using either the read command or [dropfile], maintain a [buffer~] that is 60000ms long regardless of what length sample you put into it, and report the length of the audio file you just loaded in (an audio file that could come from anywhere on the computer, not just the max search path). This needs to happen with one load action i.e dropping a file onto [dropfile] once or clicking a single button.

The patch I’ve included should demonstrate the issue I’m having, please help! :)

Apr 4, 2013 at 5:59pm

As a workaround – could you load it twice? Once into your buffer, and once into a resizing buffer


Apr 4, 2013 at 6:09pm

Could be something like this?

– Pasted Max Patch, click to expand. –
Apr 4, 2013 at 6:10pm

Hi Andrew, yeah, I’m doing that in the example patch above, but the patch I’m building is destined to be an app, I can’t expect the users of this app to have to do that.

Apr 4, 2013 at 6:12pm

Hi LSka, I’m guessing your on a PC? Unfortunately owing to the apparent bug I mention on Crapintosh (see my post here this doesn’t work, dropping the audio file in resizes both of these buffers. :(

Apr 4, 2013 at 6:23pm

Sorry for the hacks – but you get a bang once you’re done reading into the first buffer yeah?

ok – I can get the size alright – so the bug seems to be that the read dialog works differently from read

read is working the same as replace. We’ll get it ticketed


Apr 4, 2013 at 6:28pm

Hi Andrew, I really don’t mind hacks as long as I can hide them from the end user! The trouble is I have no way of getting the file path of the file I just loaded into the first buffer with the read command. If I could get that file path I could indeed bang it with the bang once I’m done reading into the first buffer. Any idea how I might get this? As we’ve established, I can’t use read

Apr 4, 2013 at 6:33pm

yeah this sucks – I’ve ticketed it. I can’t really think of anything that doesn’t involve some kind of nasty copying samples over type action.


Apr 4, 2013 at 6:59pm

you could do it like this:

– Pasted Max Patch, click to expand. –

or use MXJ buf op which is faster.

Apr 4, 2013 at 7:09pm

John you are an absolute star! I was starting to think that I’d have to go down the peek~ route, also I’ve needed to avoid java to get the app into the apple app store so this works really well! Thanks everyone! :)

Apr 4, 2013 at 7:56pm

I’m on Mac, not on Windows (Max 6.1.1 OS X 10.6.8) and with the patch i posted buffer two doesn’t change length.

Apr 4, 2013 at 8:18pm

Wieeerd. I’m on OS X 10.8.3, perhaps its that?

Apr 4, 2013 at 10:23pm

@LSka – that works for me too.


Apr 6, 2013 at 8:04pm

Okay, after a fresh install of Max this now works for me as well. Thanks for the ideas and support guys! :)


You must be logged in to reply to this topic.