Midi in events not triggering

:thinking: Yes, cue and sync are working ok.

(edit) …and the Launch Control is receiving midi messages (for switching on-off buttons) from Sonic Pi with no problem

In the first message I wrote that it was working on version 2. Obviously, this is wrong, because midi functions started on sonic pi 3. So, the working version I was using was 3.1. Now I’m back to v3.1 and it works again

I’ve just got hold of version 3.2.2 on Windows 10 and I’ve been working through the tutorial for the last few hours. I was just trying out the example in section 11.1 and I’ve just hit this issue, too. Midi events - I’m specifically looking for note-ons - are appearing in the Cues window, but the live loop doesn’t trigger. Everything else has worked wonderfully up till now. (I’ve been specifically interested in the threading/live loop examples.) Like the original poster, I tried moving back to version 3.1 and yes, this does work. I noticed in 3.1 that midi in events are named with forward slashes in 3.1 - “/midi/modal_002_48/25/1/note_on”, but in 3.2 there are colons - “/midi:modal_002_48:25:1/note_on”. Is this likely to be significant?

Also, I noticed with 3.2.2 that after stopping and restarting Sonic Pi all midi inputs are likely to have disappeared from the Midi Ports list in Preferences/IO. (Output devices are always present.) Restarting the PC will reset this. With 3.1 I’ve seen this happen once, but most times input devices show up each time I restart Sonic Pi.

I’m a longtime programmer/hacker, though not with this particular environment, but happy to dig in and help debug if given a few clues as to what to do next.

hi @BN1701,

Please post your code you are testing to help us to help you :slight_smile:

yep it’s normal. there is a change between these two versions.
Midi changes for upcoming Sonic Pi 3.2

Thanks for the reply. The code is just the example from the tutorial, section 11.1, modified with my own midi in port info and with an extra puts call for debugging:

live_loop :midi_piano do
note, velocity = sync “/midi:modal_002_48:25:1/note_on”
puts “Hello …”
synth :piano, note: note
end

Nothing appears in the log after the initial run info, despite fresh midi events showing in the Cues panel. (Screen shot attached, I hope.)

see this topic

Update …

I think the issues I’m having are to do with midi loops. I had been running loopMidi from Tobias Erichsen, which provides a way of sending midi between apps running on the same PC. I see from the Midi Ports list that Sonic Pi automatically opened the inputs and outputs of the ports that I had set up in loopMidi. Shutting down loopMidi and restarting the PC (I previously had loopMidi running automatically at startup) the example code that I posted previously now runs as intended. So, I have two questions:

Firstly, why wasn’t this a problem in version 3.1?

Secondly, is there a way of choosing which midi ports are opened by Sonic Pi?

This second feature would be great to have regardless of the current problem, as in Windows only some USB/midi drivers can be shared/opened by more than one app and once Sonic Pi has grabbed all the ports nothing else can use them (even when Sonic Pi doesn’t actually need them). This applies to any devices which use the Windows class compliant driver. (In fact I only have two devices out of about ten that have their own custom drivers, all the others have to use Windows’ own non-sharable class compliant driver.)

Thanks,

BN

sonic pi shows you midi ports available. Then you specify which midi port you want to send messages via the midi instruction options :

use_midi_defaults port: "loopmidi01", channel: "11"

or

midi :e1, channel: 3, port: "loopmidi01"

I often use loop midi with no pb at all.

Sorry nlb, that’s not what I mean. I know how the functions ‘midi’ and ‘use_midi_defaults’ allow you to choose where to send midi, but Sonic Pi opens all available ports regardless of whether you intend to use them. Just try opening up your Daw whilst Sonic Pi is running. All the class compliant devices will be unavailable because Sonic Pi has already grabbed them.

Ok sorry. would you give more details about your set ?

Here’s a screenshot showing midi ports not being shared. Hopefully you’ll see what my setup is like from this, too (though I’ve turned off most of it to simplify what’s going on):

In the background you’ll see that Sonic Pi has opened four usb devices. If then I load Reaper it reports that it can’t open three of them. These three all use Windows’ own class compliant USB/Midi driver. The fourth device is my RME Babyface, and that has a custom USB/Midi driver provided by RME and this is open properly in Sonic Pi and in Reaper. If I close down Sonic Pi at this point and click Retry in Reaper, all ports will be opened.

