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, bla
– bla
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