search

tim-janik / beast

Beast - Music Synthesizer and Composer
GNU Lesser General Public License v2.1
84 stars 12 forks source link

More Song properties C++ified #69

Closed swesterfeld closed 6 years ago

swesterfeld commented 6 years ago

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 STANDARDRDONLY - 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.

tim-janik commented 6 years ago

Thanks a lot Stefan. I'm not sure that "TPQN" is any better than "Ticks" for users at the UI, at least I'm not aware of another sequencer that has TPQN labels... I think in either case users will need the tooltip to decipher what the property is about.

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. Please keep that in mind for ported properties and watch out if we shouldn't add extra guards, like:

denominator = CLAMP (input, 0, 256)