Thanks, fixed that one too.
JT contributions
Gavin
#12
Not sure if your Distortion object will be based around distortion style effects or not, but I do know when guitarists are sourcing custom made distortion effects, the variety of clipping diodes and possible placement of only 2 - one in each direction, or 3 - two in one direction and one in the other, or 4 - two in each direction, can give quite a large choice as factors to help generate ones unique personal effect. And very useful from the boost effect, to the overdrive, then onto distortion.
Is this something that can be simulated within the math ?
I have been trying to copy the sound of all these three (boost, overdrive, distortion) in fact it is fundamental if I want to use the Axo with my music. I have in pedal varieties covering these 3 effects, as a novice not quite sure how to get to the target, but I expect the more options available, the more variety in the effect can be achieved.
Blindsmyth
#13
Just saw the link/audio object. Looks like a really great Idea. How should I link two boards in order to try it?
Sputnki
#14
The granular object sounds awesome, will it be expanded (maybe with options for grain size, number, panning, pitch) or is it just sold as is and open to exploitation?
In this last case i'd suggest to write some commentary in the code, which now looks really hardcore for basic users (mainly because of the pointers and STM functions)
johannes
#15
I posted a breakdown of fuzz/overdrive/distortion modelling here
Proof-of-concept firmware is developed and made public in the "spilink" branch on github, but I haven't written a setup guide, and the firmware is also missing diagnostic reporting that 'd help setting it up. Currently having trouble to allocate time to finish this effort. Stay tuned...
haha "sold" 
It's a working draft, that's why it is listed as under development, and is a patch containing an embedded object rather than a library object. Configurable grain size and number are certainly missing. The code currently exploits dependencies between grain size, number and audio buffer size to maximize performance:
At 128 grains of 2048 samples, and all grain phases distributed evenly, exactly one single grain needs a new random position per audio buffer. But in a similar fashion, a grain duration of 1024, 4096 or 8192 samples can be done, with respectively 2 position updates per buffer, one position update per two buffers, or one position update per four buffers.
Variable pitch is not implemented, and 'd increase the dsp load significantly. The left and right outputs each contain 64 hard-panned grains, adding random panning 'd increase the dsp load too.
In the big picture, I got a bit fascinated by tonewheel/drawbar approaches: rather than doing voice allocation, just running a full set of oscillators. Cross-breeding tonewheels with granular would require a massive amount of grains, when limiting to 64 tonewheels and two grains per tonewheel this requires... 128 simultaneous grains. This proofs this is possible with room to spare to increase to 80 or 96 tonewheels... The ability to access a grain table of 8MB means, this table could be split into 64 segments, each containing source material for every semitone. That's 1.333 seconds per semitone. Or the table could contain a single glissando of 64 semitones in 83.3 seconds, avoiding the need for pitching grains. Even with only two grains per tonewheel, a single key can mix tonewheels with the drawbars, I think the result could be rich and expressive, and totally alias-free.
The overlapping grain offsets could also be synchronized to pitch rather than random offsets.
Or perhaps skipping the tonewheel idea, a polyphonic synth could be made that uses 32 grains per voice (from a table containing segments for every semitone), so 4 voices can be played, and reducing the number of grains per voice progressively when more than 4 keys are playing...
toneburst
#16
I'm going to sound unkind here, but I have to say, a tonewheel organ sounds about the least sonically interesting use for a hardcore grain-playback engine.
I can see with more controls (like those suggested above), it could be a great MI Clouds-style texture generator/beat masher/vocal mangler (would love to see that!).
That said, I admit I am biased against organ sounds, unless they're going through a really nice Leslie cabinet, so others may disagree.
a|x
Gavin
#17
Have just finished testing the "dist/class a", and I believe as a bass player who likes very noisy and messy sounds, this is a massive improvement towards the idea of a quality Boost/overdrive/distortion goal. Maybe its because I am a noob at all this DSP stuff, but when the object is active and in play, it makes me feel like there is a lot of meat on the bone when looking for sound to better represent the dynamics of play.
In fact I am even happy just connecting it to one gain object when I normally have 2.
For the extreme test (limited to desk speaker), I split the audio into two lines, each with 2 gains each, one before and aft the "class a" - on max, and band pass each, one set high, the other low, and the sound got full and dirty, a lot better than I was expecting. Almost sounded like it wanted a mind of its own. I know this type of sound is not everyone's taste, but it was certainly enough to get me excited considering the struggles I have been having to create this. 
Does this mean there is a Class B & C on the way.. !
Gavin
#18
Further to my comments above, I have been thinking, what would be a good mod to this object, would be an adjustable level input, because I would like to have the drive level be adjustable in line with the envelope level, so at quieter levels it will be turned down automatically, or any other drive level formulae that may work.
Blindsmyth
#19
Ok I try to be patient the idea sounds really promising. May I ask how the connection between the boards would be achieved?
johannes
#20
Update from the granular front, thee new objects and corresponding help patches:
* jt/granular/grainverb
* jt/granular/graindelay
* jt/granular/graintable
The number of simultaneous grains, length of the grains, and window shape is now configureable.
The code is also more documented, and I found a way around stealing the DMA channel from the GPIO serial port, by using the DMA2D engine instead. The old granular128 patch conflicted with use of the serial port on gpio, this issue is now fixed.
Blindsmyth
#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
#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...
jaffasplaffa
#24
- 1 for the grainverb. Really liking that one
But like blindsmith says, pitch would be a really great addition.
johannes
#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
#26
Could this be adapted into a 'sine bank', driven by data from an FFT, for spectral resynthesis effects?
a|x
mtyas
#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
#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?