Sonic-pi: Double/triple midi cues for one action in 3.3-beta5

[xorik]

Hi. For some reason sometimes sonic pi beta triggers multiply cues for single action (e.g. pressing a button).

So result is breaking code like this:

current_notes = []

live_loop :midi_keys1 do
  use_real_time
  note, velocity = sync "/midi:*:1/note_*"

  if velocity > 0
    use_synth :dsaw
    current_notes[note] = play note: note, amp: velocity / 127.0, sustain: 5
  else
    control current_notes[note], amp: 0, amp_slide: 0.3 if current_notes[note] != nil
  end
end

To fix it I need to restart sonic pi (sometimes few times). The issue is never happened in v.3.2

Nothing interesting in the log:

~ $ cat ~/.sonic-pi/log/erlang.log

+--------------------------------------+
    This is the Sonic Pi OSC Server
       Powered by Erlang 23

        Incoming OSC on port 51351
  OSC cue forwarding to {127,0,0,1}
                     on port 51343
+--------------------------------------+



+--------------------------------------+
    This is the Sonic Pi API Server
       Powered by Erlang 23

       API listening on port 51352
+--------------------------------------+



+--------------------------------------+
    This is the Sonic Pi MIDI Server
       Powered by Erlang 23

   Detected MIDI input ports:
   ["launchkey_mini_lk_mini_midi",
    "launchkey_mini_lk_mini_incontrol",
    "launchkey_mini_mk3_midi_port",
    "launchkey_mini_mk3_daw_port"]

   Detected MIDI output ports:
   ["launchkey_mini_lk_mini_midi",
    "launchkey_mini_lk_mini_incontrol",
    "launchkey_mini_mk3_midi_port",
    "launchkey_mini_mk3_daw_port"]
+--------------------------------------+


Enabling midi cue forwarding
Enabling cue forwarding
Enabling cue forwarding

I have 2 midi controllers, but bug appears even if only one is connected.
Mac OS: 10.15.7, MacBook Pro (13-inch, 2019)
Demo: https://www.youtube.com/watch?v=TOPMo5QE360

You can see 3 runs: (1-bug present, triple cues, 2-no bug, single cues, 3-bug present, double cues). Sorry, no sound, but basically control isn't working so note is sustained and isn't silenced as supposed.

All 3 runs the same version of sonic pi.

[rbnpi]

I think you may have hit on a problem. The midi interface in SP is detecting two ports for each controller as you can see in the Erlang log, but is not differentiating between them in the cues log as seen in your video. Because you are using a wild card in the midi sync string note, velocity = sync "/midi:*:1/note_*" I think it may be that each of these ports is producing an input and hence the double cues. @samaaron has recently been doing a lot of work on this interface but it looks like in this case the different ports may not being differentiated properly, so that you can choose the one you want.
I think this is one for him to investigate.
Your program works fine on my Mac with identical OS, but the midi keyboard I use only shows as a single device.

[xorik]

@rbnpi thank you for your suggestions, but I think it's not the case:

1) It doesn't explain why it sometimes have single cue, sometimes double, and sometimes triple.

2) If you check the video, you can see that wildcard isn't source of the issue, because all repeated cues have exactly the same midi device/port:

I know that those devices have 2 midi inputs, but they are completely separated in terms of midi commands. I can prove it by opening another midi monitor program. Also it was not an issue in previous version of sonic pi.

[rbnpi]

(EDIT I know that the video shows the same port for all. My point is that you have two ports with the same initial part in the erlang log. but only the fist part of the name shows in the cues log.)

can you set up a virtual port in Audio MIDI setup, and then simulate your keyboard by sending midi from Sonic Pi itself. eg

sleep 0.5

live_loop :mout do
  n=scale(:c4,:major).tick
  midi_note_on n,velocity:80,channel: 1

  sleep [0.2,0.4,0.6].choose
  midi_note_on n,velocity: 0,channel: 1
end

