Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More Song properties C++ified #69

wants to merge 4 commits into from


Copy link

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.

Signed-off-by: Stefan Westerfeld <>
Signed-off-by: Stefan Westerfeld <>
Signed-off-by: Stefan Westerfeld <>
Signed-off-by: Stefan Westerfeld <>
Copy link

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)

@tim-janik tim-janik closed this in dc84f2c Aug 30, 2018
@swesterfeld swesterfeld deleted the pport-song-merge branch September 1, 2018 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants