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.

Sign up for GitHub

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

Jump to bottom

Constant Frequency (as opposed to constant note) pitch shift #865

Closed
baconpaul opened this issue May 5, 2019 · 14 comments
Closed

Constant Frequency (as opposed to constant note) pitch shift #865

baconpaul opened this issue May 5, 2019 · 14 comments
Labels
Feature Request New feature request
Milestone
1.6.2

Comments

@baconpaul
Copy link
Collaborator

Again with Don Lewis on #surge-irc

He wanted to have OSC2 4hz off from OSC1 but a constant 4HZ. So A4 is 444 and A5 is 884 not 888.

The pitch adjustment right now is in note space. So If you set a 1% pitch drift you get 444 and 884

So really a 'master tuning in frequency space' control. This amounts to using the note table I whack around in the .scl code with an offset per osc.
@bit-101010
Copy link

There's a workaround for now; you can set the Unison Spread to be an absolute detune in Hz, just right click on it. It would mean that both oscillators must have the same waveform and the detune happens in both directions from the center frequency (maybe?).

If you have .kbm support you'll need to make a master pitch reference anyway, so then it's just a matter of exposing that to the GUI.

@lewisizer
Copy link

Thank you for your response! Is it possible to send the two oscillators output to separate audio channels?
I tried to setup dual instances and mute the opposite oscillators, but to no avail.

Thanks again for your insights!

@bit-101010
Copy link

with absolute detune for the unison setting, the "wide" filter configuration will pan the unison voice across the stereo field, so in theory for a unison count of two one of them will pan hard left and one hard right.

if you are doing things by seperate oscillators, try the L-R filter configuration and send one oscillator to each filter.

These two should get you one tuning per stereo channel.

@lewisizer
Copy link

Hi Paul, just wanted to say again thank you for your advice and guidance to find a solution to my challenge with 4 Hz constant detune between two oscillators.
I've been using Surge AU on four tracks. Is there a way to in unison mode to play only the top note if you happen to play a chord? Thanks for your kind assistance!

@baconpaul baconpaul added the Feature Request New feature request label Jun 19, 2019
@baconpaul baconpaul added this to the 1.6.n milestone Jun 19, 2019
@baconpaul baconpaul modified the milestones: 1.6.n, 1.6.2 Jul 5, 2019
@baconpaul
Copy link
Collaborator Author

OK so taking a look at this issue again and these are more "notes to myself before I go to bed so I remember my research" not "actionable items for either you guys - sorry!

Parameter.h has a method can_be_absolute which allows the Absolute trigger. This is how, on the uni-spread, you can set the spread in absolute hz (do RMB/Absolute then drag goes to hz rather than notes). This would actually work for us now if uni-1 took the spread as a detune but of course it doesn't. Parameter.cpp makes it clear that osc_spread is the only parameter that supports absolute.

So I think the trick here is

1: Make the "pitch" slider support absolute. That's actually really easy (you just add it to the enumeration in can_be_absolute in Parameter.cpp). That should right away get you to seeing hz rather than notes I think

2: This is the hard part. Make the oscillators read that value rather than interpreting the slider as midi note in absolute mode. I think this is well identified code (I mean, it is basically the same code I just played around with for the tuning changes but a bit different) but probably will require me to visit each of the oscillators

  1. Test.

So there go you. I think I'll turn to this one next in the nightlies, mostly because opening up the patch format is a big and ugly change which I am putting off, and the vocoder-as-standalone is a fun bit of code but requires a bit more concentrated time, which I will probably have end of month.

@baconpaul
Copy link
Collaborator Author

OK so just a further note before I'm done for the day so I remember

SurgeVoice is where all the note construction happens. Happens in 7 places (look for pitch.extend_range). It passes a midi note into the oscillators which then call storage->note_to_pitch (which is what the alternative tuning mechanism whacks).

So there's a couple of choices I have

  1. The "clean" choice which "breaks everything". To Oscillator::process_block add an pair of arguments bool hasAbsoluteFrequencyShift, float absoluteFrequencyShift then make all the note_to_pitch conversions take that into account. But since there is note_to_pitch_inv also that's tricky and it is a lot of change

  2. The "less clean but more workable" version. When I have a constant frequency shift I convert that back into note shift space before I call down. In standard tuning mode this isn't that hard but in alternate tuning mode it is ... complicated. And could potentially be expensive. But this is fewer places to change. Basically all those extend_range spots get replaced with an inline function (that should really happen anyway right?) that if you are in absolute mode does something clever to be determined. Most likely that clever thing would be way less efficient in non-standard tunings with absolute pitch shifts but that is a fairly rare case where I'm willing to pay some price

So I think I'll do the second. But like I said still just research notes to myself so I don't forget em.

baconpaul added a commit to baconpaul/surge that referenced this issue Jul 13, 2019
@baconpaul
Absolute Pitch Shift
b039ee6 
Addressing surge-synthesizer#865, we want to be able to shift pitch by either a
relative (note space) frequency or an absolute (frequency space)
frequency amount.

This change is incomplete, and edit this when rebasing but here we do
the following

1. Make the pitch parameter allow absolute for pitch_semi_7b
2. Make sure the absolute property saves and restores
3. In SurgeVoice plumb through a note-setter function which
   will allow us to find the note equivalent to the absolute
   shift from a base

We do not in this change find that note equivalent. So absolute
right now is same as pitch = 0 in an oscillator.
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 14, 2019
@baconpaul
Absolute Pitch Shift
27278bd 
Addressing surge-synthesizer#865, we want to be able to shift pitch by either a
relative (note space) frequency or an absolute (frequency space)
frequency amount.

The implementation works as follows:

1. Make the pitch parameter allow absolute for pitch_semi_7b
2. Make sure the absolute property saves and restores
3. In SurgeVoice plumb through a note-setter function which
   will allow us to find the note equivalent to the absolute
   shift from a base
4. An implementation of constant pitch shift to note which
   uses the current tuning table to interpolate in absolute
   mode and just adds in normal mode
@baconpaul baconpaul mentioned this issue Jul 14, 2019
Merged
baconpaul added a commit that referenced this issue Jul 14, 2019
@baconpaul
Absolute Pitch Shift (#957)
db2cc16 
Addressing #865, we want to be able to shift pitch by either a
relative (note space) frequency or an absolute (frequency space)
frequency amount.

The implementation works as follows:

1. Make the pitch parameter allow absolute for pitch_semi_7b
2. Make sure the absolute property saves and restores
3. In SurgeVoice plumb through a note-setter function which
   will allow us to find the note equivalent to the absolute
   shift from a base
4. An implementation of constant pitch shift to note which
   uses the current tuning table to interpolate in absolute
   mode and just adds in normal mode
@baconpaul
Copy link
Collaborator Author

@lewisizer hi! I just implemented this constant frequency request. Here's how to do it

  1. Grab the surge nightly any time after about 9pm eastern time July 13. (It is starting to build now - usually takes half an hour or so). You can grab the nightly from https://surge-synthesizer.github.io/#downloads).

  2. Open up the init patch. You see a standard oscillator.

  3. On 'Pitch' right mouse and choose 'absolute'. Now the pitch shift will be in Hz rather than in notes.

  4. If you want a bigger range than the one provided (+/- 70hz is the default) right mouse and choose 'extended'. That will give you +/- 800hz or so.

I'm going to leave this issue open until I hear from you or @bit-101010 that you've confirmed it behaves as you expect. It was slightly tricky but I did test it against a tuner and indeed, middle c + 10hz gives me 271hz etc... and c an octave up goes from 522 to 532 or what not, as opposed to 522 to 542 which a relative retune would yield.

Thanks!

@baconpaul
Copy link
Collaborator Author

The nightly now contains this feature. Let me know if it works for you! Thanks

@lewisizer
Copy link

lewisizer commented Jul 14, 2019 via email

@baconpaul
Copy link
Collaborator Author

Safe travels and absolutely no rush!

@baconpaul
Copy link
Collaborator Author

Again this is more of a note to self. I implemented this in a way that it works with non-standard tuning pitch tables which is great. But for standard tuning I can use an analytic since I know the pitch formula to figure out the calculation. But that means I need to know we are in standard tuning. So let me link this with #828 so i don’t forget.

It won’t change the user-side implementation of the feature, so still appreciate a test whenever anyone has time, but might make it a couple of hundred instructions faster in standard tuning mode. (Although it also might not; I would have to do a logarithm to figure out the analytic so I may also not do this).

@baconpaul
Copy link
Collaborator Author

OK with last nights tuning fix, I am now convinced that this is correct in all situations, so I'm going to close this issue to help me manage GitHub issues as we approach 1.6.2. @lewisizer all that means is "it doesn't show up on my list requiring work". If you find bugs in the feature we can reopen the issue easily.

@lewisizer
Copy link

lewisizer commented Sep 13, 2019 via email

@baconpaul
Copy link
Collaborator Author

Hi Don

I renamed the plugin in the latest release - it is now called “SurgeEffectsBank”. From this stack trace it looks like you are still using the old “surge-fx” one. So I think you need to uninstall that and install the newplugin

To uninstall from a terminal you can just “sudo rm -rf /Library/Audio/Plug-Ins/Components/surge-fx.component”

Then grab a new version of the nightly installer from surge-synthesizer.github.io and you should see a version called “SurgeEffectsBank” which will have the fix to this problem and several other installed.

I’m sorry I should have made the rename clearer. But the name “surge-fx” conflicted with a couple of important use cases on Windows so we kind of had to bite the bullet.

Let me know if you have trouble getting the new version installed

Best

@bobobo199733 bobobo199733 mentioned this issue Mar 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Request New feature request
Projects
None yet
Milestone
1.6.2
Development

No branches or pull requests
3 participants
@bit-101010 @lewisizer @baconpaul