Old 12-08-2008, 03:36 AM   #1
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default Lost midi events, time elapsed between 2 midi events ?

[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!

Last edited by Jeffos; 01-31-2010 at 08:52 AM.
Jeffos is offline   Reply With Quote
Old 12-09-2008, 03:53 AM   #2
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default LOST MIDI EVENTS ISSUE

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))

Last edited by Jeffos; 01-31-2010 at 08:56 AM. Reason: bullshit
Jeffos is offline   Reply With Quote
Old 12-17-2008, 03:02 PM   #3
AkeW
Human being with feelings
 
Join Date: Dec 2008
Posts: 39
Default

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 is offline   Reply With Quote
Old 12-21-2008, 01:32 PM   #4
AkeW
Human being with feelings
 
Join Date: Dec 2008
Posts: 39
Default

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.
AkeW is offline   Reply With Quote
Old 01-06-2009, 03:12 AM   #5
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

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....
Jeffos is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:02 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.