Poly Midi bug
===========
been playing with ppg wavemapper quite a bit lately, and despite a few early issues, its actually really good, and quite low cpu for a voice per channel synth 🙂
however, I’ve just tripped up on a bug in the poly midi (i think both midi and au agents affected).
if you make the agent use poly channel and then create pressure and yaw mappings to a CC, Â but ‘forget’ to change in that mapping from ‘global’ to ‘per note’ you will get hung notes (very quickly!)
on reflection, I suspect (but not checked yet) its probably pressure
= global, midi channel = poly is the issue.
note: i tested channel = poly breath = global and that works fine, hence the suspicion that ‘pressure’ is being dealt with perhaps differently!?
ive tested in current 2.1 (from github) and 2.0.74 and exists in both.
I confirmed not only by hearing , but also recording all notes in ableton and can see it is eigenD not the plugin.
could someone else test, just to confirm.
p.s. I think if channel=poly, then key inputs, yaw/roll/pressure probably should be defaulting to per note, its usually what you want.
Eigenharp Google+ Community Archives 
So what’s going on when this manifests itself, the note off messages aren’t sent?
LikeLike
exactly – the note offs are not being sent.
just confirmed, it is channel=poly, pressure=global , mapped to CC 2.
LikeLike
can you check with MIDI monitor too?
LikeLike
sure, I’m testing it now 🙂
LikeLike
sent to your email.
Interesting… it looks like EigenD has stopped allocating notes as well
In my example, the note was hung on channel 2, then it allowed another 4 notes, then no more notes were sent…Â
(id assumed it was the AU running out of polyphony when I heard this before, but MM is showing EigenD is not sending more data)
then after ‘a while’ eigenD is able to send more notes… and this gets more ‘interesting’
I never receive a corresponding note off that channel 2 note on  BUT i do get a new note on/off pair for channel 2 (i waited 5 minutes)
i’ll send you the later one too by email
LikeLike
Ok, I’ll try having a quick look later today to see if something jumps out. Feels like a channel allocation bug.
LikeLike
ok, it maybe related to midi buffer, as log has the following:
eigend: : read too far in past: read=1504400 write=1504914 size=512
ive also noticed increase decimination helps, <5ms its easy to reproduce, above seems less likely.
Note: its worth remembering this does not happen at all if pressure=per note, so above may or may not be a red herring.
LikeLike
(my point above, is we don’t know if the midi_output error is the cause, or symptom)
Im going to go test with a factory setup too, ‘just in case’
LikeLike
ok, the experimental basic midi also does it, so not my setup 🙂
(i.e. clear matrix, just set pressure to cc1, and main channel = poly, and reduce global and pressure decimation =0)
LikeLike
ok, ive a theory on what the issue is:
it is the midi buffer
because when set to global we are sending 16x more data for every pressure event. so i think the midi buffer overflowsÂ
I think this may also have another side effect, that the voice count starts increasing (think correlator here), which i think is why we get the pausing, these eventually ‘auto release,’ somehow, and then it all works again. Im not sure if this due to the midi buffer overflow some how blocking, or ifs just caused by the extra load of sending out so much dataÂ
EDIT, ok so the buffer is actually an EigenD data queue, so not sure its overrun.
but appears buffer is 512 bytes, but its expecting 514 bytes of data… not sure where the 512 comes from , a default somewhere?
LikeLike
ok, today had eigenD hanging, even when set correctlyÂ
i.e. channel is set to ‘per note’
not as quickly though, so may be unrelated, I’ve a stack dump which i’ll email you Geert Bevin as it looks reasonably clear… odd thing is it appears to have the main thread locked in a mouse event.. .but i was no where near mouse when it started hanging… i was playing the harp at the time with both hands 🙂
LikeLike
Sorry that it took a while, but I finally got time to look into this. I couldn’t reproduce any crashes, but I could reproduce hanging notes a couple of times, not anymore though. It does seem that it could be related to the MIDI buffer. Maybe try with this patch and see if it helps?
diff –git a/lib_midi/src/midi_from_belcanto.cpp b/lib_midi/src/midi_from_belcanto.cpp
index df6fb46..dc0a09e 100755
— a/lib_midi/src/midi_from_belcanto.cpp
+++ b/lib_midi/src/midi_from_belcanto.cpp
@@-670,7 +670,7 @@ namespace midi
Â
   midi_from_belcanto_t::impl_t::impl_t(const piw::cookie_t &cookie, piw::clockdomain_ctl_t *clk_domain):
     root_t(0), piw::event_data_source_real_t(piw::pathnull(0)),
– Â Â Â Â upstream_clk_(0), downstream_clk_(0), output_buffer_(1,4*PIW_DATAQUEUE_SIZE_NORM),
+ Â Â Â Â upstream_clk_(0), downstream_clk_(0), output_buffer_(1, 16*PIW_DATAQUEUE_SIZE_NORM),
     clk_state_(CLKSTATE_IDLE), clk_domain_(clk_domain),
     channel_(1), poly_(false), omni_(false), time_(0ULL),
     resend_current_(midi::resend_current_t::method(this,&midi_from_belcanto_t::impl_t::dummy)),
LikeLike