When I make a buffer~ with an initial length of 86,400,000 ms (1 day), there doesn’t seem to be a problem.

This translates to 86,400 x 44,100 = 3,810,240,000 samples x 16 bits = 7,6 GB of memory, right? I’d expect my memory monitor to go off the charts, but that doesn’t seem to be the case..

How does memory allocation work for buffer~? Am I going to experience an unexpected crash as soon as I start writing in the memory over 2 GB (since max doesn’t support 64-bit addresses)?

Mattijs

#P newex 116 136 95 196617 buffer~ 86400000;

This doesn’t crash on my MacPro 2,66 Quad, Max 4.6.3, OS 10.4.8. It also doesn’t change anything to the amount of used memory. What happens to the memory charts in your activity monitor?

>
> > This translates to 86,400 x 44,100 = 3,810,240,000 samples x 16
> > bits = 7,6 GB of memory, right? I’d expect my memory monitor to go
> > off the charts, but that doesn’t seem to be the case..
>
> it’s worse: 86,400 x 44,100 = 3,810,240,000 samples x 32 bits (it’s
> floating point values) = 15,240,960,000 octets. (> 15 GB).

Ah, of course.

So there is a difference in memory management between a MacBookPro and a MacPro?

Mattijs

> #P newex 116 136 95 196617 buffer~ 86400000;

Thanks again for the precision, I tried

#P newex 116 136 95 196617 buffer~ toto 86400000;

And this one crash, on PPC and on Mactel.

Cheers,
ej

Sorry, forgot the name.

>
> Thanks again for the precision, I tried
>
> #P newex 116 136 95 196617 buffer~ toto 86400000;
>
> And this one crash, on PPC and on Mactel.

It crashes here, too. But this one doesn’t:

#P newex 201 262 141 196617 buffer~ allaudio 86400000 2;

Am I going crazy?

Mattijs

Yep. I was particiularly amazed that creating a buffer with a big size doesn’t affect the displayed amount of free memory in my activity monitor.

> I would suggest some other strategy
> involving sfrecord~/sfplay~ instead.

In fact the reason why I stumbled upon this was that I was hoping for a way to resize the buffer~ while keeping its contents intact. This doesn’t seem to be possible at the moment.

But then it suddenly looked like it was possible to create a buffer~ with a very big size without actually reserving the memory, maybe until you actually write something in it (?). So I figured this might be a solution for my problem..

Mattijs

#P newex 35 50 126 196617 buffer~ allaudio 3600000;

does reserve about 600 MB of memory, which is visible in the activity monitor, but

#P newex 35 50 135 196617 buffer~ allaudio 3600000 2;

doesn’t reserve anything, or at least I don’t see anything change in the activity monitor.

Could you confirm that?

Cheers,
Mattijs

To me this looks like missing error checking in buffer~s’ code: if you
ask malloc() (or any other memory allocation function) to alloc more
memory than possible they usually return NULL. Which means no memory was
allocated at all! I think that’s what happening here. So if you start to
write to that memory you will just crash Max sooner or later because you
are overwriting memory that doen’t belong to that buffer~.

Olaf

Ah, I get the error too, missed it, sorry.

But it’s weird that this generates an error while the other one crashes. Or.. could it be that it crashes when it tries to allocate with a memory address bigger than 2 GB but when the address is still within 2GB there is a possibility that it complains about a lack of memory?

Anyway, what is important is that I know for certain that a buffer larger than 2 GB is not supported and there is no intelligent memory allocation system inside buffer~ that would only use memory when it is first written.

So I’ll have to find a way around the fact that buffer~ is not resizeable without losing your content.

Thanks,
Mattijs

not exactly the ability to resize buffer~s, but if you would like an object that can load unlimited audio files, my [prmultibuffload] abstraction might be of interest:

http://www.peterreid.org/code/#multibuffload

Thanks Peter.

I get

The requested URL /code/prmultibuffload200705.zip was not found on this server.

Mattijs

Thank you Mattijs, I fixed the link, please try again!

http://www.peterreid.org/code/#multibuffload

Peter

Hey, that’s a cool abstraction! This is indeed a way to dynamically allocate memory for additional sound data.

Now I am thinking of a way to have all the buffers together act as a single one. ;)

Thanks,
Mattijs

Cheers,
Mattijs

I always thought it was bad magic to add dots in filenames (though not as bad as spaces and odd characters). But if everyone does it, I may start following that convention.

Glad the object could come in handy for someone.

Peter

Better the other way round, take a single buffer~ and let
groove~/play~/wave~ act as if it were multiple ones (with an offest to
the start point…)

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

Stefan, the problem is I can’t resize a single buffer~ without losing its contents (see earlier messages in this thread).

Mattijs

>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-