Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 26 to 50 of 69

Thread: Open Sound Control

  1. #26
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    The Frankie board is ready to play. I2C yet has to be tested but Ethernet is up and running and it takes 3 seconds to register the OSC service on the Network via ZeroConf/ Bonjour.
    Looks like I'll have to try my own hand at making this communicate with TouchOSC

  2. #27
    Senior Member
    Join Date
    Mar 2013
    Posts
    126
    Quote Originally Posted by adrianfreed View Post
    There are some interesting dedicated hardware devices that support OSC well coming out for those of you who don't want to do
    the heavy lifting with Arduino or Teensy, i.e., https://github.com/tkrworks/PICrouter and http://www.x-io.co.uk/products/x-osc/
    And a wireless OSC to MIDI box: http://wifimidi.com
    I have been using x-osc for a few weeks and it works very well and has good provision for connection of Teensy - 4 fast serial ports can be enabled and the data merged in and split out of the OSC wireless stream. It uses a Microchip 802.11 module.


    I have also been studying small WIFI modules as OSC candidates for connection with Teensy's. One of the more promising ones used in recent designs (e.g. sparkcore), the TI CC3000 has some worrisome problems in the current firmware for UDP and long latencies through their API reported (20mS).
    I am curious whether anyone here has had good luck with any of the other modules, (e.g. Red Pine Signals, iWiFi, Digi Wifi XBee, Roving Networks Wifly).
    Last edited by adrianfreed; 08-14-2013 at 05:33 PM.

  3. #28
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    The WiFi module on the Arduino Yśn is promising. OTOH you could also go ahead and get a TP-Link Router and hook it to your Favorite Arduino flavor ( I assume Teensy3), which is what I am doing. The WiFi hardware on the Yśn the same as on the TP-link WR703n running an embedded Linux router software.

    I have found a TouchOSC example in an older implementation of Yotam's OSC library and think I should be able to get that working on my Teensy3 WIZ820io combo.

  4. #29
    Senior Member
    Join Date
    Mar 2013
    Posts
    126
    Thanks, I will definitely explore those solutions. My more urgent need is for a small wearable module for dance and body interaction work.

  5. #30
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    I see. Getting something that small and light is a challenge for WiFi. WiFi is also rather power hungry!
    Would that have to be WiFi or would Bluetooth 4.0 also be an option ?

  6. #31
    Senior Member
    Join Date
    Mar 2013
    Posts
    126
    We are building OSC support for TI's SensorTag which is an affordable interesting Bluetooth LE device.
    The hardware tends to be underpowered for BLE and over complex for WiFI. Fortunately in the kind of dance I am working on it is hard to perform for more than 20minutes which is feasible with WIFI.

  7. #32
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Quote Originally Posted by adrianfreed View Post
    We are building OSC support for TI's SensorTag which is an affordable interesting Bluetooth device
    I had this in mind when I posted. Seems to have pretty good software support.

    The sensor tag would be another nice alternative.

  8. #33
    Senior Member
    Join Date
    Jan 2013
    Posts
    966

    Problems with routing OSC bundles

    Having a problem not receiving, but routing an OSC bundle.

    I have not posted the entire code below but only the code in question:

    Code:
    void loop()
    {
    //Add your repeated code here
    
    // This actually runs the Bonjour module. YOU HAVE TO CALL THIS PERIODICALLY,
    // OR NOTHING WILL WORK! Preferably, call it once per loop().
    	EthernetBonjour.run();
    
    //read the incoming message
    	bundleReceive();
    
    }
    
    
    
    void bundleReceive(){
      int packetSize;
      int numOSCMessages = 9999;
      if((packetSize = Udp.parsePacket())>0){
        while(packetSize--)
        	bundleIN.fill(Udp.read());
        if(!bundleIN.hasError()){
        	Serial.print("Received Bundle with ");
        	numOSCMessages = bundleIN.size();
        	Serial.print(numOSCMessages);
        	Serial.println(" messages");
        	bundleIN.route("/TriClops/toggle1", handleAnalog);
        	bundleIN.empty();
        }
      }
    }
    
    
    void handleAnalog(OSCMessage &msg, int addrOffset){
    	Serial.println("Received Bundle : ");
    }
    The serial monitor printout :

    Code:
    Connected to /dev/tty.usbmodem1441 at 115200
    DHCP-Bonjour-based OSC server test 12/28/12
    Reading MAC from hardware...
    MAC: 04:E9:E5:00:05:A9
    Frankies IP address: 10.0.1.7.
    
    Setting Bonjour Name successful
    Bonjour Service Record added successfully
    Received Bundle with 0 messages
    Received Bundle with 0 messages
    Received Bundle with 0 messages
    Received Bundle with 0 messages
    Received Bundle with 0 messages
    So I can receive bundles, but there is no OSC message inside ?
    Somehow I believe there is a conceptual error in my thinking as I am sure that TouchOSC is not sending empty packets. That same TouchOSC layout works using ArdOSC in conjunction with a Teesny++2 and WIZ812io. Id greatly appreciate some guidance!

    Click image for larger version. 

