Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Hanns Holger Rutz
    @Sciss
    With booleans-as-ints, your message will be larger than 32 bytes:
    val m = osc.Message("/test", 1, true, 2.3f, 4.5f, 6.7f)
    val c = osc.PacketCodec().doublesAsFloats().booleansAsInts().build
    c.encodedMessageSize(m)  // 36 !
    A message is not just the atoms, it's the header, the types, and all with some 4-byte alignments. http://opensoundcontrol.org/spec-1_0
    val m = osc.Message("/test", 1, true, 2.3f, 4.5f, 6.7f)
    val c = osc.PacketCodec().doublesAsFloats().booleansAsInts().build
    
    val confR = osc.UDP.Config()
    confR.localPort  = 44444
    confR.codec      = c
    val r = osc.UDP.Receiver(confR)
    r.connect()
    r.dump(osc.Dump.Hex)
    
    val confT = osc.UDP.Config()
    confT.codec = c
    val t = osc.UDP.Transmitter(localhost -> 44444, confT)
    t.connect()
    t ! m
    0000  2F 74 65 73 74 00 00 00  2C 69 69 66 66 66 00 00  |/test...,iifff..|
    0010  00 00 00 01 00 00 00 01  40 13 33 33 40 90 00 00  |........@.33@...|
    0020  40 D6 66 66                                       |@.ff|
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    dump for my bundle :
    x : -0.07136369 y : -0.07136369 z : -0.07136369
    r: 
    0000  23 62 75 6E 64 6C 65 00  00 00 00 00 00 00 00 01  |#bundle.........|
    0010  00 00 00 0C 2F 78 00 00  2C 66 00 00 BD 92 27 20  |..../x..,f....' |
    0020  00 00 00 0C 2F 79 00 00  2C 66 00 00 BD 92 27 20  |..../y..,f....' |
    0030  00 00 00 0C 2F 7A 00 00  2C 66 00 00 BD 92 27 20  |..../z..,f....' |
    Hanns Holger Rutz
    @Sciss
    This is the one that causes the exception?
    And what does r.bufferSize say? Your buffer must be at least 0x40 or 64 bytes large
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    no it throws the excetion before the dump :/
    Hanns Holger Rutz
    @Sciss
    But the dump r: that's coming from ScalaOSC, no? That means this is the dump
    Perhaps the exception is printed early due to concurrency, but that's the hex dump of your message
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    yes it was the bundle which works fine
    when i come back to a simple message it's throws the dump instantly
    the exception sorry
    SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
    SuperCollider 3 server ready.
    Exception in thread "UDP.Receiver@604ed9f0" de.sciss.osc.PacketCodec$BufferOverflow: /test
        at de.sciss.osc.PacketCodec$Impl.decodeMessage(PacketCodec.scala:573)
        at de.sciss.osc.PacketCodec$class.decode(PacketCodec.scala:696)
    Hanns Holger Rutz
    @Sciss
    But your message is called /test and not /x or /y, so which I don't see how this is the same content as your bundle
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    message : /test, x: float, y: float, z: float
    becomes
    bundle : (message : "/x", x: float ; message : "/y", y: float ; message : "/z", z: float)
    which is very ungly
    ugly
    Hanns Holger Rutz
    @Sciss
    Yeah, making a bundle doesn't make sense here anyway, unless you would rely on the time tag
    Ok, so yeah it seems the hex-dump is called after decoding, so that makes it difficult to assess how the packet is malformatted.
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    got an idea, it works with 2 float
    i'm gonna give the hex-dump with 2 floats see it can help
    Hanns Holger Rutz
    @Sciss
    cool
    Otherwise, you can also just hack together a plain hex dump receiver:
    val debug = new Thread {
      val buf     = java.nio.ByteBuffer.allocate(1024)
      val channel = java.nio.channels.DatagramChannel.open()
      channel.bind(localhost -> 44445)
    
      override def run(): Unit = {
        buf.clear()
        println("Waiting...")
        channel.receive(buf)
        println("Received.")
        buf.flip()
        osc.Packet.printHexOn(buf, System.out)
      }
    }
    
    debug.start()
    
    val confT = osc.UDP.Config()
    confT.codec = c
    val t = osc.UDP.Transmitter(localhost -> 44445, confT)
    t.connect()
    
    val m = osc.Message("/test", 1, true, 2.3f, 4.5f, 6.7f)
    t ! m
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    ok, this is new.. now that i send a single oscMessage, ScalaOSC receives it as a bundle
    either with calling
    m @ osc.Messag(...)
    
    r: 
    0000  23 62 75 6E 64 6C 65 00  00 00 00 00 00 00 00 01  |#bundle.........|
    0010  00 00 00 14 2F 74 65 73  74 00 00 00 2C 66 66 00  |..../test...,ff.|
    0020  BD 7A 6A 00 BD 7A 6A 00                           |.zj..zj.|
    never mind i messed up
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    dump for 2 different messages :
    x : -0.045681715 y : -0.045681715
    r: 
    0000  2F 74 65 73 74 00 00 00  2C 66 66 00 BD 3B 1C C0  |/test...,ff..;..|
    0010  BD 3B 1C C0                                       |.;..|            
    
    x : -0.05590892 y : -0.05590892
    r: 
    0000  2F 74 65 73 74 00 00 00  2C 66 66 00 BD 65 00 C0  |/test...,ff..e..|
    0010  BD 65 00 C0                                       |.e..|
    val m = osc.Message("/test", 2.3f, 4.5f, 6.7f)
    val c = osc.PacketCodec().doublesAsFloats().booleansAsInts().build
    c.encodedMessageSize(m) //size : 28
    Hanns Holger Rutz
    @Sciss
    Yes, these two messages are correctly formatted. I don't believe sending these to ScalaOSC would cause any problem
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    no it works fine
    s.bufferSize says 8192so 8K, fine
    so there is no possibilities to get a message of 3 floats?
    channel.bind(localhost -> 44445)
    how do you get localport?
    localhostsorry
    Hanns Holger Rutz
    @Sciss
    You can receive as many floats as you want as long as the buffer is large enough. If you still have the issue with the three floats, please try to send them to the val debug = new Thread... dummy-receiver above to get a hex dump
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    x : 2.2 y : 2.2 z : 2.2
    r : 
    0000  2F 74 65 73 74 00 00 00  2C 66 66 66 40 0C 25 3D  |/test...,fff@.%=|
    0010  40 0C 25 3D 40 0C 25 3D                           |@.%=@.%=|
    Hanns Holger Rutz
    @Sciss
    Cool. So yes, you have a malformed packet here. The 0x40 after the type tags ,fff is wrong. It should be a zero to terminate the type-tags section. Which OSC library is encoding this packet?
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    <dependency><groupId>com.illposed.osc</groupId>
                <artifactId>javaosc-core</artifactId>
                <version>0.3</version>
            </dependency>
    Hanns Holger Rutz
    @Sciss
    Weird. That should be pretty stable, I have never heard of such bug
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    so i'm not crazy haha
    Hanns Holger Rutz
    @Sciss
    The best would be to try to find a forum or bug-tracker for JavaOSC and see what they say about it. Definitely your message is wrongly formatted by not terminating the type-tags
    No, not crazy :)
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    i'll let you know about it!
    thank you for your time anyway its very cool
    Hanns Holger Rutz
    @Sciss

    From the spec:

    OSC-string:
    A sequence of non-null ASCII characters followed by a null, followed by 0-3 additional null characters to make the total number of bits a multiple of 32.
    OSC Type Tag String:
    An OSC Type Tag String is an OSC-string beginning with the character ',' (comma) followed by a sequence of characters corresponding exactly to the sequence of OSC Arguments in the given message.

    So the type tags must always be zero terminated, otherwise a client could not possibly know where to stop parsing them.

    Ok, good luck
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    the byte array which is sent :
    / test NULL NULL NULL , f f f @ FF 4 3 @ FF 4 3 @ FF 4 3
    the one that
    / test . . . , f f f @ . . . @ . . . @ . . .
    is received
    it's the exact same i guess