helgoboss / reaper-rs

Rust bindings for the REAPER C++ API
MIT License
80 stars 8 forks source link

Medium-level API: Add PPQ functions #62

Open Levitanus opened 1 year ago

Levitanus commented 1 year ago

midi_get_ppq_pos_start_of_measure midi_get_ppq_pos_end_of_measure midi_get_proj_qn_from_ppq_pos midi_get_ppq_pos_from_proj_qn midi_get_proj_time_from_ppq_pos midi_get_ppq_pos_from_proj_time

every PPQ function is unsafe, because of take requirement

Levitanus commented 1 year ago

Now should be OK

Levitanus commented 1 year ago

I'm thinking on PositionInPpq representation. Basically, in take, PPQ is just normal u32. And, working with midi events, I usually need to convert it to the u32. It just returns from REAPER as f64.

It also blocks deriving of Ord, Eq, Hash. Changing underlying type to u32?

helgoboss commented 1 year ago

I'm thinking on PositionInPpq representation. Basically, in take, PPQ is just normal u32. And, working with midi events, I usually need to convert it to the u32. It just returns from REAPER as f64.

It also blocks deriving of Ord, Eq, Hash. Changing underlying type to u32?

The question is whether REAPER supports and/or returns decimal PPQ values or is planning to do so in a potential future. If yes, we should definitely stay with f64. In such cases, I usually ask Justin by dropping him an email. Could you do that? If not or if that takes too long, I would prefer to take the safe route ... just use f64.

We can't derive Ord, Eq, Hash for that newtype with f64 but we can implement it. AFAIK, the most important reason why f64 doesn't implement those is that it can have special values such as NaN and so on. But we explicitly exclude that for the newtype, so we can provide an implementation that makes sense.

Levitanus commented 1 year ago

Hmm, I never told to Justin)) If I try to ask some questions in cocos forum, it looks for me like an dead frost...

The question is whether REAPER supports and/or returns decimal PPQ values or is planning to do so in a potential future.

Reaper MIDI source is almost just a MIDI file of the standard midi specification. And PPQ is, generally, an summarized offset value. When MIDI take should be disconnected from the timeline, it happens not by multiplying values inside the pure midi data, but with modifying of the take tempo.

So, I think, the probability of fail is very low.


I've changed also UsageScope to MainThreadOnly

helgoboss commented 1 year ago

Hmm, I never told to Justin)) If I try to ask some questions in cocos forum, it looks for me like an dead frost...

I asked him an he responded that internally it can be fractional but on the API surface it's essentially always an integer. So I guess we can go with an integer.