Name:	Screen Shot 2013-08-17 at 9.12.06 AM.png 
Views:	355 
Size:	68.6 KB 
ID:	831

  9. #34
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Problem solved! Touch OSC appears not to send OSC Bundles, but OSC Messages.

    I tried to replicate the code I had found in an Arduino sketch example for and earlier version of the OSC library that was on Github before the library was moved to the current CNMAT Github repository.
    In That Example everything works with OSC bundles and I am assuming the previous library version that Arduino sketch worked with included a detection mechanism for determining whether an OSC message was received (incomingByte is "/") or if a bundle was received (incomingByte is "#"). the current library does not have that mechanism, or if it does , it does not work.

    The message never gets decoded as numMessages is set to zero when the object instance is created, but when a message is received it never gets increased by a numMessages++ and OSCBundle::decodeMessage does nothing.

    Code:
    void OSCBundle::decodeMessage(uint8_t incomingByte){
        //get the current message
        if (numMessages > 0){
            OSCMessage * lastMessage = messages[numMessages - 1];
            //put the bytes in there
            lastMessage->fill(incomingByte);
            //if it's all done
            if (incomingBufferSize == incomingMessageSize){
                //move onto the next message
                decodeState = MESSAGE_SIZE;
                clearIncomingBuffer();
            } else if (incomingBufferSize > incomingMessageSize){
                error = INVALID_OSC;
            }
        }
    The following code routes the OSC Message nicely.

    Code:
    void loop()
    {
    //Add your repeated code here
    
    // This actually runs the Bonjour module. YOU HAVE TO CALL THIS PERIODICALLY,
    // OR NOTHING WILL WORK! Preferably, call it once per loop().
    	EthernetBonjour.run();
    
    //read the incoming message
    	bundleReceive();
    
    }
    
    void bundleReceive(){
    	OSCMessage msgIN;
    	int size;
    	if((size = Udp.parsePacket())>0){
    		while(size--)
    			msgIN.fill(Udp.read());
    		if(!msgIN.hasError()){
    			msgIN.route("/TriClops/toggle1",handleMessage);
    		}
    	}
    }
    
    void handleMessage(OSCMessage &msg, int addrOffset ){
    	Serial.println("Message Received");
    }
    Last edited by Headroom; 08-24-2013 at 04:04 AM.

  10. #35
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Another issue I noticed using the OSC library is that it's allocating memory that does not get released again, depending on where the object instances for OSC bundles, or messages are created.

    For example in the code listed in the post above, when the object instance "OSCmessage msgIN;" is created within the function "bundle receive()" everything works as expected as memory is releases when the function ends.

    However when I create the instance in the main body before "setup()" and "loop()" it keeps allocating memory and appears not release all of it, even when using msgIN.empty().
    After receiving enough OSC messages, or bundles the Teensy3 simply crashes - for lack of better words - indicated by the led turning off and lack of response on the serial side. It has to be powered off and the teensy loader has to be restarted to get it going again.

    I used this function in that I found in a thread:

    Code:
    int heapSize(){
        return mallinfo().uordblks;
    }
    and printed out the "heap size" after receiving bundles and messages and emptying them and memory consumption kept increasing with every received message.

    I am not sure whether this is intended or not so I would assume it is not!
    Last edited by Headroom; 08-25-2013 at 04:15 PM.

  11. #36
    Junior Member
    Join Date
    Oct 2013
    Posts
    1
    Thanks Headroom for finding that leak.

    empty() was in fact not freeing the incomingBuffer which both OSCBundle and OSCMessage fill as the data comes in.

    I did some quick testing on a similar setup as you describe and found that the issue was resolved. Please let me know if that change fixed the bug for you.

  12. #37
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Is there a newer or better version of the OSC library that I should put into the Teensyduino installer?

  13. #38
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    @Paul,

    The OSCuino library is located here on Github

    That was a super speedy fix. After not receiving any response here on the forum in quite a while I decided to get a little bolder. I found an email address for Yotam on the Internet and decided to approach him directly. I wrote the email yesterday at 8:00PM EST and had a response with the fix in less than 3 hours. Unbelievable!

    Thanks to both of you for the help!

  14. #39
    This is an extremely interesting thread. I've been using OSC with Renoise and Processing for a while, and the prospect of interacting with Arduino/Teensy hardware is quite appealing.

    I'm quite interested in the Internet of Things. Usually when I read of something along these line it ends up being [small-device]-> [hard-wire]->PC-> [cloud] and back again; it's really PC-to-PC communication; the "things" are not the main drivers of messaging and intercommunication.

    I'm curious about one Teensy being able to exchange OSC messages with another Teensy anyplace in the world. I realize that there's a good deal of intermediation required, but those middle devices can be mostly dumb message routers (much the way two laptops can communicate over the 'Net).

    I thinking of how a device could use OSC to query some server for the OSC address of another device that's registered it's information and (assuming perhaps some means of authentication) move on to direct further OSC messages more or less straight to that other device.

    Is something that's already been done or worked on?

    I've seen somewhat similar things done using socket.io/websockets and Node.js, but it seems that ends up being too heavyweight to run directly on a small board like the Teensy. The actual messaging protocol is never run on the end device.

    This is where I think OSC has the edge. The part I have not seen addressed is general device registration/lookup and wide-area networking (e.g. my phone getting or sending OSC messages from/to my home thermostat when I'm out shopping.)

  15. #40
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    I don't want to dampen your spirits but believe it'd suit you well if you inform yourself a bit more about internet technologies and the purpose of the different TCP/IP protocols.

    There are several problems that you would have to overcome when sending OSC through the internet. For one, OSC is based on the UDP protocol. It is a connectionless protocol and UDP packages can get lost as there is no transmission control. In a LAN that's no problem, but on the internet it would definitely be! Of course OSC could theoretically also be transmitted through TCP but it's mainly aimed at speed and real time sound control.

    A protocol that does address resolution where a device "queries some server" already exists and is one of the main drivers of the internet called DNS. In order not to just resolve IP addresses but also "resolve" or better detect services ZeroCon/Bonjour and the associated protocols mDNS and DNS-SD were developed. As their name suggests these use the same structure as "regular" DNS. Again, those also work based on UDP.

    On a local network it is possible to program several Teensys to register services e.g. an OSC service on the network and discover each others services and exchange OSC messages with each other. Also OSC addresses are very application specific. on a LAN where you program all the devices you have full control over what is exchanged, on the Internet you don't so you need to rely on standard protocols.

    I woud disagree that most Internet of things devices are wired through a PC as the mediator. There is a whole host of WiFi and other RF solutions available that talk through a router to the cloud without the help of a PC. E.g. the CC3000 WiFi module from Texas Instruments is a popular choice in the Arduino world. The Arduino Yśn is another popular choice, the SparkCore, the Electric Imp etc...
    Last edited by Headroom; 03-30-2014 at 02:32 PM.

  16. #41
    Quote Originally Posted by Headroom View Post
    I don't want to dampen your spirits but believe it'd suit you well if you inform yourself a bit more about internet technologies and the purpose of the different TCP/IP protocols.
    Thanks; I'm already informed about Internet technologies and the purpose of the different TCP/IP protocols.

    Quote Originally Posted by Headroom View Post
    There are several problems that you would have to overcome when sending OSC through the internet. For one, OSC is based on the UDP protocol.
    Sort of an odd comment to make in a thread discussing the use of OSC over non-UDP transport. Indeed, that prospect of OSC over serial, etc., is what encouraged me to think of using the OSC format for a more general-purpose IoT medium. As the spec says, "OpenSound Control (OSC) is an open, transport-independent, message-based protocol." So long as each client/server part of a chain understands what transport is in use things should be OK.

    A Teensy might do OSC-over-serial to my laptop; the laptop does OSC-over-UDP to some local server; that server does OSC-over-TCP or something to some other server, etc.

    Quote Originally Posted by Headroom View Post
    It is a connectionless protocol and UDP packages can get lost as there is no transmission control. In a LAN that's no problem, but on the internet it would definitely be! Of course OSC could theoretically also be transmitted through TCP but it's mainly aimed at speed and real time sound control.
    OSC may have been intended as a better MIDI, where UDP is an excellent fit, but there's no reason it has to be so, especially if one is OK with some latency. I'm OK if sending an OSC message to turn off lights take s few (or many) seconds. I see no reason I cannot use, say, Websockets to bridge more conventional OSC clients and servers across different networks.

    Quote Originally Posted by Headroom View Post
    A protocol that does address resolution where a device "queries some server" already exists and is one of the main drivers of the internet called DNS. In order not to just resolve IP addresses but also "resolve" or better detect services ZeroCon/Bonjour and the associated protocols mDNS and DNS-SD were developed. As their name suggests these use the same structure as "regular" DNS. Again, those also work based on UDP.
    Some form of ZeroCOnf could be handy, but so too an OSC server that handles registration and queries. USe OSC to register yourself. Use OSC to ask about registered devices. I think it simplifies things for the end-point devices.

    Quote Originally Posted by Headroom View Post
    On a local network it is possible to program several Teensys to register services e.g. an OSC service on the network and discover each others services and exchange OSC messages with each other. Also OSC addresses are very application specific. on a LAN where you program all the devices you have full control over what is exchanged, on the Internet you don't so you need to rely on standard protocols.
    Going over the Internet I would expect to do the same thing as happens with PCs: use routers to connect a LAN to the outside world. I'm curious about doing this with OSC. It's certainly doable; just matter of what's a good way.

    Quote Originally Posted by Headroom View Post
    I woud disagree that most Internet of things devices are wired through a PC as the mediator. There is a whole host of WiFi and other RF solutions available that talk through a router to the cloud without the help of a PC. E.g. the CC3000 WiFi module from Texas Instruments is a popular choice in the Arduino world. The Arduino Yśn is another popular choice, the SparkCore, the Electric Imp etc...
    Things like SparkCore and the Electric Imp, if I understand them, work by requiring a centralized service. The commands exchanged are not interpreted directly by the receiving device.

    My interest in using OSC here is so that any device (not just specific hardware from specialized vendors) can operate in terms of a fairly simple set of well-defined standard messaging concepts. OSC fits that description.

    When I write the logic on my Teensy I'd prefer it not be coupled to some specific vendor. I don't want the code to be Imp-specific or SparkCore specific. OSC seems like it would provide a good abstraction layer without vendor lock-in.

    The technical issue is devising some conventions for device discovery and in bridging local networks across the Internet.

    I just don't want to reinvent stuff if I can avoid it, but I think this may be a case where I have to write some code to proof some concepts.

  17. #42
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    My comment on OSC being based on UDP stems not from the theoretical spec, but from the actual implementation in OSCuino. OSCuino can "Send and receive messages over any transport layer that implements the Arduino’s Stream Class such as Serial, EthernetUdp, and more." the "and more" as far as I am aware has not yet happened. Of course there is really no reason this couldn't also work over, say TCP and my own creations would be fine with some latency. It just is not yet implemented in OSCuino. In fact, I believe most actual non-cable implementations use OSC over UDP.

    You mentioned the desire for a wireless connection directly through a router without the involvement of a cable to a PC. The Arduino Yśn or a CC3000 connected per SPI to a Teensy allow you to connect directly to a router using TCP/IP without being tied to a specific vendor. In my own creations I use a Teensy connected per SPI to a WIZ820io that is cabled to a little WiFi pocket router. There is also no dependence on a specific vendor. I also use Bonjour to register an OSC service that then is discovered by TouchOSC.

    What I was trying to say is that the service registration part including on WAN is already invented with mDNS and DNS-SD. A DNS server infrastructure already exists and would not have to be re-invented. If you want to do this with OSC I'd still encourage youth read Zero Configuration Networking: The Definitive Guide as it also generaly explains the technical problems that have to be solved. Whether you use ZeroConf or try to implement your own ideas, the problems would be very similar.

  18. #43
    Dear all,

    Since all my favorite people are linked to this thread it seems to be the best place to add my question and it seems related to the topic. (Hi, Adrian, Yotam, Paul and Headroom)

    With help from Headroom I have a good connection between my teensy 3.1 the WIZ820io and my MAC.

    The only thing is that I cannot plug and play at the moment since broadcasting on my teensy does not seem to work. In practice this means that when I want to connect my teensy WIZ combination I first have to make a local Network (but I have to do that anyway so no problem there) but then I have to manually set my wifi address to the address that the teensy is using in the sketch. The broadcast address (in my case 169.254.255.255) does not work.

    Thanks in advance,

    Hans Leeuw.



    In answer to the original question in this topic from Paul: I am happy with the ethernet shield solution. But if there would be a USB implementation I would support the first four remarks by msutherl.


    My current code with the broadcast address (connecting three XBEE incoming streams to one stream over ethernet):


    #include <Ethernet.h>
    #include <EthernetUdp.h>
    #include <SPI.h>
    #include <OSCMessage.h>

    EthernetUDP Udp;

    //the Arduino's IP
    IPAddress ip(192, 168, 2, 4);
    //destination IP
    IPAddress outIp(169, 254, 255, 255);
    const unsigned int outPort = 9999;

    byte mac[] = {
    0x04, 0xE9, 0xE5, 0x00, 0x63, 0x54 }; // This is the current teensy's MAC address and can be found with the teensyMAC sketch.

    int32_t XBEE1[12] = { 1, 2, 3, 4, 5, 6 };
    int32_t XBEE2[12] = { 1, 2, 3, 4, 5, 6 };
    int32_t XBEE3[12] = { 1, 2, 3, 4, 5, 6 };
    byte checkArray1[] = {
    126, 0, 20, 131, 0, 1, 0, 0, 1, 126, 0 };
    byte checkArray2[] = {
    126, 0, 20, 131, 0, 2, 0, 0, 1, 126, 0 };
    byte checkArray3[] = {
    126, 0, 20, 131, 0, 3, 0, 0, 1, 126, 0 };
    byte bytenr1 = 0;
    byte bytenr2 = 0;
    byte bytenr3 = 0;
    int32_t incomingByte1;
    int32_t incomingByte2;
    int32_t incomingByte3;
    int32_t value1;
    int32_t value2;
    int32_t value3;
    OSCMessage msg1("/XBEE1/");
    OSCMessage msg2("/XBEE2/");
    OSCMessage msg3("/XBEE3/");

    void setup() {
    Serial1.begin(115200);
    Serial2.begin(115200);
    Serial3.begin(115200);
    Ethernet.begin(mac,ip);
    Udp.begin(8888);
    }

    void loop() {

    if (Serial1.available() > 0) {
    incomingByte1 = Serial1.read();
    if (bytenr1 < 11) {
    if (incomingByte1 == checkArray1 [bytenr1] || bytenr1 == 6){
    bytenr1 += 1;
    }
    else {
    bytenr1 = 0;
    }
    }
    else {
    if (bytenr1 < 19) {
    bytenr1 += 1;
    }
    else {
    if (bytenr1 < 23) {
    if (bytenr1 % 2) {
    value1 = incomingByte1 << 8;
    bytenr1 += 1;
    }
    else {
    value1 = value1 + incomingByte1;
    msg1.add(value1);
    bytenr1 += 1;
    }
    }
    if (bytenr1 == 23) {
    Udp.beginPacket(outIp, outPort);
    msg1.send(Udp); // send the bytes to the SLIP stream
    Udp.endPacket(); // mark the end of the OSC Packet
    msg1.empty(); // free space occupied by message
    bytenr1 = 0;
    }
    }
    }
    }

    if (Serial2.available() > 0) {
    incomingByte2 = Serial2.read();
    if (bytenr2 < 11) {
    if (incomingByte2 == checkArray2 [bytenr2] || bytenr2 == 6){
    bytenr2 += 1;
    }
    else {
    bytenr2 = 0;
    }
    }
    else {
    if (bytenr2 < 23) {
    if (bytenr2 % 2) {
    value2 = incomingByte2 << 8;
    bytenr2 += 1;
    }
    else {
    value2 = value2 + incomingByte2;
    msg2.add(value2);
    bytenr2 += 1;
    }
    }
    if (bytenr2 == 23) {
    Udp.beginPacket(outIp, outPort);
    msg2.send(Udp); // send the bytes to the SLIP stream
    Udp.endPacket(); // mark the end of the OSC Packet
    msg2.empty(); // free space occupied by message
    bytenr2 = 0;
    }
    }
    }


    if (Serial3.available() > 0) {
    incomingByte3 = Serial3.read();
    if (bytenr3 < 11) {
    if (incomingByte3 == checkArray3 [bytenr3] || bytenr3 == 6){
    bytenr3 += 1;
    }
    else {
    bytenr3 = 0;
    }
    }
    else {
    if (bytenr3 < 23) {
    if (bytenr3 % 2) {
    value3 = incomingByte3 << 8;
    bytenr3 += 1;
    }
    else {
    value3 = value3 + incomingByte3;
    msg3.add(value3);
    bytenr3 += 1;
    }
    }
    if (bytenr3 == 23) {
    Udp.beginPacket(outIp, outPort);
    msg3.send(Udp); // send the bytes to the SLIP stream
    Udp.endPacket(); // mark the end of the OSC Packet
    msg3.empty(); // free space occupied by message
    bytenr3 = 0;
    }
    }
    }

    }

  19. #44
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    What exactly do yo mean with "Broadcasting" ?

    Usually when connecting a device per Ethernet to a network I would assume it will connect a router either per cable or per WiFi .
    • The Router, if configured to do so, will assign an IP address to your Teensy per DHCP.
    • Each Teensy 3.x has its own mac address burned in. As you have commented in your sketch, this can be read out and used as the Ethernet mac.
    • With the Ethernet Bonjour library you can then register an _osc._udp service. This works particularly flawlessly on MAC OSX as Bonjour/ZeroConf is part of the operating system. However it can be installed on Linux (Avahi) or Windows as well.
    • Once you have registered the OSC service, other software, either running on a computer or other devices (teensy for example) can discover the service and use it. I use this scheme to control devices through TouchOSC on an iPhone and iPad.
    • The EthernetBonjour library also enables the Teensy to discover a service running on other devices.


    Service registration and discovery per Bonjour/ZeroConf should allow you to have that Plug-and-Play experience.

    A slightly different approach is employed by the monome devices. These also work with the OSC protocol through USB. They require to run a little server software called serialosc. Seril OSC detects when a monome device is plugged into a USB port. Once it has detected the device it will register a _monome._udp service per Bonjour. this _monome service is basically a OSC service. I believe serialosc is open source software. I am not exactly by what mechanism it detects the device but I believe the Arduinome has solved that problem. Needs a little gouging and instigation.

    Still hoping that my multicast mods to the Ethernet library will make it into the next Teensyduino release! Paul ?
    Last edited by Headroom; 04-18-2014 at 08:05 PM.

  20. #45
    Dear Headroom,

    First of all thanks for answering my question and quick as always. I don't think that my question was completely clear to you though so I'll try to explain a little bit more.

    Broadcasting means that you do not send your data to a specific network address but that you send it to all the computers on the network. This depends on the network mask. If your network mask is 0.0.255.255 it means that you should be able to broadcast to all computers on the network using the ip address *.*.255.255 (*.* mostly stays the same and says something about the type of network. In my case *.* = 169.254 is typically assigned on MAC computers when they can't reach the wifi_router (which is exactly what I want)). So if I tell my teensy to send to 169.254.255.255 I tell the teensy to broadcast on the network when it is in local mode. It should not matter then what the exact address of my WIFI adhoc network or my ethernet connection is (they will both have a 169.254.*.* address and both receive the data).
    There are a number of articles on the internet describing pro's and con's of multicast vs broadcast if you google for it. The reason I want to use broadcast is because it is more simple and I did not know about multicast until you mentioned it anyway. I do not really understand how it works either. I'd like to understand before using.... Would it work on a local network and not interfere with my shared desktop program? And how much time do I need to understand and implement it?

    I am not using a router in my set up. I don't need one. I am using another mode on the mac which enables the mac to make a so called 'local network'. The MAC then operates as sort of a router in itself but there is no connection to the internet. You can then use this local network to connect diverse devices to it also over WIFI. (if you have a MAC you'll find it under your wifi symbol in the menu bar).
    As explained earlier my setup does work so I am not to happy to change it and loose precious time again figuring out a different scheme..... The OSC examples provided by CNMAT use just normal networking and not bonjour so if I can get them to broadcast I am happy. And for now I can still do the extra steps (no plug and play) when I perform. It works.... Besides that I use my local network for example to connect my iphone to the macbook. I can then use a desktop sharing program to look at my computer screen. I don't have to rely on any network that is not mine in this way!!!

    About the bullets:
    The IP address of my teensy is assigned. In my case that is always the same. That problem has been overcome.
    No problems with my MAC address either.
    As said I am a bit hesitant towards the bonjour library if someone else can help me with the broadcasting. I forgot to mention that I see my data packages coming in through the ethernet port with the destination address 169.254.255.255 (checking this with CocoaPacketAnalyzer).
    Does that service create extra latency as far as you know? As you describe I understand that there is a service running on the MAC that is forwarding the OSC packages to the program?
    I am only interested in sending data from the teensy not in receiving...

    I am happy to finally be away from serial for my DATA. I'd like to keep it that way...

    Best, Hans.

  21. #46
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    I was aware what Broadcasting means in terms of TCP/IP networking

    It is simply not clear what the overall purpose of your application is as you only explain a problem without the overall context of what you are actually trying to accomplish.
    For example what are you doing with the OSC messages that you are sending. What software is processing these OSC messages and what is it doing with them ?

    This will make it a lot easier to determine what could be done to make thins more plug-&-play. In general broadcasting on the network in order to avoid having to configure things is a brute force method and I would not recommend it. I think Bonjour could really help you, pending an explanation what you are actually trying to do.

    For example let's assume you don't want to use an IP address hard coded in your teensy sketch. You would prefer DHCP but then you don't have any guarantee what IP address will be assigned to the Teensy and you don't want to configure the other devices or software your Teensy connects to. So you want to be able to ping your teensy not with an IP address but for example with ping teensy.local and you want that teensy.local to be resolved into the actual IP address automatically without you having to know what it is. Thats the most basic thing Bonjour does - Link Local Address resolution.

    Bonjour uses UDP as its underlying protocol just like OSC. Instead of sending only OSC messages per UDP you'd be sending a few mDNS messages.

  22. #47
    Dear Headroom,

    I send sensor data from the teensy to MAXMSP. about 500 messages per second and a payload of 24 bytes per message. It is control data to control sound processing with hopefully very low latency on the control data. Prior bad experience with serial data and diverse serial objects in MAXMSP led me to try out ethernet with OSC and thus far the experience is positive (better and more stable performance). Reading (NIME) articles from both CNMAT and IRCAM convinced me to take this route.

    How would hard coding my IP address help me in setting up the connection? It is the ip-address of my local network that keeps changing. Unless there is a method to connect to it through a name (like I do with my mobile phone when I connect to my local network) but I guess that is what bonjour can do?

    My application is a musical instrument. i have to set up a lot of things prior to my performance so cutting down on these tasks will create rest and concentration. That is why I would like plug and play instead of having to set up IP addresses each time. But time in general is limited as well. In my experience implementing a new protocol can sometimes take me a week when things are not straightforward so that is why I am not to eager to try your solution unless the implementation is straightforward.

    But I am willing to give it a try anyway. I suppose I have to install the Ethernet118bonjour library in my arduino library instead of the normal ethernet library. Is there an example patch on how to use bonjour?

    My latency question is related to the fact that the application is a musical instrument (www.electrumpet.nl) but I guess that is not influenced if bonjour only helps in setting up the right ip-connection.

    Thanks for thinking along.

    Best, Hans.

  23. #48
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    I guess my explanation was a little convoluted ;-) You don't want to have to configure the IP address on your Teesny every time you connect it to your computer. Lets see how I imagine for this to work:

    1. You connect your device to the computer. I am not exactly sure how that is done. Based on your description you are not using Internet Sharing but "create a new Network" and then connect to that. I am not at my home computer right now but will try test either tonight or tomorrow how that works.

    2. The Teensy requests an IP address from the computer per DHCP and the computer picks one from the pool of available adresses and assigns it to the Teensy.

    3. The Teesny registers an _osc._udp service per Bonjour. This registration will also include a name "e.g. "etrumpet.local" to the IP address the Teensy received from the DHCP server. When this step is completed you can open the "ping" command in a terminal window on your mac and ping etrumpet.local instead of having to know the IP address of the Teensy. The service registration will also include on what port this service is registert and whether it is a UPD or TCP service.
    Beeing able to resolve etrumpet.local into an actual IP address actually may already all you need to do as you are in full control of the UDP ports on the Teesny as well as on the MaxMSP side.

    4. You start your Max MSP application which will browse the available services for _osc._udp and will be able to show available services you can then select from. There is a MaxMSP plugin available that will do this for you http://maxobjects.com/?v=objects&id_...=0&id_format=0
    But, again as you are in full control of the port assignements you may not need the plugin.

    That's it. The only "action you wuill have to perform is to connect the etrumpet-teesny to the computer. The rest is automatic!

    I really would love to help you getting this to work. Your use case is a picturebook example of what can be done with OSC and Bonjour and you are using a very popular software in MaxMSP. I'd love to write an article of how to get this to work for my trippylighting.com blog.

    I personally use OSC and Bonjour in a very similarly fashion to control my LED lighting systems. The Teensy in my LED system signs on to the router my home computes and iDevices connect to. Then it registers an OSC service per Bonjour, which in turn is picked up by TouchOSC on my iPhone or iPad and I can remotely controll my creations without having to configure an IP address or port or have to think about what protocol is in involved.

  24. #49
    In answering

    1. I have internet sharing on but probably I don't have to. Did not try without yet.

    2. Yes. In my case that is always 192.168.2.4 so no worries there.

    3. This is the step I don't understand.
    The Teesny registers an _osc._udp service per Bonjour
    . Is there any code involved or does this work automatically when including the ethernet library in my sketch?
    Then the second step:
    This registration will also include a name "e.g. "etrumpet.local" to the IP address the Teensy received from the DHCP server
    . Where do I set this name? Is that in the software as well?
    The rest is clear.

    4. Ok. If I listen on the correct port and the teensy is connected to the local network and sends data to the IP address of that local network than I should see the data coming in in MAXMSP. The object for that is UDPreceive (formerly developed by CNMAT and now part of MAXMSP) which listens on the specified port address of the network that the computer is part of. (I am not totally clear where MAXMSP is listening exactly I must be honest)

    Thanks for all your time again.

    Best, Hans.

  25. #50
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    @ElectrumpetPlayer
    Our exchange strays from the actual topic of this Tread. While OSC and Bonjour very nicely complement each other IMHO, I suggest that we move this over to the ZeroConf / Bonjour Library thread.
    Yes, you need the EthernetBonjour library. This does not Replace the EtherntUDP library but rather inherits and uses it's methods. So both are needed.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •