astevens

I now have a polybuffer~ being used to fill 10 buffers.

The drag and drop into the poly buffer works fine yet it doesn't seem to replace the whole folder just the first track.

So I end up with folder A track 1, then 2 to 10 folder B and vice versa if I do it the other way around.

Big thanks to Matt for pointing to the polybuffer~ in the first instance.

I now have a polybuffer~ being used to fill 10 buffers. 

Big thanks to Matt for pointing to the polybuffer~ in the first instance.


polybuffer-3

[dropfile]-->[prepend readfolder]--->[polybuffer~ mySounds].

Trying to fathom out why the first track sticks when a new folder is dropped!

This seems to work. The reason you need "send 0 clear" is if you have other buffer~ objects hanging around your patch, the memory will hang around. Think about it this way: If you've got two buffer~ objects referring to the same sound and you delete one, the memory stays intact. So when polybuffer deletes all it's internal buffers to make room for your new buffer objects, another buffer in your patch would cause it to stick around.

So if you've got a [buffer~ mySounds.5] hanging out, in our example, "send 0 clear" will simply make that buffer zero samples long. It won't erase max's record of it being there but it also won't take up any memory. AND since your coll file lists all the buffers in play (and not the empty one's you're not using), your program will know exactly which buffers to pay attention to.

This seems to work.  The reason you need "send 0 clear" is if you have other buffer~ objects hanging around your patch, the memory will hang around.  Think about it this way:  If you've got two buffer~ objects referring to the same sound and you delete one, the memory stays intact.  So when polybuffer deletes all it's internal buffers to make room for your new buffer objects, another buffer in your patch would cause it to stick around.  

So if you've got a [buffer~ mySounds.5] hanging out, in our example, "send 0 clear" will simply make that buffer zero samples long.  It won't erase max's record of it being there but it also won't take up any memory.  AND since your coll file lists all the buffers in play (and not the empty one's you're not using), your program will know exactly which buffers to pay attention to.


Also, here's a simpler way to replace sounds using messages to polybuffer instead of using an extra buffer~ object.

Even when I use your examples, one track will always hang around even after I have cleared the buffer!

I think it's time that you post a clear example of your patch. If you're having a problem, you should whittle your patch down to as few objects as you can while still demonstrating the unexpected behavior.

I think it's time that you post a clear example of your patch.  If you're having a problem, you should whittle your patch down to as few objects as you can while still demonstrating the unexpected behavior.


Here's a condensed patch wich continues to hold at least one track even after a manual 'clear'

The first thing I did was load a folder and play each buffer. Then I loaded a different folder and played each buffer. I didn't get any from the first folder in the second set. Maybe post a bug report.

The first thing I did was load a folder and play each buffer.  Then I loaded a different folder and played each buffer.  I didn't get any from the first folder in the second set.  Maybe post a bug report.
