I am getting a strange issue when sending looped midi data to my Shruthi via Reaper, the first note in the loop plays intermittently. I have not worked out a pattern yet, it plays maybe every 6 or 7th repetition and the rest of the time it just plays what sounds like an attempted note - like the note has just been played for a fraction of a second. If I move the note to the middle of the looped bar, it seems to play OK.
I have checked the following things:
1)That there is no overlap of midi notes within Reaper - beginning or at end of the loop. I have used the grid snap function to place the first note at the beginning of the bar so I am fairly certain that the beginning of the note is not outside the loop. I have stripped the loop down to just this note.
2)I have checked the Shruthi seq and arp settings. The mode is set to STP.
3)I get the same thing with all the Shruthi patches.
3)I exported the midi item from Reaper and played it via MidiOx (using the midi play loop function) and it plays fine.
4)The same loop plays fine with my Anushri via Reaper
Not sure what to make of this. Any Reaper users out there who might be able to help?
Do you have a MIDI monitoring program to look at what is actually sent by Reaper to the Shruthi. I bet it’s sending overlapping notes
I have tried using MidiOx to do this but got lost in the options. Could you recommend a simple application to record this data? I am using Windows.
You could try reducing note lengths and see if that fixes the problem. I’m guessing you have a note off and a note on at about the same moment in your sequence and either your sequencer or the midi driver is sending these in the wrong order.
In my experience, it has to do with the Shruthi’s envelope response to rapid midi messages. It will treat two very close and not overlapping notes as legato. So leaving a gap between notes is a good idea, but not because your interface is not sending them properly.
Thanks for all the suggestions. Comments below.
I have managed to attach a midi logger in the form of a VST plugin. I had no success trying to do this in external midi monitors. The outputs are attached as images (unable to copy and paste, sorry!) The file called ‘MidiLog_oneItem_Looped.png’ is the problematic output. Only the first loop, log item 1&2, played the full note correctly. The second file, ‘MidiLog_ItemRepeated_NoLoop.png’ is the same midi item but instead of being looped it is duplicated numerous time in the Reaper sequencer. Every note plays fine in this.
I’m afraid I don’t really understand most of the data in these outputs - can we conclude anything from this? I have attached the exported midi file for reference.
Windows 7 64 bit
Reducing the note length does not fix the problem unfortunately
This seems reasonable but there is quite a gap between each note. Take a look at the attached Midi file. It is just one note with a large gap after it.
Interesting. I have just unticked the ‘send clock/SPP to this device’ checkbox in Reaper’s midi output settings for my audio interface and the loop plays fine.
Is this correct? I have a limited understanding of how this is supposed to work.
@alestevens: Yes, this midi file wouldn’t cause that behavior. It could be an issue with Reaper, but I do not use that DAW. However, the less MIDI info you send to hardware, the better - that is my general rule of thumb.
Sorry for the necro, but hopefully that’s preferable to making a new thread for the same issue.
I’ve been running into this and it’s definitely related to the clock rather than overlapping notes. As alestevens notes, one can tell Reaper not to send MIDI clock and I’ve also discovered that taking the Shruthi off external clock works too.
As far as I can tell, it’s the clock starting again that interrupts the first note. I don’t know much about MIDI, but it seems that Reaper is sending a clock reset message or something at the beginning of its loop (I just checked this with a 1 and a half bar reaper loop and the Shruthi sequencer plays a bar and a half and starts again rather than 3:2 bar phasing thing).
As far as I can tell, the Shruthi momentarily trips up when it receives the clock reset message. Maybe it’s arriving after the note?
Is this the expected behaviour if the messages were arriving in the wrong order?
There are workarounds, but this is a bit workflow interrupting for me. Either I can have tempo synced LFOs and a screwed up first note or I have to lose external sync…
Yeah, I never fully understood this. Reaper is definitely sending a dodgy MIDI message at the start of a MIDI loop when the MIDI clock is enabled. It was really annoying me for a while but I have just ended up working around it.
I’m hoping for confirmation from someone who knows more about the Shruthi’s expected MIDI behaviour, but I expect it’s down to Reaper trying to sent the clock reset message and first note at the same time and therefore sometimes they arrive the right way round (reset then note) but a lot of the time they’re the wrong way around and so the note gets cancelled.
If I can get confirmation here that the Shruthi is behaving correctly then I might bring this to the Reaper forums and report it as a bug or feature request.
Later on I’m going to try using a program to monitor Reaper externally because I don’t think a VST would show the dodgy clock messages.
Other people have reported a similar issue when the “Start” message is sent right after the first note (rather than the other way round).
I can post a “fix” - but I’m not sure what I do on my side really needs to be fixed.
No, it’s ok. The problem is obviously Reaper sending the messages out of order. I just wanted to check that this was the expected behaviour before bugging the Reaper devs.
I guess I should ask, is the “Start message cancels notes” standard behaviour for MIDI devices or a quirk of the Shruthi? I don’t have any other MIDI devices to test this. I guess if it only causes problems for the Shruthi then it’s a bit much to ask the Reaper devs to fix if it doesn’t affect any other hardware (even if it is wrong to send the first note before the start message).
Jitter can mean things get sent at varying times?
Correct me if I’m wrong, but I wouldn’t have thought that jitter could actually alter the sequence of the messages? I thought that jitter caused timing inaccuracies as if there was constantly changing latency, but I thought MIDI messages were sent serially and that the sequence would be defined by the software sending them.
I’m assuming you mean jitter in my soundcard or in the OS, if you meant jitter in Reaper then I suppose that’s what I was accusing Reaper of in my previous posts.
Is the Shruthi’s note being cancelled by the start message ‘correct’ behaviour as far as MIDI standards go or is it a quirk of the Shruthi specifically? If the Shruthi is the only synth that cares then I understand why the Reaper devs wouldn’t bother to make sure of the order they get sent but if the Shruthi is behaving correctly then I can go and report a bug to the Reaper devs*.
*Hmm, unless it’s possible that something inbetween Reaper and the Shruthi is changing the order of the messages? My old and not great Edirol UA-25? Windows (which I know is supposed to be inferior to OSX in terms of jitter)?
It depends how the sequencer is coded, it may have multiple threads which won’t all be synchronised. There’s no timestamping (unless you have a fancy Steinberg interface) for MIDI, whatever gets written to the port first is output first.
In the Atari and Amiga you tended to use hardware clocks for stability, but with modern OSes there’s a few layers of OS in the way.
Right, so we were both thinking along the same lines. I wouldn’t have thought that hardware or OS jitter could re-order the messages but yeah, in Reaper I think that’s probably what’s happening. The clock obviously comes from Reaper’s clock, but the note data is coming from a MIDI item on a track and the jitter is causing the start message to fall after the first note.
I suppose in theory the events occur at exactly the same moment if the note is bang on the beat, but obviously only one MIDI message can be sent at once. You’d think they’d give clock messages priority though wouldn’t you?
I guess it’s enough to file a bug report, but I might wait and see if someone can confirm to me that the Shruthi’s behaviour is ‘correct’.
The MIDI standard doesn’t have anything to say about that.
Yup, it’s just bytes coming down a cable. So the “priority” will be decided by the design of the sequencer.