MuShoo

So I've been converting my patch to use a poly~ object to do most of it's processing. The patch loaded into poly~ has a bunch of wave~ objects referencing a buffer that is set from outside the poly object. However, after switching to poly~, if I have too many instances of it actually processing (more than 8 or so), and I try to replace the file loaded into the wave~ buffer, I get a message saying: "buffer~: can't load now."

Is this due to too much audiorate processing going on? Trying to load the buffer across multiple threads?

If there's no simple way around this, I suppose I'm going to have to load all my possible sounds into buffers at load, and then tell the wave~ object to switch which buffer it references. I don't like this idea much.

The wave~ buffer loads in grain windows, referenced from a folder. Currently it's very easy for me to add new windows, just drop a new aif file in the folder and presto, it's there. I suppose I could try and figure out a way to javascript the buffer creation/naming based on the filenames? Any thoughts on how best to do that?

So I've been converting my patch to use a poly~ object to do most of it's processing.  The patch loaded into poly~ has a bunch of wave~ objects referencing a buffer that is set from outside the poly object.  However, after switching to poly~, if I have too many instances of it actually processing (more than 8 or so), and I try to replace the file loaded into the wave~ buffer, I get a message saying: "buffer~: can't load now."

Is this due to too much audiorate processing going on?  Trying to load the buffer across multiple threads?

If there's no simple way around this, I suppose I'm going to have to load all my possible sounds into buffers at load, and then tell the wave~ object to switch which buffer it references.  I don't like this idea much.

The wave~ buffer loads in grain windows, referenced from a folder.  Currently it's very easy for me to add new windows, just drop a new aif file in the folder and presto, it's there. I suppose I could try and figure out a way to javascript the buffer creation/naming based on the filenames?  Any thoughts on how best to do that?

buffer-erroroddity

> If there's no simple way around this, I suppose I'm going to 

> have to load all my possible sounds into buffers at load,

You could alternatively load buffers that weren't in use... For ex., you have buf1 and buf2, and buf1 is currently playing.

You could "cue up" buf2 during buf1's hay-day in use and then switch the ref with the set message afterwards (you could automate it with the bang and onebang objs).

> If there's no simple way around this, I suppose I'm going to 
> have to load all my possible sounds into buffers at load, 

This is a pretty standard way to do it.
You could alternatively load buffers that weren't in use...  For ex., you have buf1 and buf2, and buf1 is currently playing.

Quote: MuShoo wrote on Sun, 26 October 2008 21:42

----------------------------------------------------

> So I've been converting my patch to use a poly~ object to do most of it's processing. The patch loaded into poly~ has a bunch of wave~ objects referencing a buffer that is set from outside the poly object. However, after switching to poly~, if I have too many instances of it actually processing (more than 8 or so), and I try to replace the file loaded into the wave~ buffer, I get a message saying: "buffer~: can't load now."

Just for your information, I have used this same approach in the past (wave for grain window in poly, buffer in main patch) and have never had any problems loading a new file into the buffer.

I did a quick test (wave in patch > patch in 32 voice poly >poly in main patch where buffer also is), and max gave me no error on reading a new file into the buffer.

I haven't tried it under load, but it should not make much difference, right? Also, this approach has always worked for me in the past.

If you keep having problems, I suggest that for now you preload your different window shapes (they are small so memory won't be an issue) and reference to the different buffers with the set message to wave~.

Quote: MuShoo wrote on Sun, 26 October 2008 21:42
----------------------------------------------------
> So I've been converting my patch to use a poly~ object to do most of it's processing.  The patch loaded into poly~ has a bunch of wave~ objects referencing a buffer that is set from outside the poly object.  However, after switching to poly~, if I have too many instances of it actually processing (more than 8 or so), and I try to replace the file loaded into the wave~ buffer, I get a message saying: "buffer~: can't load now."

Hello,
Just for your information, I have used this same approach in the past (wave for grain window in poly, buffer in main patch) and have never had any problems loading a new file into the buffer.

Well, I just discovered something else fun with this. While preloading the window buffers would be fine, it seems I also can't load in a main sample either. I get the same 'Can't read file now' error. I can't preload files for this, because I don't know what files I'm going to want to play around with, and the idea was to keep it simple to load new files in.

At first I thought maybe it was the poly~ referencing a buffer~ created from outside the poly~ object, but a simple test patch I made proves this to be wrong. I honestly have no clue what's going on with this, and the error message itself is very uninformative.

Well, I just discovered something else fun with this.  While preloading the window buffers would be fine, it seems I also can't load in a main sample either.  I get the same 'Can't read file now' error.  I can't preload files for this, because I don't know what files I'm going to want to play around with, and the idea was to keep it simple to load new files in.

At first I thought maybe it was the poly~ referencing a buffer~ created from outside the poly~ object, but a simple test patch I made proves this to be wrong.  I honestly have no clue what's going on with this, and the error message itself is very uninformative.

Buffer~ error/oddity.