seemingly basic but frustratingly challenging max problem!

    Apr 04 2013 | 5:37 pm
    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:
    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 04 2013 | 5:59 pm
      As a workaround - could you load it twice? Once into your buffer, and once into a resizing buffer
    • Apr 04 2013 | 6:09 pm
      Could be something like this?
    • Apr 04 2013 | 6:10 pm
      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 04 2013 | 6:12 pm
      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 04 2013 | 6:23 pm
      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 04 2013 | 6:28 pm
      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 04 2013 | 6:33 pm
      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 04 2013 | 6:59 pm
      you could do it like this:
      or use MXJ buf op which is faster.
    • Apr 04 2013 | 7:09 pm
      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 04 2013 | 7:56 pm
      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 04 2013 | 8:18 pm
      Wieeerd. I'm on OS X 10.8.3, perhaps its that?
    • Apr 04 2013 | 10:23 pm
      @LSka - that works for me too.
    • Apr 06 2013 | 8:04 pm
      Okay, after a fresh install of Max this now works for me as well. Thanks for the ideas and support guys! :)