-
Notifications
You must be signed in to change notification settings - Fork 173
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
allow pan element in .h2pattern and drumkit #1249
allow pan element in .h2pattern and drumkit #1249
Conversation
while keeping backward compatibility. Now, either `pan` or both `pan_L` and `pan_R` must be present.
I guess you meant [0;0.5] for note_pan (L/R) and [0;1] for instrument_pan (L/R) (they were gains for the channels originally) I remember that. If you use the But since there is a division If we skip I don't know... |
Other reflections: |
I think the truncation is okay because it just occurs once and the resolution of the pan values set by the GUI is not bigger than O(10^{-2}). For the failing tests I had to increase the resolution of the output to see what was going on. It just affects the last digit of the float.
Yes. This PR should be the basis on which we can deprecate the
Forward compatibility is a promise almost no FLOSS project gives (including ourselves) and I think this is OK since one has free access to the latest version. Also, as soon as a pattern or drumkit file is not validated it will be loaded by the legacy routines instead. So, you can have a basic usage in older versions.
The old ranges won't be touched. But I would vote for handling both the |
I agree. [-1,1] makes an elegant symmetry (and the current formula works for that range). Ok for all! |
<xsd:element name="pan_R" type="h2:psfloat" default="1.0"/> | ||
<xsd:choice minOccurs="0" maxOccurs="1"> | ||
<xsd:sequence> | ||
<xsd:element name="pan_L" type="h2:psfloat" default="0.5"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a special reason why here the default value has changed from 1.0 to 0.5?
I know that both the default pairs (0.5, 0.5) and (1,1) are converted into pan = 0, but maybe there's something I misunderstand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, those default values are redundant at best and misleading everywhere else. The XSD files are just used for validation and in this context the default values can be viewed was comments.
It's a good idea to have make them consistent with the default values used in the C++ code but IMHO an even better idea to get rid off them entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out we use 0.5 as default value anyway.
@oddtime would you like to rewrite the pan handling (loading/storing/class members)? |
Ok! |
while keeping backward compatibility.
Now, either
pan
or bothpan_L
andpan_R
must be present.@oddtime The pan parameters in the patterns are defined within [-0.5,0.5] while the one in the instruments are within [-1.0,1.0]. I guess you already know this and intend to streamline this one too, right?