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
    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?
    ritschwumm
    @ritschwumm
    ich bastel gerade (mal wiede) an einer gui lib in pur scala, alles ziemlich low-level auf java2d aufsetzend...
    Hanns Holger Rutz
    @Sciss
    Hi @ritschwumm sorry, war ein paar Tage offline von den Software Kanälen und lese erst jetzt. Ich wollte ein paar einfache Graphikdinge machen, mich nervt aber der Zyklus mit fastOptJS und so weiter im Browser eher, und ich bin viel schneller mit der JVM; auch waere es langfristig gut, ein einziges API zu machen, was ich entweder fuer Dinge verwenden kann, die direkt auf JVM auf einem Raspberry Pi (z.B.) laufen, und solche, die dann im Browser laufen. Habe mal einen Anfang hier gemacht, was in der Tat sehr unproblematisch war: https://github.com/Sciss/Infibrillae/tree/sar21/shared/src/main/scala/de/sciss/infibrillae - sind aber bisher nur eine handvoll von Operationen. Wenn Dein Projekt auch auf beiden Kontexten funktioniert, bin ich nach wie vor sehr interessiert.