-
Notifications
You must be signed in to change notification settings - Fork 122
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
Topic/atk fix speed of sound #319
Topic/atk fix speed of sound #319
Conversation
FIX: supercollider#317 Update AtkFoa.speedOfSound == AtkHoa.speedOfSound == 343.0 m/s
Update for release, along with further updates to conform ATK sc3-plugins READMe to ATK Quark README.
Hi @joslloand |
Ah, this is a nice idea! In practice, I don't think I'd want this to be an argument that the user supplies directly in the user interface to the UGen. Doing so could / would break existing code. Instead, it should happen "under the hood" by setting Ok, having had a little look, the changes to do so would have to happen in both AtkUGens.cpp here in sc3-plugins, and in ATK.sc found in the quark. @joshpar, what do you think of this? And.. I just noticed that, as we actually need normalized frequency in the calculation: sc3-plugins/source/ATK/AtkUGens.cpp Lines 1949 to 1950 in 444cef3
Could be updated to:
I'm feeling this would make things more simple, and clearer. |
Yes, that's what I was thinking |
Good to know! The slight danger is that users will need to make sure to update both sc3-plugins and the atk-sc3 quark. That shouldn't be a problem if the change is communicated in the update announcement.. @joshpar, how does this sound to you. (I'll add @mtmccrea, too.) |
yeah @joslloand - I think that's a cool idea |
Ok, great! As for actually making it happen, I'm super rusty on the plugin side and would need to have some guidance on getting it right. In particular, once the speed of sound is set, it should be constant for the life of the UGen instantiation. I.e., it should be a fixed value that isn't modulate-able. @dyfer, I may reach out over email for a quick chat on the matter.... |
I can help as well if needed. Cheers!
… On Jul 27, 2021, at 12:32, Joseph Anderson ***@***.***> wrote:
yeah @joslloand <https://github.com/joslloand> - I think that's a cool idea
Ok, great!
As for actually making it happen, I'm super rusty on the plugin side and would need to have some guidance on getting it right.
In particular, once the speed of sound is set, it should be constant for the life of the UGen instantiation. I.e., it should be a fixed value that isn't modulate-able.
@dyfer <https://github.com/dyfer>, I may reach out over email for a quick chat on the matter....
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANHLALDVOQLR4FNPU2IZLTZ4CTFANCNFSM5BCYNZBA>.
|
Ok, great! I think I see what needs to happen... so that's fine. (However, since, I haven't tried to compile sc3-plugins on this machine in so long, I'm expecting a task!) |
affects: FoaNFC, FoaProximity NOTE: interface requires update to atk-sc3 quark ATK: speed of sound as init value
Ok, I've just made an updated push. The updated atk-sc3 quark branch is here: https://github.com/ambisonictoolkit/atk-sc3/tree/refactor-foa-nfc-proximity What I haven't done is tried to compile... so testing is required.... |
@joslloand we've just added automated building with github actions. If you rebase your PR on the current |
Thanks @dyfer! I didn't realize this... very convenient. (I ended up doing a merge rather than a rebase.) I've done some tests, and both HOA and FOA are now matched. Hurrah! So the updates are working now. ... so... I think we're ready for a merge |
@dyfer, @joshpar just picking this up again after some time away.... ... I think this is all ready to go. The tests (matching NFE results w/ the HOA implementation) have passed. So, I think this is ready to be closed and merged. |
@joshpar would you also agree that it is ready to go? |
@telephon I had a conversation with @dyfer yesterday, regarding backwards compatibility and resulting behavior given installs with mismatched quark and sc3-plugins. I have a possible solution I'll be testing today that should resolve performance issues if the class and plugin aren't aligned. (I expect a simple check on inputs will do the job.) If this does work, I'll go ahead and push this change... then I think we'll really be ready to go! |
affects: FoaNFC, FoaProximity NOTE: resolves previously required update to atk-sc3 quark If AtkFoa.speedOfSound is not passed, plugins use 333.0 mps, which is equivalent to coeffiencts used in previous sc3-plugins (<=v3.11.1)
Ok, here's the fix: 8bc45e4 Which meets these cases, testing cases for matching and unmatching quark AND plugins:
@joshpar, @dyfer, @telephon, so now I'm thinking we're ready to go with this. (Finally!) |
SHIP IT!
… On Sep 16, 2021, at 17:14, Marcin Pączkowski ***@***.***> wrote:
This seems to work as advertised, thank you!
@joshpar <https://github.com/joshpar> @telephon <https://github.com/telephon> is it OK to leave that merge commit in?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANHLAG43567L2YNH5MCVDUCKB7RANCNFSM5BCYNZBA>.
|
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.
Shippin' it
@joshpar is your change request satisfied? :) |
Thanks everyone! |
PR to address #317 (& ATK Quark 104)
Additional updates to ATK sc3-plugins README to align with ATK Quark README & in preparation for sc3-plugins v3.12.0 release.