importing samples smaller than a buffer without resizing it

Apr 3, 2013 at 11:56am

importing samples smaller than a buffer without resizing it

Hello all, I am trying to import a sample that is smaller than the buffer it is being imported into, but when I import it, [buffer~] shrinks to accomodate it. I have been using [read sample.aiff 0 1000] to try and restrict the buffer size to 1000ms in all instances, this works fine for longer samples i.e any thing above 1000ms, but if I want to import a very short sample, one below 1000ms, [buffer~] shrinks. Any ideas?

#67501
Apr 3, 2013 at 2:05pm

Hi
afaik, the read message should do this as you describe, according to the helpfile. It must be your additional arguments specifying start and end. I’m guessing you’re importing a section of a larger file? Can you ‘pre-crop’ and then use a less specific read message?

#242871
Apr 3, 2013 at 2:26pm

Thanks for the reply n00b, right I have refined the problem a little more, if I read a file using a read message directly into the [buffer~] (which opens the file browser) this works perfectly, when I use [dropfile] with [prepend read] this doesn’t work as described above. Here is a reduced patch:

– Pasted Max Patch, click to expand. –
#242872
Apr 3, 2013 at 2:57pm

Yeah, same behaviour here. Nothing specific about dropfile in the [buffer~] reference for “read” either. And I tried a [read $1] message from [dropfile]; it behaves in the same way. I wonder does the header data specify file length, which is then passed to [prepend read] and [buffer~], where the “open browser via read” doesn’t?? Do I need to read the documentation more thoroughly?

Brendan

#242873
Apr 3, 2013 at 3:12pm

Thanks again for your feedback, I’ve been through a fair amount of documentation, can’t find anything yet, could this be a bug?

#242874
Apr 3, 2013 at 3:32pm

Hi Barry,

I re-read your OP; if you use dropfile plus the following message:

read $1 0 1000

If the dropped file is < 1000 (or whatever size presented as the above 3rd argument) the buffer will NOT crop to the file length!

Is this what you need?

– Pasted Max Patch, click to expand. –

Brendan

#242875
Apr 3, 2013 at 3:35pm

I think my method is a cheat – “read” does not resize the buffer (as we know); what happens is the buffer is “resized” by the first “read $1 blah blah” message, to it’s original size….

This did crash on me once a few moments ago, but I think it was just impatient clicking.

Brendan

#242876
Apr 3, 2013 at 3:38pm

Hi Brendan, for some reason this isn’t working for me, it’s defaulting to the same behaviour as before. :(

#242877
Apr 3, 2013 at 3:40pm

Are you on a PC or a Mac? I’m on a Mac, just thought that might be the issue here…

#242878
Apr 3, 2013 at 3:45pm

Really?

1. buffer is sized via loadbang;
2. browse to audio files via “read” and import something (< bufsize ms);
3. drop audio file via dropbox –> “read $1 0 bufsize*ms” message;
4. no cropping should ensue.

New version:

– Pasted Max Patch, click to expand. –

Brendan

#242879
Apr 3, 2013 at 3:47pm

Windoze, but testing with the bundled aiff filetype

#242880
Apr 3, 2013 at 3:52pm

Yeah, this still crops at my end so perhaps Crapintosh is the issue after all. Thanks for testing this at your end Brendan!

#242881
Apr 3, 2013 at 3:56pm

Windoze?

Crapintosh?

Linux ! ! !

Shame I couldn’t help, kind of. Must be doubly frustrating knowing I’m sitting here looking at a solution :)

Brendan

#242882
Apr 3, 2013 at 3:57pm

Well when you put it like that! ;)

#242883
Apr 3, 2013 at 4:03pm

One last question:

Are the audio files stored in a location known to Max?, ie have you tried this both with the files in /examples/sounds, and your own soundfiles? Might be trivial, but this dictates whether a browser opens or not – might have some bearing.

Hate leaving unsolved!

Brendan

#242884
Apr 3, 2013 at 4:07pm

No there not, and they can;t be really as I’m intending people to drag and drop files off of their desktops (or what ever file they wish).

#242885
May 2, 2013 at 3:26pm

hello Barry Farrimond…hello n00b_meister…
i believe that this is a bug of max6(i am not sure from which version)…
the same patch is giving different results in max5 vs max 6..
max5 read message does not resize the buffer(as it should) when version 6 resize the buffer…
(also in max4.5 does not resize the buffer!)

– Pasted Max Patch, click to expand. –
#242886
May 2, 2013 at 5:48pm

Hi all,

We are currently looking at some regression issues with buffer~, this being one of them. There are a number of differences that have cropped up in Max 6, and although I can’t say when or if we will have fixes for them, we are going to be taking a closer look in the near future.

Thanks,
-Ben

#242887
May 2, 2013 at 6:32pm

The patch posted by N00b_meister seems to work for me (Max 6.1.2 on Mac OSX 10.6.8)

#242888

You must be logged in to reply to this topic.