Hi,
i route OSC messages an then unpack it.
[unpack 0 0 0 0]
with one OSC controller i get the error:
error: unpack: type mismatch unpacked: 3 14.8743 14.0385 20
with another OSC Controller nothing:
unpacked: 3 85.539 85.3286 20 unpacked: 3 15.0827 85.9539 20
why does unpack behave like that?
Unlike MIDI, OSC isn't a tightly defined protocol, so some implementations of "OSC Controllers" are different to others. Print out the data in its raw form, before you try to route it to a control destination and see what is different.
On Thu, Feb 16, 2012 at 10:23:31AM +0100, Christoph Kuhr wrote:
Hi,
i route OSC messages an then unpack it.
[unpack 0 0 0 0]
with one OSC controller i get the error:
error: unpack: type mismatch unpacked: 3 14.8743 14.0385 20
with another OSC Controller nothing:
unpacked: 3 85.539 85.3286 20 unpacked: 3 15.0827 85.9539 20
why does unpack behave like that?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2012-02-16 at 10:23 +0100, Christoph Kuhr wrote:
Hi,
i route OSC messages an then unpack it.
[unpack 0 0 0 0]
with one OSC controller i get the error:
error: unpack: type mismatch unpacked: 3 14.8743 14.0385 20
with another OSC Controller nothing:
unpacked: 3 85.539 85.3286 20 unpacked: 3 15.0827 85.9539 20
why does unpack behave like that?
It might be that the controller is sending the numbers as strings instead of floats or ints. [unpackOSC] will then just output them as symbol elements.
If that really is the case, you might be able to convert those symbol-numbers to floats with zexy's [atof] which was added just a few minutes ago. Check zexy from svn.
Roman
On Thu, 2012-02-16 at 18:37 +0100, Roman Haefeli wrote:
On Thu, 2012-02-16 at 10:23 +0100, Christoph Kuhr wrote:
Hi,
i route OSC messages an then unpack it.
[unpack 0 0 0 0]
with one OSC controller i get the error:
error: unpack: type mismatch unpacked: 3 14.8743 14.0385 20
with another OSC Controller nothing:
unpacked: 3 85.539 85.3286 20 unpacked: 3 15.0827 85.9539 20
why does unpack behave like that?
It might be that the controller is sending the numbers as strings instead of floats or ints. [unpackOSC] will then just output them as symbol elements.
If that really is the case, you might be able to convert those symbol-numbers to floats with zexy's [atof] which was added just a few minutes ago. Check zexy from svn.
What if this was handled in [float]? Something like this:
add a symbol method to [float]
convert the symbol to a float, then back and compare
if it matches, output the float out of the left inlet
if it does not match, output the original symbol out of a new right
outlet, which would be an "everything else" outlet like [select] [route], etc.
.hc
On 02/16/12 19:49, Hans-Christoph Steiner wrote:
What if this was handled in [float]? Something like this:
add a symbol method to [float]
convert the symbol to a float, then back and compare
if it matches, output the float out of the left inlet
if it does not match, output the original symbol out of a new right
outlet, which would be an "everything else" outlet like [select] [route], etc.
i like the idea, so i added it to zexy's [atoi] and [atof] methods.
regarding [f], i think it would be feature bloat and would rather not have it.
mgf IOhannes
-
Andy Farnell -
Christoph Kuhr -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Roman Haefeli