sampler structure/efficiency question

oh and another question. I am using polybuffer~ the first time. I can't seem to find a message like (replace the file in buffer 3 with ... .aif), but only append or read folder messages. Isn't there anything like that? That would be a real pity.

You can use the send message:send 3 replace ... .aif

p

Ah! Thanks a lot!

With poly~ you can make a nice crossfade. Otherwise I don't really see why you'd need 8 buffers. Because if you don't care about interrupting the dsp chain then you might aswell just use one buffer and change the sample with the replace message.

I don't think i interrupt the dsp chain when i change the buffer a groov object should read from, do i? seems to work really fast.
i'm planning to change the referenced buffer at quite high rates and i'm quite sure reading a new file in is the slowest option, isn't it?
I mean my whole question is about efficience in the sense that i want it to react at hight rates and be as less CPU consuming as possible.

I'd recommend polybuffer~. It's fast, since you'll have already loaded the files, and you're just changing the memory pointer for the current buffer. It uses more memory, but that's not a big deal at all. It also means that if you do want something to overlap, you're not going to create a click or gap as you change sound files.

I'd say this quote from Donald Knuth is really good to bear in mind regarding optimization:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
(and I'd highly recommend the Wikipedia page on program optimization as a primer)

As long as you're not at the wall, you're going to be a lot happier with a solution that works well musically than one that runs 5% faster. Easy to control code makes for better music, and saves you time now in terms of complexity, as well as in the future, in terms of maintenance and flexibility.

I'd also highly recommend using poly~. I think a lot of people avoid it unnecessarily because it adds a slight amount of complexity, but the rewards are substantial in that it actually gets rid of some of the complexity that people create trying to avoid using poly~. (voice-handling/allocation, overlapping, etc.) Once you learn the adsr~ + thispoly~ combo, you're pretty much set. You can also very easily adapt your abstractions to use poly~.

The only way to know for sure if process A is more efficient than process B is to profile your code. Poly~ is a nice way of doing this since you can load up n copies of whatever with ease. I don't see anything in what you're describing that suggests a huge bottleneck with using poly~, so I'd say don't worry too much about any costs from using poly~ here.

In general, I think that most signal processing patches should be implemented as a poly~ for all but the most trivial cases or unless there's a highly compelling need otherwise. Here's what you get:
- Overlapping and polyphony. It's very rare that things don't overlap, and when you need it, it's already there.
- Not having to write your own extra handling code which will be buggy. (try it; it's a PITA)
- Muting
- Down-sampling/up-sampling/different vector sizes
- Almost as efficient for almost everything.
- Way more flexible, since you can also dynamically swap out poly~ patches.
- Parallel processing algorithms such as vocoders, spectral delay, etc. become trivial to implement and substantially more flexible. "16-band vocoder? Oh, you wanted 8 bands? Okay, let me change the argument to poly~..."

I'm a little bit zealous about the use of poly~, but it's always served me well. It also helps to promote good software development practices like decoupling controls from DSP which makes things easier down the road and that is a good thing IMHO.

Ah, I understand. You're right, changing the reference for the play object is way faster.
But you'll still want to use poly~, at least two instances of them. Because when changing the reference you'll get some discontinuity. With just two poly~ instances you'll be able to make a crossfade. But it might of course be that you don't care about little clicks.

Fisrt off, thanks a lot, i really appreciate you took the time t think about this!
About optimization, these are interesting thoughts, but i really want to do some optimization, this actually is a patcher that is.. hm i guess more than 4 years old and that i am continuously working on. now i am thinking about finally changing the structure of it since i need some CPU overhead for other features i want to implement.

Yes, i also tend to using poly, and it actually was my first thought too.
Anyways, maybe i even follow Peters suggestion and put the whole thiong inside a poly but still do the "sample change" vie reference to another buffer inside polybuffer~.
So the question that finally stays is, does it have a reason i am kind of skeptical about changing the buffer of a groove~play~ whatever object at very high rates?
(i will deal with clicking with windowing)

8 buffers and one play~ would be my choice, too.

of course changing the buffer to read from does not happen sample exact this way, but otherwise it is the best of all thinkable solutions.

-110