Odd ev->time.frames make B.Shapr crash in Ardour

[sjaehn]

Dividing the control atom port to a control and a midi port resulted in a crash in Ardour. It turned out that the plugin received events with ev->time.frames out of the expected range.

ev->time.frames usually ranges between 0 and n_samples. For time_Position events in the control port usually ev->time.frames == 0. For GUI->DSP events (like notify_shapeEvent) ev->time.frames == n_samples .

https://github.com/sjaehn/BShapr/blob/master/src/BShapr.cpp#L397

.

But the midi port also receives time_Position, but with ev->time.frames > n_samples.

https://github.com/sjaehn/BShapr/blob/master/src/BShapr.cpp#L433

The problem is fixed by skipping time_Position events from midi port.

[x42]

I highly recommend to only use a single Atom input, but if you must use two, the first one should be the one to receive MIDI input.

The 2nd port likely contains garbage (ardour connects it to a silent/scratch buffer).

[sjaehn]

Thank you. Your answer is the one I expected / was afraid of. I think port 2 is indeed the problem. At least ev->time.frames contains garbage. Roll back and try to get both, MIDI and time_Position in one atom input.

[SpotlightKid]

Carla also doesn't handle two atom ports correctly: falkTX/Carla#915

[sjaehn]

Done in 9ec78e7