Announcement

Collapse
No announcement yet.

Getting swamped by Accelerometer messages

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting swamped by Accelerometer messages

    First off - thanks for a great product.

    I'm using TouchOSC on the iPhone connecting to OSCulator to send controller messages for my Midi guitar (see http://vimeo.com/30575892 )
    In that video I was using the XY controls and my fingers on the touchscreen to send filter/resonance messages and all worked well.

    However, last night I tried turning on the iPhone Accelerometer signals to provide a more hands-free control of messages which worked but I noticed 2 problems:
    1) There was a noticeable lag introduced on the midi guitar notes played
    2) The Novation keyboard I was using as a sound source would become unresponsive e.g. could not change voices and I'd have to pause/resume OSCulator or reboot the keyboard.

    I suspect this is down to message overloads so the questions I have are:
    a) Can OSCulator be configured to filter out controller messages (maybe by sampling from a stream of messages rather than processing all?)
    b) Can OSCulator prioritise the signals from different devices e.g. favour delivering the note on/off info from the guitar device over the controller messages from the iPhone?

    Cheers
    Mark

  • #2
    Hi Mark,

    You are correct in your analysis, it looks like your keyboard was swamped with too much data.
    TouchOSC sends a ton of information (too much!) from the accelerometers.

    I am sorry but there is no possibility to filter the stream of data passed to MIDI.
    Some time ago, I have already considered the idea of implementing a rate limiter or something similar, but finally decided that it would bring more problem than fixes.

    Sampling is not a possibility as MIDI (or OSC) has different semantics for messages that looks the same. It would only works for continuous messages, but how do you make the difference between them. Resampling the stream is another possibility, but the same problem applies.

    Prioritisation of note over continous is also a good suggestion. The previous problem does not apply in MIDI because you can make the difference between Continous Controller messages and Note On / Note Off messages. As a matter of fact, this kind of prioritization is implemented in OSCulator's Kyma driver to provide the best possible response for Note messages.

    However, the overloading you notice is not managed at OSCulator's level, and there is nothing I can do about it. The traffic jam occurs either at the MIDI interface level (because it must rate limit the stream to comply with the MIDI wire standard), or the jam could occur at the synth level. So changing the order of event for a Note vs a CC, would not change the problem at all.

    The only wise solution I see is to ask Rob, the author of TouchOSC to give an option to set the rate of the accelerometer updating, or at least turn down the sample rate to something more like 40 fps. This is a minor change that would help all TouchOSC's users.


    Best Regards,
    Cam

    Comment


    • #3
      Many thanks for the detailed response, Camille.
      I'll try take it up with Rob or failing that do you think that it would work if I wrote a Java proxy of my own to sit between Touch OSC and Osculator to apply some of my own custom filtering of OSC messages?

      Cheers
      Mark

      Comment


      • #4
        This sounds like a good workaround. You could start dropping OSC packets to lower the rate.
        A more complicated solution would be to calculate the running average of the continous controls, and run a timer that will send the computed value at a fixed rate (obviously lower than the original rate).
        Maybe you could also do that in PureData, it is free and not too hard to learn. (Rafael Hernandez has made great tutorials: http://www.osculator.net/2010/01/20/pure-data-and-osc/)

        Comment


        • #5
          OK, I've got a simple filtering proxy working in Java. I have a time-based filter to limit the rate and a distance-based filter based on minimum degree of change.

          Seems to work well

          Thanks again!

          Comment

          Working...
          X