It is generally known that the Windows class compliant USB/Midi driver can’t be shared between apps. This is not a problem with Sonic Pi. The way that most apps deal with the situation is to provide a configuration mechanism for opening only those devices that you actually want to use within a session and leaving the rest alone. This is what I was asking if Sonic Pi could do, because it would make things much more flexible overall. For referene, Reaper’s configuration dialog looks like this, though a configuration script stored somewhere would be just as useful to me:

image

On loopMidi (and midi feedback potentially being a problem), after you said that you’d been using loopMidi without problems, I checked again here. This time I can’t find a problem with it either, at least not one that I can reproduce :frowning: I’m now back to not knowing why I had the problem in the first place. I’ll just have to keep trying things out and see what turns up.

Thanks for all the replies :slight_smile:

thank you for your screenshots :ok_hand:

as you use 3…2.2, your code should use /midi*/note_on no ?

sorry but to be clear what do you want to do ? Use reaper to send midi notes to spi ? use sonic pi to send midi notes to reaper ? the midi link is created via loopMIDI ?
Hope others can help you morenthan i do :flushed:

to be honest i’ve never heard about

In this instance I just used the auto-suggested port ID that was provided. I have noticed that these port IDs will vary between sessions and yes, it would be a good idea to use wild cards to avoid being too specific - though I will always want to name a specific interface and midi channel.

Overall, I’m just exploring and have no specific application in mind at the moment. I used Reaper here to illustrate the port-sharing issue as it is the DAW that I’m most familiar with. In other instances it might have been Ableton, or other midi enabled apps like VCV Rack, or specific synth editors.

I do know that the port sharing issue will be a wider problem for a lot of people and I think the ability to enable/ignore specific ports will be invaluable in these situations. I have a lot of outboard synths and I can easily imagine a scenario where Sonic Pi is controlling some of them but other sequencers (e.g. Ableton) are controlling others. (And here’s where I might use loopMidi to send midi data and clock between them.)

I will look a way of submitting a feature request.

Thank you. You have been helpful. The fact that someone answered my questions and engaged with me shows me that this community is alive and welcoming and this has encouraged me greatly to keep learning about it :slight_smile:

so if i do understand you if i try the following scenario :

  • helm (a little synth software) received midi notes via loopmidi01 port
  • spi sends to loopmidi01 to play notes via helm
  • ableton live sends to loopmidi01 to play notes via helm

it will fail ?

Edit : it works but maybe i misunderstand your pb :slight_smile: again and again…

Hi BN,

Sounds like you’ve been to places that aren’t quite as friendly as we are.
If so you have my sympathy.

We get all types of people here, ranging from 10 year olds to 60+'s.

Many have no musical knowledge (me), cant play an instrument (me),
and break out in a sweat when they look at computer code (yup, also me).

This is a safe place, and there are no stupid questions.

You’ll almost always get a reply within a few hours, depending what time of
day/night you post, and if it’s something that catches peoples imaginations,
you’ll get swamped with replys and suggestions.

I think most of us are too busy learning and enjoying SP to get salty with people,
you know?

Certainly I’ve never seen it, and I’ve hung around maybe 3 years now.

So please relax, dive in, and enjoy SP along with the rest of us.
Welcome to the madness, matey.

Eli…

1 Like

hi @Eli,

@BN1701 is very very cool you know :slight_smile: and in my opinion has never seemed to be nervous or something like angry.
Cheers

I’ve been using synths since the end of the seventies and had an alternate life as a programmer until maybe ten years ago, so I guess you could say I’ve been around the block a few times and I’m lucky enough to feel confident about diving into most things new. What I often find though is that when I do come across something interesting it falls over in some way because it’s unfinished and I find there’s no one around to support it. That’s when I get discouraged. A bit like turning up at a party after everyone else has moved on. However, that definitely doesn’t seem to be the case here :slight_smile:

And I do agree that there are no stupid questions.

1 Like

Nothing in that scenario is using a the Windows USB class compliant driver so everything should work. The class compliant driver is only for USB hardware that doesn’t have a custom driver. And (I think) loopMidi ports can be shared, too. If I remember correctly, the guy who wrote loopMidi also offers a service writing custom drivers for other vendors, so I assume he understands the requirements completely :slight_smile:

I haven’t come across Helm, by the way, I’ll check it out at some point.

1 Like

Hello,

I’ve faced a similar problem while trying to sync MIDI events from a Roland V-Drums.

Syncing using the following path didn’t work:

note, velocity = sync "/midi:td-1:0:10/note_on"

So I’ve followed the * trick mention above:

note, velocity = sync "/midi*/note_on"

It’s not a problem for me because I didn’t intend to sync multiple MIDI devices at the same time but it’s still didn’t get the root cause.