You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: