Open briandorsey opened 5 months ago
When implementing smpl
I ended up removing the counter fields from the inner struct entirely, automatically using and calculating them via binrw
annotations instead.
Think about this a bit more and decide if that makes more sense everywhere (reducing chances of counters going out of sync with Vecs) or if we really want to model the underlying fields? And if we do want to model them... maybe it makes more sense to use a method alias which looks up the current length of the Vec instead, anyway?
And maybe the "modeling" of the underlying fields is improved by including them in the iteration of fields for display (.iter() implementations), but just calculating that value there as well. Then we never have to store something which could get out of date.
plst, cue, smpl & fmt (WAVEFORMATEX)