i'm going to echo sentiments from others complaining about '1e05' and other numerical issues. this and other strangeness seems to be tracked down to OSCx. in particular it seems values tagged as floats are arriving as "0". as in this:
(this is what OM recieves, and sends out to all its clients (which all update fine, except pd))
Path: /om/synth/set_port_value Arg 0: 'i' 1 Arg 1: 's' "/test/dj_eq_1/latency" Arg 2: 'f' 7.813730
(this is what PD recieves, clearly truncating the value to 0)
drip: symbol /om/control_change drip: symbol /test/dj_eq_1/latency drip: 0
any hints? it seems the 'int' type works fine with PD btw..this a 64bit issue maybe? i guess im going to write a OSC implementation for TCL and ditch pd as the 'core' to host my GUI, since the weirdness goes way beyond this, and extends to just abuot anything using a table, or DSP, etc...
Hi ix!
I use:
Server: pd 0.37.4 with OSC.dll 1.05 by Bob Falesch, adapted to route up to 32 paths. I use the dumpOSC object followed by OSCroute.
Client: DLL: OSC-client 0.2 by Matt Wright, driven by a DLL-Wrapper and VB-GUI
Sending that to pd:
ix@replic.net wrote:
Path: /om/synth/set_port_value Arg 0: 'i' 1 Arg 1: 's' "/test/dj_eq_1/latency" Arg 2: 'f' 7.813730
and printing the outlet of OSCdump I get:
print: /om/synth/set_port_value 1 /test/dj_eq_1/latency 7.81373
The float number appears correct as it is supposed to. Maybe you have another versions of binaries or some problems after OSCdump (if you use any).
Piotr