Results 1 to 5 of 5

Thread: 3.1.2: poss Note Off bug?

  1. #1
    Serious User
    Join Date
    Jul 2010
    Posts
    38

    3.1.2: poss Note Off bug?

    Hi Camille,

    I've encountered some buggy behaviour in 3.1.2, which is causing some LEDs on my Launchpads to go off when they should stay lit! Behaviour is also slightly inconsistent: generally, all LEDs that should stay on, turn off nearly instantly, but sometimes, some light up correctly and the other LEDs go out.

    I also have version 3.1.1, and the same OSCulator documents (OSCuments?) work seamlessly and as expected.

    Is there any console output or logs etc. that I can post to help you trace the bug?

    (macOS: Sierra 10.12.6)
    Attached Files Attached Files

  2. #2
    Hi Clik,

    Thanks for letting me know!
    I will have a look at the attached file and revert asap.

    Best,
    Cam

  3. #3
    I have a couple of questions:


    • How is supposed to behave /128/clear? Could you please describe it? I understand it is merely called once with one integer argument of value 0. I searched on the Internets for more info about the Molar plugin, but it seems it's gone. I assume /128/led follow the Monome protocol, that is three arguments, x, y and state (0 or 1 depending on the led resp. off or or).
    • Can you please try the attached file? Basically what I changed is that I simply duplicate /128/clear and assign the same MIDI Note-Off and CC events, instead of first demuxing it on the value 0.


    Thanks.
    Attached Files Attached Files

  4. #4
    Serious User
    Join Date
    Jul 2010
    Posts
    38
    Thanks Camille - your fix for 3.1.2 worked (also works without issues in 3.1.1).

    How was 'demuxing on the value 0' the problem, and duplicating and reassigning the messages the fix?

    The 'clear' message is part of a 'meta' function, triggered by any of the 16 pads on the bottom row of the Molar grid - meta functions are for editing, changing pitch, randomising sequences etc.

    1 'Meta on' clears streaming sequencer related leds and
    2 Allows for editing etc. while continuing to block incoming sequencer messages from displaying.
    3 'Meta off' clears currently displayed meta related leds, so incoming sequencer leds can be displayed again.

    Molar 128 meta row.jpg

    (Molar was 'donation-ware', about 10 years ago - there were long threads about it on the 'disappeared' old Monome forum - they can only be found now via the Way Back Machine.
    https://web.archive.org/web/20111128...nID=260&page=1)

  5. #5
    Hi Click,

    Thanks for the details, it's much appreciated.
    It's really too bad Molar is gone, and the Monome forum.

    How was 'demuxing on the value 0' the problem, and duplicating and reassigning the messages the fix?
    To cut a long story short: you cleverly exploited a bug that was later fixed in version 3.1.2. The fix restored the behavior of messages received with no argument... and broke your setup.

    The long story: OSCulator simulates an argument for received messages with no argument. This means that if OSCulator receives a message like "/hello", OSCulator will artificially send to itself "/hello 1.0" and then "/hello 0.0". The rationale is that events requiring a trigger (like MIDI Notes) will have something to consume, and we keep the same simple model (that already works with TouchOSC, Wiimotes, and most button-like controls).

    Now, when you demux the first argument of a message with N arguments, OSCulator exposes a sub-message with N-1 arguments. In your case, /128/clear had 1 argument. When you demux it, OSCulator exposes a sub-message "/128/clear `0`", with no argument. And naturally, the events you configured were triggered twice (because of the behavior of messages with no arguments, explained in the previous paragraph)... pfew!


    Best,
    Cam

Tags for this Thread

Bookmarks

Posting Permissions

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