Good to hear from you,
Same to you!
Is it something specifically used to serialize/deserialize the state of a UGen?
I don't think so. It's mostly intended to provide an alternate, and un-typed api for a UGen.
What does the P stand for? Does that mean there are also NPMSGs that do the same thing? :)
Huh huh. Um, I can't remember what the P in pmsg stands for anymore. As for them npmsg's... it's unclear whether they are equivalent to pmsg's - another open problem in chuckian theory.
So maybe they would work like this:
StifKarp k => Filter f => dac; f.pmsg( "0.2 0.1 0.4; 0.2 0.4" );
Yup!
or something more like this, like an alternate namespace:
f.pmsg( "coefs", "0.2 0.1 0.4; 0.2 0.4" );
That too, though pmsg, for generality is always one string. So it's more like: f.pmsg( "coefs 0.2 0.1 0.4; 0.2 0.4" ); The UGen can define the protocol freely.
I'm still not sure I get it. But your explanation helps put it in perspective. (I'm working on a new UGen)
I think the key idea is that .pmsg is, so far, pretty worthless, hahaha. Though it sounds like you've gotten how they are to work as much as there is get. We'd love to hear about the new UGen, too! There are a few new ones, mostly out-of-the-box filters, coming in 1.2.0.7 as well. Best, Ge!