Open kulpajj opened 6 years ago
Hi @kulpajj, the way o.harmonics.shape~ works is that there an internal phase for the root frequency which is used to create the harmonics (i.e. higher harmonics are a multiplication of the root frequency phase).
I made it so you could define your own custom harmonic series, but since they are locked to the root phase, if you quickly change the overtone ratios it will create discontinuities in the waveforms and click.
Most likely the simplest way to crossfade between harmonic and inharmonic waveforms at sample rate would be to have two o.harmonics.shape~s or sinusoids~ and cross fade between them.
Alternatively, you could do use the harmonic envelop shaping variable in o.harmonics.shape~ to emphasize the ratios at the beginning or the end of the list. Positive shape values emphasize the values at the beginning and negative values emphasize ratios at the end of the list.
But to have a lot of control over many frequencies, usually people use control rate messages. In which case sinusoids~ might be a good choice.
hope that helps! rama
Thanks for this Rama. This leads nicely into the polyphony and delegation unit of m158.
On Mon, Nov 6, 2017 at 5:38 AM rama gottfried notifications@github.com wrote:
Hi @kulpajj https://github.com/kulpajj, the way o.harmonics.shape~ works is that there an internal phase for the root frequency which is used to create the harmonics (i.e. higher harmonics are a multiplication of the root frequency phase).
I made it so you could define your own custom harmonic series, but since they are locked to the root phase, if you quickly change the overtone ratios it will create discontinuities in the waveforms and click.
Most likely the simplest way to crossfade between harmonic and inharmonic waveforms at sample rate would be to have two o.harmonics.shapes or sinusoids and cross fade between them.
Alternatively, you could do use the harmonic envelop shaping variable in o.harmonics.shape~ to emphasize the ratios at the beginning or the end of the list. Positive shape values emphasize the values at the beginning and negative values emphasize ratios at the end of the list.
But to have a lot of control over many frequencies, usually people use control rate messages. In which case sinusoids~ might be a good choice.
hope that helps! rama
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CNMAT/Music-and-Computing/issues/86#issuecomment-342150845, or mute the thread https://github.com/notifications/unsubscribe-auth/AWhttZ8Md47kyR4dQ52Hifk1wonHg8KLks5szwvZgaJpZM4P_bub .
Thanks for this Rama. This leads nicely into the polyphony and delegation unit of m158.
On Thu, Nov 9, 2017 at 7:02 AM Jon Kulpa kulpajj@gmail.com wrote:
Thanks for this Rama. This leads nicely into the polyphony and delegation unit of m158.
On Mon, Nov 6, 2017 at 5:38 AM rama gottfried notifications@github.com wrote:
Hi @kulpajj https://github.com/kulpajj, the way o.harmonics.shape~ works is that there an internal phase for the root frequency which is used to create the harmonics (i.e. higher harmonics are a multiplication of the root frequency phase).
I made it so you could define your own custom harmonic series, but since they are locked to the root phase, if you quickly change the overtone ratios it will create discontinuities in the waveforms and click.
Most likely the simplest way to crossfade between harmonic and inharmonic waveforms at sample rate would be to have two o.harmonics.shapes or sinusoids and cross fade between them.
Alternatively, you could do use the harmonic envelop shaping variable in o.harmonics.shape~ to emphasize the ratios at the beginning or the end of the list. Positive shape values emphasize the values at the beginning and negative values emphasize ratios at the end of the list.
But to have a lot of control over many frequencies, usually people use control rate messages. In which case sinusoids~ might be a good choice.
hope that helps! rama
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CNMAT/Music-and-Computing/issues/86#issuecomment-342150845, or mute the thread https://github.com/notifications/unsubscribe-auth/AWhttZ8Md47kyR4dQ52Hifk1wonHg8KLks5szwvZgaJpZM4P_bub .
@ramagottfried My students had a lab on (in)harmonicity that had to consider a movement from harmonic to inharmonic sounds in any order or stacking them together...but there had to be an evolution. Several of them used the OSC namespace /ratios [ ratios list in here ] and send in different bundles over time to shape this very powerful musical parameter.
...and now I am a convert to your signal rate data model. =-) . Because for o.harmonics.shape~, /ratios is not a signal rate inlet, but rather an odot list, the students who were trying to evolve /ratios over time featured a plethora of clicks every time a new bundle came in to change this parameter.
Can anything be done about this? I know /ratios is a list, and I am not sure how we could have a list at signal rate. I fixed one of their patches by having the amplitude go down briefly each time she changed the /ratios. But her patch was moving at a slow enough phase rate to pull this trick off. But the other students were doing wild things with random engines changing /ratios at rapid rates and there were clicks everywhere. =-O
(this is somewhat related to our thread on OSC /name_space for various objects vs signal rate numbers and inlets. But this was specific to this object and this parameter.)
Thanks!