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
Many fields containing time and position information (as well as start / end offsets) have been discovered already. They are exposed to as-is, no conversions from the uint32or whatever to a human readable representation consisting of beats, bars and divisions.
😎 What I already know
Time / position fields are most of the time dependant on the PPQ of the project (and not the tempo!),
For example, at a PPQ of 96, a length of 96 means that the entity's musical length is a quarter or, a beat or, 1/4th of a bar.
Using the PPQ as a runtime dependency for calculation is already possible, but the part where problems begin are time signatures.
⏰ What's with time signatures?
The above calculations work only for a time signature of 4/4. If while measuring the length, a time signature occurs in the playlist or in a pattern, the formula probably changes and not accounting for this would mean all further calculations will go wrong.
👀 Where to look for?
The FLP format is very close to MIDI in terms of many things. I think, the MIDI format already has something of this kind and I would like to get insight from somebody who has experience in MIDI or how musical timings are represented in DAWs.
Achieving this would be a great feat 🥳, its one of those features that would make PyFLP 10x more useful that its right now.
The text was updated successfully, but these errors were encountered:
demberto
changed the title
✨ Converting binary representations of musical timings to human readable ones
✨ Interpreting encoded musical times
Dec 10, 2022
Many fields containing time and position information (as well as start / end offsets) have been discovered already. They are exposed to as-is, no conversions from the
uint32
or whatever to a human readable representation consisting of beats, bars and divisions.😎 What I already know
Time / position fields are most of the time dependant on the PPQ of the project (and not the tempo!),
Using the PPQ as a runtime dependency for calculation is already possible, but the part where problems begin are time signatures.
⏰ What's with time signatures?
The above calculations work only for a time signature of 4/4. If while measuring the length, a time signature occurs in the playlist or in a pattern, the formula probably changes and not accounting for this would mean all further calculations will go wrong.
👀 Where to look for?
The FLP format is very close to MIDI in terms of many things. I think, the MIDI format already has something of this kind and I would like to get insight from somebody who has experience in MIDI or how musical timings are represented in DAWs.
Achieving this would be a great feat 🥳, its one of those features that would make PyFLP 10x more useful that its right now.
The text was updated successfully, but these errors were encountered: