Pfunc event order in Pbindef

Same question as https://scsynth.org/t/sendosc-with-pbind, right?

I had given you a suggestion here but there was no response.

(One side note: please use backticks to enclose the entire code example – I had to reformat some of your code in order to run any of it.)

```
the correct way to embed code into a post
```

Anyway – checking the pairs as I had suggested:

(
Pbindef(\pdef_test1,
	\instrument, "sin_atac",
	\dur, 1.0,
	\freq, 1000,
	\amp, 0.5,
	\pan, { rand(2)*2-1 },
	\bla, Pfunc( {|e| ~oscOut.sendMsg("/triger1", e.pan, e.freq ); } )
);

Pbindef(\pdef_test1).source.pairs
)

-> [ instrument, a PatternProxy, dur, a PatternProxy, freq, a PatternProxy, amp, a PatternProxy, pan, a PatternProxy, bla, a PatternProxy ]

So the order of the keys is, in fact, instrument, dur, freq, amp, pan, blabla definitely comes after pan – so, key order is not the problem.

There’s a new element in this code example, that wasn’t there in the old thread: \pan, { rand(2)*2-1 },.

TL;DR if you correct this to read \pan, Pfunc { rand(2)*2-1 }, then it should work.

  • \pan, Pfunc { rand(2)*2-1 }, means: While evaluating Pbind, run the function and set \pan to the value returned by the function.

  • \pan, { rand(2)*2-1 }, means: set \pan to the function object itself, not a concrete value. Then \bla evaluates, based on \pan = a Function. sendMsg tries to send the objects as given – but there’s no OSC representation of a Function, so nothing goes across:

    OSCdef(\x, { |msg| msg.postln }, '/test');
    
    NetAddr.localAddr.sendMsg(\test, \pan, { 1.0.rand2 });
    
    // result
    [ /test, pan ] -- **no value for pan!!**
    

    After that, the event-play logic does include instructions to resolve functions to their numeric values – but it’s too late, \bla has already run, and the other side already got the malformed OSC message.

So the take-away here is to be careful that all of the Pbind pairs are really patterns (or hardcoded values). Pfunc {} is a pattern and is valid. {} is not a pattern, and is not valid in this context.

hjh