Buf.op on a long buffer

Did You try doing it without BufOp ?
You can send gain and normalise messages directly to buffer, a least since max 6.

Well, I've just begun experimenting with this, and my final goal is to modify the Buf.Op and add some more sophisticated operations, so using the built-in buffer operations won't be enough... And I do intend to work on large files.

There is a object el.buffet~ by Eric Lyon that does buffer copy, fade in/out, normalise, gain, rotate zero etc
Unofficial version which was uploaded to forums few years ago had overdubb function included.
External is only 32 bit compatible, allows only 2 channels, selection only in ms but
it is really fast when executing buffer edits, and very reliable. BufOp being java is a snail compared to it.

https://github.com/ericlyon

Source code for version 3 /64 bit is available on github, so one can look into code, modify to own needs and compile it.
Cycling folks could have included much more of that stuff into standard buffer object capabilities.
Buffer copy was available in old days of Mac OS 9, bufcpy~by Bill Orcutt worked perfectly.

Ok, thanks for all that info, but I'm trying to build a very specific application which involves scanning a few buffers and manipulating them in several ways. What I need is not a ready external but some info that would help me build my own process.

So - is it impossible to process big buffers in MXJ Java? So far I didn't even succeed in scanning buffers that are longer than 2^24 samples (which is totally strange, as I understood that int numbers should go up to 2^32..) When my counter goes past 2^24 Max either hangs or crashes..

The problem is likely to be that the sound file that you read is larger than the memory that the Java Virtual Machine has. You can increase the size of the JVM by changing the line in max.java.config.txt config file.

from max.jvm.option -Xmx256m to max.jvm.option -Xmx2048m

Thanks Emmanuel Jourdan!!

Changing to 2048 caused a "Can't create JVM" message, but then I tried 1024 and it did the trick! I guess I don't have enough memory for 2048 (I only have 4 GB on my computer).

One last question on this topic: I intend to build an executable application from my patch and send it to my clients - will it work on their computer or will they also need to perform some edits in order to make it run properly?

If you build a standalone using Java classes, you'll need to include a couple of files (Max won't do it for you), one of them is max.java.config.txt. So your clients won't need to edit anything.
You'll find more informations here: https://docs.cycling74.com/max7/tutorials/jitterchapter99_appendixd

Thanks for mentioning el.buffet~. The object is part of LyonPotpourri 3.0, which may be downloaded at: http://disis.music.vt.edu/eric/main/lyonpotpourri/

el.buffet~ is a someone unusual signal object that does not call a perform routine. All its work is done NRT, which in practice is usually much faster than RT. The object should work just as well in 64-bit as 32-bit mode. Its computation is on 32-bit floats, but that is because Max audio buffers are currently 32-bit, not 64-bit. Also, the channel count is not hard-coded, and should scale up to whatever the channel count of the current buffer is. I have only tested up to 8-channel buffers, but there should be no problems for considerably larger buffer channel counts.

-Eric

Unfortunately el.buffet in version 3 is having many problems,
not freeing buffer after operations, so that buffer remains locked - no
read, replace etc. and crashes way to much, in both max 6 & 7 versions.
I still use old one v2 which works perfectly.