Open Yikai-Liao opened 3 weeks ago
The first question is what level of detail do you need? Probably all the channel messages
are in. Do you think anyone would want sysex
, real-time
or meta
messages?
You probably want to offer a single array view of the event stream so users don't have to reconstruct timing. But then you need a way to present different message object types. In tensormidi I used a super-set struct with multi-purpose fields, but that might not match the style of this project.
Since you have a pointer-indirection array already, maybe you could have it hold multiple backend buffers for different message types, but present a single pointer / object sequence.
Another option is using a single super-set struct in the c++ backend, but construct different python types based on message type which view the underlying struct.
After thinking it over, I feel like I still haven't figured out what the usage scenario is for adding message level Api? For me, it's more of a debug tool that can be used to analyze if there are any errors when saving midi. I think it's important to analyze the possible usage scenarios to figure out what pattern to design it as.
Oh I see. In my case, I'm trying to model noteon/noteoff events causally, so I can condition the generation on a live stream (e.g. from a digital instrument).
I'm preparing to add midi mesage level interface to symusic, but it's not very clear yet how the interface should be designed.
So I thought I'd ask your opinion here @wrongbad