I'd prefer to catch direct use of the *Msg methods as well -- currently this helps only for object-style usage (which will catch most cases, but it's not truly complete).

And I just found this -- EventTypesWithCleanup bypasses the Buffer methods altogether. Setting control buses by events may be similar.

s.boot;

a = Buffer.alloc(s, 128, 1, completionMessage: { |buf| buf.sine1Msg([1]) });
b = Buffer.alloc(s, 128, 1);
b.setn(0, Signal.fill(128, { 1.0.rand2 }));

b.free;

(type: \sine1, bufNum: b, amps: [1, 1]).play;

a.plot  // a is affected even though the event said bufNum: b

I know that this solution isn't ideal. At one point, I has though about checking validity only inside the *Msg methods. That way, we aren't checking .isNil twice if we call for example .set (which then calls setMsg).

Looking at this again, I noticed some inconsistencies with how some methods and their respective *Msg methods are implemented. Compare Buffer set/setMsg to gen/ genMsg. In the case of gen, both methods send a potentially destructive server message!

The main reason why the implementation is so redundant is speed: argument passing is (relatively) slow, compared to method calls etc. And because these methods here are potential bottlenecks, they have these duplicates, like fill vs. fillMsg.

I've suggested a simplification which doesn't pass arguments. I think you could add this to the msg variants as well.

@patrickdupuis, you are working on an alternate version or extension of this right?

Yes - as we discussed yesterday, I was going to improve upon this. Can we un-merge?

Maybe, for now, I could simply add the same check to all the Msg type methods, and I'll commit myself to fixing it better for the next release.

I'm sorry that I had misunderstood it. Can you be so kind and just make a new pull request on top? We just continue from there.

no worries! I should have asked someone to label the PR as "Work in progess".

So, I can still add to this if I push to the same branch in my fork? That's good.

before you do more, can you try and push a little change to the same branch, and then see if github lets you make a pull request for it?

yeah, I would recommend pushing to the same branch

you won't be able to build on this PR, you will have to make a new one. since we have a no-force-push master, we can't undo it without also adding a revert commit. saves time just to add more on top of it.

See #2959. I can create a new PR from this branch. Please merge this PR as soon as possible so that I can commit more changes to my branch 👍