Lost midi events, time elapsed between 2 midi events ?

[Jeffos]

[EDIT] With more JS pratice, I now think that this issue was due to something like: http://forum.cockos.com/showthread.php?t=50634

OP:
______

"LOST" EVENTS ISSUE:
I'm doing some classical processing on midi events sent by an e-drum: something like "while (midirecv(ts,msg1,msg23)[...]".
It most cases, it works fine BUT when the events rate becomes higher (e.g. roll on the drums) most of those events are "lost" !! After some debug + monitor at the output of my JS, I've seen that the events are not really "lost", in fact there're not processed at all, they pass thru
(and it's not a programming error).

I didn't find any thread dealing with that issue: is it a known issue ?
... and the most important question: HOW CAN I FIX IT ?

For the moment, I use this work around: copy/paste of the faulty JS (events missed by the 1st instance are processed by the 2nd one) but, it's really complex: processing started in the 1st instance / finished in the 2nd one, variables sharing, etc...

Remarks:
- not a PC perf issue (monster !)
- MIDI ROUTING: events are received form a track where a 1st (very simple) JS midi filter applies. No issue with this one, all events are correctly processed !
Then those events are routed to another tracker with the faulty JS



Elapsed time beween midi events:
Can someone provide a code sample or help me to compute the elapsed time between 2 midi events ?
I'd a look a schwa's humanize JS, but it didn't helped me...


Thanks!

[Jeffos]

Spent some time on the LOST MIDI EVENTS ISSUE:
- Same issue after JS optimizations (as far as possible but, from a given point, it also has to do its job!)
- Same issue without MIDI routing (i.e. JS directly in front of the MIDI hardware).
- Same issue when I slightly update (i.e. increase CPU usage) some the JS provided with reaper

I'M REALLY SURPRISED THAT NOBODY HAS ALREADY FACED THIS ISSUE!
Rmk: it may be a subbtle bug. Before I found a systematic reproduction with the drum roll, I first thought it was a random bug, an that only some events were lost from time to time... Nobody here "randomly" loose some midi events ?

For those who think that "it looks like a newbie error", don't trust my number of posts (I just don't like forums) and rather have a look to this snaps done while looping on a drum roll:

Snap1: input midi events (all on channel 1)
[img]http://img123.**************/img123/4379/image1jo7.jpg[/img]

Snap2: output midi events of the 1st instance of faulty JS. Normally, all non-filtered events should be remmapped to channel 12.
=> the "lost" events are those visible on channel 1. As you can see, there're MORE lost events than processed ones.
[img]http://img412.**************/img412/1775/image2vn3.jpg[/img]

Snap3: output midi events of the 2st instance of faulty JS. This is a STRICT copy of the 1st instance (copy/paste FX).
As you can see, there's no more lost events (all are on ch 12): the events missed by the first instance are processed by the second one.
[img]http://img389.**************/img389/6010/image3hn9.jpg[/img]

If it was a programming error, the same events on ch1 would also be present at the output of the 2nd JS.

[EDIT]Removed, here was written some HUGE bullshit[/EDIT]

Can somebody confirm that behavior ?
(so that I can move on another reliable solution: for some reasons I'll not detail, the "double instance" work around is not acceptable and has worse impacts than missed events).

To be transfered tothe bug thread ?


ELAPSED TIME BETWEEN 2 MIDI EVENTS:
for those interested: cpt+=1 in the @sample part, storing the cpt value on the focused event, then, when a new event is received, elapsed_time=floor(((cpt-lastCpt)/srate) *1000); (where srate is a system var))

[AkeW]

I'm not sure, but I think this happens to me in my cymbal choke plugin. When the choke comes really fast after the note - the choke does not work. Probably because it never gets converted by my JS...

If I move the choke to happen a bit later - the choke works!

[AkeW]

I've investigated this a bit further. The problem I think is that the choke from my drum brain is 4 (or 5?) CC messages that appear in reaper with the exact same timecode.

Could this be due to the device being an USB virtual midi port instead of a real midi device? (I could try it with real midi though, since it has that output as well...)

I've also noticed that editing the midi offset in reapers editor seems a bit buggy - If i enter .77 at the end of the code, it sometimes becomes .76 after pressing enter.

[Jeffos]

Thanks for the feedback, AkeW!
Nothing new: I moved to another solution: custom C++ app -> midiYoke -> reaper with exactly the same algotrythm (including the 'unique' array) everything is working fine...

y'a un truc pas clair....