added at the start of your program. This will then simulate sending from your keyboard. Sends to and back from the virtual port. My virtual port is named iac_driver_sonic-pi and when the program is running I get cues log like

...
 /midi:iac_driver_sonic-pi:1/note_on  [72, 0]
 /midi:iac_driver_sonic-pi:1/note_on  [60, 80]
 /live_loop/midi_keys1  []
 /live_loop/mout  []
 /live_loop/midi_keys1  []
 /live_loop/mout  []
 /midi:iac_driver_sonic-pi:1/note_on  [60, 0]
 /midi:iac_driver_sonic-pi:1/note_on  [62, 80]
 /live_loop/midi_keys1  []
 /live_loop/midi_keys1  []
 /live_loop/mout  []
....

[rbnpi]

Further thought. What ports show on the Help IO tab? Do you see two ports for your keyboard?
You can also get the port strings from auto complete in
use_midi_defaults port:

[samaaron]

I would have loved to have seen the Erlang log for each of the different runs. Is there a difference in the log between a run with single cues and one with triple cues?

Looks like I also need to find a nice way to let users enable more verbose logging for this kind of thing.

Definitely want to get to the bottom of this before we release. Looks like we're going to have to make at least one more beta :-)

[samaaron]

Could you also try v3.3-BETA-4 to see if the bug is still present there? (Temporary link)

https://sonic-pi.net/files/tmp/dd8a/Sonic-Pi-for-Mac-x64-v3.3.0-BETA-4.zip 

[xorik]

@rbnpi @samaaron demo on beta-5: https://www.youtube.com/watch?v=ra9IbkAj5OE

I removed the wildcard symbol from the midi path, except for the note_* part.

This time I recorded log and preferences IO dialog for each run (They always look the same for each run).
Also recorded midi monitor, to show it's not a hardware issue.

I used only one controller, that's why you can see less devices, than in my initial message (because the second controller throws a ton of clock messages). But it seems that if I connect both controllers, number of repetitions is always the same for both controllers (1, 2 3 or no repetitions).

The beta-4 link isn't working for me (500 error).

Thanks for helping, and let me know how I can help you with fixing that.

[ethancrawford]

@xorik - there was an extra bit of fluff on the end of the beta-4 link that was not visible in the text.
This is the correct link:
https://sonic-pi.net/files/tmp/dd8a/Sonic-Pi-for-Mac-x64-v3.3.0-BETA-4.zip

[samaaron]

One thought I had that's worth checking and ruling out is whether you somehow have multiple versions of the Erlang server somehow running.

When you get a program run they generates triple events could you just verify that you only have 1 beam.smp process running and not 3?

[xorik]

Wow, for some reason I have 58 instances of beam, even when sonic pi is not started 😄

~ $ ps aux | grep beam.smp | wc -l
      58

Looks like after each restart of sonic pi, I have leftover ruby and beam processes in memory.

I use this command in terminal:

ps aux | grep beam.smp | wc -l && ps aux | grep ruby | wc -l

On my computer after each run number of processes is increasing. After few runs I have 9 beams and 19 rubys :)

But good news, when I killed all those processes manually, the initial bug seems disappeared, so it's not MIDI related (most likely).

[samaaron]

Excellent news! This should be easy to fix :-)

[samaaron]

Lol, that wasn't easy at all to fix - turns out the code works just fine until you sign the app and run it from within a hardened runtime on macOS Big Sur - then it doesn't work ;-)

Hopefully I've fixed it now. I'm hoping to release a new BETA in the next few days which will include this.

[samaaron]

Hi, @xorik does v3.3-BETA-6 fix this issue?

https://www.patreon.com/posts/46604385

[xorik]

@samaaron yes, it seems fixed now! I did few runs and it always cleanup the processes properly. And I don't have any double cueing.
Thanks for fixing!

[samaaron]

Awesome news! Thanks for reporting the issue - it's so much nicer to be able to fix this now before the proper release :-)