JT contributions

Blindsmyth 2016-10-03 21:40:45 UTC #21

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?

johannes 2016-10-03 22:14:58 UTC #22

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...

Blindsmyth 2016-10-03 22:18:09 UTC #23

Ok cool. This already quite impressive

jaffasplaffa 2016-10-04 05:36:37 UTC #24

1 for the grainverb. Really liking that one

But like blindsmith says, pitch would be a really great addition.

johannes 2016-10-06 16:22:24 UTC #25

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.

toneburst 2016-10-06 17:29:34 UTC #26

Could this be adapted into a 'sine bank', driven by data from an FFT, for spectral resynthesis effects?

a|x

mtyas 2016-10-06 17:49:12 UTC #27

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

johannes 2016-10-07 15:33:23 UTC #28

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?

lokki 2016-10-08 21:08:28 UTC #29

@johannes that would be called sostenuto. usually midi cc 66

toneburst 2016-10-11 07:52:11 UTC #30

That sounds cool!

a|x

toneburst 2016-10-11 07:56:57 UTC #31

@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

johannes 2016-10-11 19:56:19 UTC #32

I expect problems integrating large block-size FFT operations, that does not blend well with the small block-size (and low latency) Axoloti uses.

johannes 2016-12-23 19:08:33 UTC #33

added sustain pedal support to jt/drawbars/switched

johannes 2016-12-23 20:29:33 UTC #34

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!

SmashedTransistors 2016-12-25 14:03:26 UTC #35

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 ?

jaffasplaffa 2017-01-16 18:22:32 UTC #36

@johannes

I just want to compliment the Class A drive object. This is really great. Thanks