Really digging the grainverb and grain table!
Got pretty much in to the realm of paul stretch with the table.
Is there any way of also pitching the grains?
JT contributions
Pitching/transposing the grains is currently not implemented, my aim was to maximize the number of grains.
Sorry, don't expect me to develop a pitching version soon, I have other things in the development pipeline that will keep me busy for a while... If I extend it further, first efforts would go towards pitch-synchronizing grains...
- 1 for the grainverb. Really liking that one
But like blindsmith says, pitch would be a really great addition.
An update from the tonewheel and divider-organ front:
- jt/tonewheels/pwm dpw
- jt/tonewheels/saw cheap phasing
- jt/tonewheels/saw cheap
- jt/tonewheels/saw dpw phasing
- jt/tonewheels/saw dpw
- jt/tonewheels/sine
- jt/tonewheels/tri dpw phasing
- jt/tonewheels/tri dpw
- jt/tuning/adjustable
- jt/tuning/equal
- jt/tuning/hammond
- jt/tuning/just
- jt/drawbars/pulse
- jt/drawbars/scope
- jt/drawbars/switched
- jt/env/table/ar
- jt/env/table/r
Simple demo patch in
* jt/patches/tonewheel chainsaw organ.axp
Multi panned sawtooth demo patch in
* jt/patches/tonewheel chainsaw organ.axp
Specific to these organs is that they do not use voice allocation, but use a constant running set of chromatic oscillators, the sound output is a mix (depending on keys pressed and drawbar settings) of these fixed oscillators. The overtones (as adjusted via the drawbars, not the harmonics from the tonewheel oscillator waveform) are not natural overtones, but tap from the same oscillator set, so they have the same phase.
The assumption that a set of oscillators is a chromatic set, with fixed 2:1 octave frequency ratios allows to optimize quite a bit of the oscillator algorithms.
Trying to separate tonewheel and divider-oscillator based organs into flexible construction pieces, leads to a set of objects for tonewheels with different waveforms, drawbar objects to manipulate the harmonic composition/registers, table-envelope and tuning objects. So different oscillators, envelopes, drawbars and tunings can be combined.
The drawbar objects in fact expose a 128-element table containing the amplitudes, the tuning objects expose a 12-element table with the linear frequencies of 1 octave.
Besides (loosely) modelling Vox continental, Hammond B3, Arp Solina, Eminent... style organs, I believe there is also potential for non-organ type applications via other generative or arpeggiating constructions that generate a tuning and chromatic amplitude table.
Feedback on the "decomposition" of tonewheel/divider oscillator type organs into objects is welcome.
For me, it shows me that a "wired" connection for tuning and amplitude table would be more intuitive rather than a named object reference.
Could this be adapted into a 'sine bank', driven by data from an FFT, for spectral resynthesis effects?
a|x
Having a great time with these modules, thanks very much.
I know it's not much of an organ thing, but do you think it could respond to sustain information (CC64), like the factory midi keys objects ?
It would be quite useful for playing a load of notes at the same time (I've only 10 fingers, and my arm is not precise enough).
Anyway thanks a lot, I'm playing along with modulated tunings as well as modulated tonewheels and it's sounding amazing
A chromatic sine synthesis bank, that's jt/tonewheels/sine
but semitone resolution is too rough for real spectral resynthesis.
FFT outputs linear frequency, that does not match well with the auditory preception. FFT requires long analysis windows to get good frequency resolution at low frequencies, while at that point the time resolution at high frequencies becomes insufficient, and latency gets high.
A chromatic sine bank with amplitude at a certain frame rate suffers from the opposite, excessive time resolution at low frequencies versus insufficient time resolution at high frequencies.
That lead to the domain of multi-rate signal processing, and multi-complementary filter banks... It 'd be cool to have a "multirate spectrum" wire type between objects, but there are many different design parameters that make it hard to partition multirate processing into separate objects.
I have a draft chromatic analysis filter bank + RMS envelope follower in the pipeline, its output can be multiplied with the output from a drawbar object, to produce a sort of non-conventional vocoder (no carrier filterbank, but "carrier oscillators"). But it is not as efficient yet as I would like it to be. Sorry for teasing...
sure it is possible to add, I think there are also two distinctly different sustain methods: sustain every key that was pressed when and after engaging sustain, or sustaining only the keys that were pressed when engaging the sustain pedal. I forgot the name for this.
I'd like to invite the community to develop the sustain functions, that 'd allow me to spent more time on the more obscure parts of development. Anyone?
@johannes have you looked at the FFT code for the Mutable Instruments Clouds module (here, I think https://github.com/pichenettes/eurorack/tree/master/clouds/dsp/pvoc ), by any chance?
a|x
I expect problems integrating large block-size FFT operations, that does not blend well with the small block-size (and low latency) Axoloti uses.
A new experiment in electric piano modelling added:
axoloti-contrib/patches/jt/devel/rhodos.axp
It's based on a resonant filter, the resonance is switched between "damped" and less "damped", and excited with a pulse when a key is hit. This filter resonates at the the fundamental frequency of the note, does not generate harmonics.
To spice it with harmonics, the sine output of the resonator with a constant value added (bias2) is fed into a ring modulator. The 2nd input of the ring modulator is fed with a mix of the cosine output of the resonator (parameter drive2), and the output of the ring modulator (parameter drive1) after some filtering (high pass filter parameter hpfc), and a constant value (bias1).
When the 2nd ring modulator input clips, this causes extra energy dissipation in the resonator, this was added to be able to have stronger but shorter "gnarwl" in the attack.
The ring modulator feedback idea derives quite a bit from the "dist/class a" distortion above.
This was developed through experimentation. The parameters are not very easy to control, and some combinations can cause high frequency oscillations.
72 notes polyphony at 68% load...
If you find other sweet spots of parameter settings or code variations, please share!
Hi and merry christmas @johannes
It's really impressive,
I'm having a look at your code.
As far as I understand, you use a state variable filter with notch, band, low and high outputs. Which ones correspond to "sine" and "cosine" outputs ?
I really like that sound, thank you! with a good monitor or headphones I hear some glitchy noises, but I dont know if it was intended, would work as a chainsaw (the dsp shows 94%)..
I just had a listen to the "rhodos" patch (due to https://sebiik.github.io/community.axoloti.com.backup/u/shellfishand reviving the thread) and like it a lot. So i'm just going to go ahead and ask a silly question: Would anyone know how to `MPE-dify' this algorithm, in particular to allow polyphonic pitch bend and velocity (more modulation possibilities would be even better, of course)?
Cheers!