Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    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
    Pierre-Alexandre ADAMSKI
    @PierreAlexandreADAMSKI
    the MalformedPacketis send when checking on the PacketCodec the first decodeMessage() is called, i can't get farther on the debug so i can only refer to the dump output to compare the sender stream to the input stream buffer.
    I really don't understand how can that happen, but again, when i send a such message from javaOSC to puredata there is absolutely no problem...
    I feel like the MalformedPacket Exception must not be thrown
    from PD : OSC:string: /test 2.2 2.2 2.2
    moritz bust
    @busti
    Hey, I am using ScalaOSC for a project and I was wondering how to send data back to a client application.
    moritz bust
    @busti
    Favorably without creating a separate client.
    I know, it is probably stupid given how UDP works. But I just wanted to know.
    Hanns Holger Rutz
    @Sciss
    Hey @Busti can you be more specific... What do you mean by "without creating a separate client"? A client in UDP is just a combination of transmitter and receiver, so if you need to ping back you need another receiver at the sending side.
    Hanns Holger Rutz
    @Sciss
    Sorry for the late reply - didn't have notifications enabled
    moritz bust
    @busti
    No problem.
    I have to send a lot of OSC Messages whenever I recieve one. It would be great if I could answer a recieved UDP message with sender ! Message whenever I recieve one. Right now I instantiate a new Client whenever I receive a message and store them to a map with the address of the sender as key, for later use.
    Hanns Holger Rutz
    @Sciss
    I see. Yes, this is possible without creating a new client each time. Let me give you an example.
    So you want a receiver that can reply to the sender, as I understand.
    There are two scenarios - one is you have a 1:1 connection, so always the same transmitter and receiver are connected. Or your receiver can server multiple transmitters. Let me show the latter case.
    Hanns Holger Rutz
    @Sciss
    // set up our "server"
    import de.sciss.osc
    val t = osc.UDP.Transmitter() // for sending replies
    val r = osc.UDP.Receiver(t.channel) // re-use channel!
    r.connect()
    t.connect()
    
    r.action = { (packet, sender) =>
      println(s"Server received: $packet")
      t.send(osc.Message("/okay"), sender)
    }
    
    // set up a client
    val c = osc.UDP.Client(t.localSocketAddress)  //  note: the address argument is the _server target_!
    c.connect()
    c.action = { response =>
      println(s"Response from server: $response")
    }
    c ! osc.Message("/ping")
    
    // text output:
    // Server received: Message(/ping, )
    // Response from server: Message(/okay, )
    This "server" bit is indeed tricky, because you want the same socket/channel both for receiver and reply-transmitter.
    moritz bust
    @busti
    That is indeed a lot more sophisticated than my current setup, thank you. I realized that this is about the same as the example on Github, I just could not wrap my head around it.
    Hanns Holger Rutz
    @Sciss
    So osc.UDP.Receiver() and osc.UDP.Receiver(channel) create an undirected receiver, whose action function takes two arguments, packet and sender's address, whereas osc.UDP.Receiver(socketAddress) creates a directed receiver, who can only receive from the given address, and thus the action method's function only has a single argument, the packet, as the sender's address is already known.
    Yeah, I had to think about it myself again :) It's not entirely intuitive.
    There should be osc.UDP.Server() to do what I did with the separate t and r. I'll add that to the to-do list.
    moritz bust
    @busti
    Great!
    Thanks again for replying, this feels a lot more correct compared to the usage of the map.
    Hanns Holger Rutz
    @Sciss
    Cheers
    ritschwumm
    @ritschwumm
    gerade zufällig auf deine frage gestoßen - was hattest mit die einer scala-api als facade für Graphics2D und html5 canvas vor?