assurance-tunnel
assurance-tunnel
assurance-tunnel
assurance-tunnel

Guru Session #9: Open Sound Control (April 22nd, 2020 - 6pm CEST/5PM GMT/12pm EDT/9am PDT)



  • Dear Community,

    In today's installment of the "guru sessions", open to all levels of experience, we'll dig deep into Open Sound Countrol (OSC), a protocol that allows Isadora devices and other programs to communicate with each other for real-time interactive control. You'll learn how to receive OSC and use it to control your patches, how to control other applications by sending them OSC messages they understand, how to create a custom layout for the incredibly useful control surface app TouchOSC.

    We'll be using the OSC enabled apps TouchOSC (iOS/Android) and GyrOSC (iOS only) and FaceOSC (Mac/Win) during the demonstration. (TouchOSC and GyrOSC are not free, but I can highly recommend both for anyone seeking ways to sense a person's movement and orientation using a device.)

    The materials for today's session can be downloaded here.

    6pm CEST (Europe) 5pm GMT (UK) 12pm EDT (East Coast USA) 9am PDT (West Coast USA)

    Click here to watch the live stream (also good for later viewing)

    Best Wishes,
    Mark



  • Can you use OSC to send data from a different Ap running on the same computer to Isadora? I want to send data from MAX to Isadora



  • https://play.google.com/store/apps/details?id=com.oneten.drive.zig_sim&hl=en

    ZIG Simulator is an application for "the physical prototyping prototyping".
    Data of a lot of sensor with a smartphone by utilizing ZIG Simulator it is possible to send to the destination device by UDP socket communication.
    Thus, without electronic kits, it enables verification of wearable devices and IoT.

    iphone & android



  • First session I've been to tonight and it was great. Looking forward to watching back over the earlier ones (and the ones still to come)!

    I'm not sure if this is a question or a feature request, probably depends on the answer... and sorry if this is a bit rambling, I might not explain myself very well.

    > Am I correct in thinking that each unique OSC address needs a unique Channel number? I imagine setting different addresses with the same channel could lead to complications.

    > Secondly, is there a way of referencing an incoming OSC address within the patch, say to use in a string for example?

    The main reason I'm asking is because I often need to integrate show systems with lighting desks, normally ETC ones, and am often having to find work arounds. Now the OSC implementation on ETC desks was poor for a long time but, while it's still not great, it's getting better and is becoming more and more useful. Once you have OSC transmit turned on the desk will basically output everything it's doing, using specific OSC addresses/arguments. Some things are really easy to implement in Issy, such as data from submasters. Every time you move a submaster the desk will transmit /eos/out/event/sub/X followed by the data (where X is the number of the submaster). This is great as you can easily set an OSC channel in Isadora for each sub and see it's value from 0-1.

    However, every time a cue runs the desk will transmit /eos/out/event/cue/X/Y/fire followed by no other data (where X is the cue list number and Y is the cue number). So with this address one would need a separate OSC channel for each cue, of which there could be many. Also the cue number could be a float so the numbering of channels could get confusing. And, with no data attached after the address does Isadora 'see' a new value as having arrived?

    The ETC desks aren't the only regularly used show equipment that behaves like this, some of the built in stuff in QLab is similar, so it would be great if it were possible to do something like the following:

    Tell Isadora to look for part of an address and if then show the address as a string. For example have Channel 1 as the address /eos/out/event/cue/* (where * means any value) and have the OSC listener show the full address as well as the other data. This way you could check for the argument at a given position in the string (in this case the cue number) using something like Text Chopper and/or Parser.

    I'm sure there may already be a way to do this by reading the raw TCP/UDP packets (i'm not sure if those are the correct terms sorry) but it would be great to handle it within the OSC interface. I'm also well aware that this is asking for a work around due to the limitations of things that aren't as flexible as Isadora. I do think it would be useful to have access in the OSC listener to more of the incoming data though, including the address.

    Thanks again for a great session tonight!


  • Beta Platinum

    @kathmandale

    You aren't the first one to request this. I'm also an ETC fan and love to tinker with the feedback that I receive from them and sadly I had to use other software to built my tools for my performances because Isadora is quite 'fixed' with the way that OSC flows through the program.

    For the topic see https://community.troikatronix...


  • Beta Platinum

    Hi,

    Here is a demonstration patch made for FaceOSC (Mac OSX 10.14). It is an Isadora 3.07 file.
    It uses the 'raw' OSC to generate a line puppet face with scenes that use the 3D Lines and 3D Particles module. For those who like to play....Face_Tracking_Demo_bonemap.izz


    Kind Regards

    Russell



  • @juriaan

    ah, thanks Juriaan, I missed that. I use OSCrouter a lot, which is a great tool, but still often need other bits and pieces to set up with Isadora when OSCing out of ETC world.