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
Good point, that's actually something I kept in my head for later when working on miditoolkit.
I think keeping all the controls in Track.controls is better, and it's simpler to write only the controls. Track.pedals should just be for users to use.
Now avoid any pedal-control inconsistency, we could ensure that each pedal stored has its Control equivalent. This shouldn't be a problem when parsing as the pedals are deduced from the controls. But then, if a user is adding a pedal to any Track.pedals, we could add the equivalent control in Track.controls. And also each time a control is added to Tracks.controls, if its a pedal we could just add the pedal to Track.pedals.
Setting Track.pedals as a property with setters / deleters would achieve this purpose.
It would make sure that the user can use/add any pedals without duplication, even for let's say two identical pedals (that may append even if it's not natural).
It would be challenging to achieve this encapsulation if common operations in list is allowed for pedal like slice.
Also, in this case, we may need to store two references of the corresponding control change in pedal, and a reference of pedal in control change event.
Pedals are actually stored twice, in
controls
andpedals
of atrack
If someone change
controls
orpedals
, there might be some inconsistence between them.Now, in symusic, we just write all the
controls
back and ingoring the pedal events inpedals
.Well, a solution is to remove all the corresponding control events in
controls
, but I'm not sure if it is a good design.What's your opinion @Natooz ?
The text was updated successfully, but these errors were encountered: