Here is a C++ port for Song: tpqn / numerator / denominator
I renamed tpqn so that it says "TPQN" and not "Ticks" at the UI, because I think "Ticks" is a terrible name for that property, as it doesn't say what kind of ticks we have here.
I added STANDARD_RDONLY - we could also call this STANDARD RDONLY or STANDARD READONLY - I choose the name that SFI_* originally used.
I had to remove the computed defaults, since idl doesn't allow me to compute the default of a property. Previously the default values for properties were set in the Song implementation, so that the property defaults for bpm/numerator/... would always match the defaults from bse_song_timing_get_default().
However I think for Song, duplicating the defaults in bse_song_timing_get_default() and bseapi.idl is okay, because these probably will not change (often). One alternative would be to somehow allow the Song implementation to read the defaults that bseapi.idl defines, and so get rid of the duplication and make the idl file the canonic place.
The only Song property that remains is the post processing network, but since this has the type object, I am not able to port it now. If you have any preference for the next object properties to port, let me know.
The text was updated successfully, but these errors were encountered:
Signed-off-by: Stefan Westerfeld <firstname.lastname@example.org>
Thanks a lot Stefan.
There's one other thing I noticed during review. With the old GParamSpec + GObject based property API, the GObject machinery ensures that the GValue passed in to property setters complies with the GParamSpec value range. With our IDL API, nothing like that is enforced anymore. That means, an int32 property between 1-256 can now be set to 0 or -2^31 through the API. For a denominator to become 0 that could affect stability.
denominator = CLAMP (input, 0, 256)