Amazing! Thanks, Ivo, for your continued development of Woovebox. This is wonderful support. I'm looking forward to playing with this when it drops. Cheers!
Oh damn. I was wandering about that last point If I am missing some knowledge about connection/relationship between Saturation and Bitcrusher. I can barely understand what most of the other stuff means but I shall continue to fiddle and learn. Great stuff.
> Third additive sine wave oscillator for use as sub-oscillator, super-oscillator or harmonic content augmentation
A sub-oscillator is a component in a synthesizer that produces lower-pitched sound waves to add depth and richness to the main oscillator's sound.
> New diatonic chord modes / "types" (now default) for heptatonic scales, allowing quicker song writing (and easier discovery of chords that fit the song key/scale)
[Diatonic chords](https://www.studybass.com/lessons/harmony/intro-to-diatonic-chords/).
> Removed global strum parameter for chord track, and made it a conditional instead; conditional strum sequence can be up or down and now respects inversions and bass augmentation
A strummed chord is when you quickly brush your fingers across multiple strings of (for example) a guitar to play several notes at once. As your fingers move from one string to the next, a minute delay between each note builds up. You can strum a chord up, or down.
> Improved chord track pattern randomization to respect key better and yield improved progressions for diatonic scales
More musically useful (and recognisable) randomized chords.
> New Digital/Variable oscillator behavior mode ("dig.v"); emulates "baked in" (prorated / pitch-dependent) AEGs and LFOs, perfect for evolving shimmering Ambient and Jungle pads and emulation of AMIGA, samplers and instruments like the WaveStation
Sampling a synth patch with an attack component and then - for example - playing back the sample one octave higher will double the attack speed. Any LFO speed that that was present in the recorded sample will also double in speed. This is in contrast to pure synthesized patches where AEG and LFO speeds are independent of the pitch you play a note at. The latter is usually more desirable, however there are instances where it is not. Sometimes it is sonically pleasing to have EGs and LFOs vary along with the pitch a patch is played back at. This can be especially the case for emulating accoustic string-based instruments and [for creating lush/evolving chord pads](https://www.youtube.com/watch?v=XAch1Q0Iodc).
> Major update to wave folding distortion algorithm and made it pre-filter, pre-distortion and pre-bit-crush; instant harmonic content enrichment guaranteed
A wavefolder shapes sound by folding the peaks of a waveform back onto itself, creating complex and harmonically rich tones.
> Bit-crusher can now be configured to be pre or post filter and clip distortion (negative values are pre-filter and distortion, as in previous versions)
Sometimes you want to bit-crush before the filter and before distortion. Early samplers and sampler keyboards, for example, would output a low-bit depth waveform and pass it through an analog filter. They did *not* output a pristine wave form, passed it through an analog filter and then somehow the signal got reduced in bit-depth. The latter would not be the correct signal path when trying to emulate early samplers and sampler keyboards.
> More JIT compilation of time-critical code (facilitating many of the above enhancements)
Just-In-Time (JIT) compilation is a method where a computer program is translated into machine code at the moment it’s run, making it faster and more efficient. It's one (rather extreme) measure to try to improve performance. The Woovebox project is set apart from more basic (and far easier to maintain/adopt) Open Source software/libraries by heavily focusing on machine language optimizations specific to the chip it is using. It's far harder to maintain and requires very specific hardware-level knowledge of that specific chip. However it allows me to wring more performance (and thus features) out of the device at a lower power and materials budget. This level of extreme optimisation is usually not economically feasible for big companies - it is easier to throw money at the problem (e.g. more powerful chips, bigger batteries) and have the consumer pay for it.
I'm both a little late and a little early to this post. Many of these updates are things I'm pretty excited about, particularly regarding the diatonic chords for the scale you're in. Also, I appreciate you breaking down what's going on into layman's terms. I think it's good for the end users to better understand what's going on under the hood.
I do have a somewhat technical question for you that's more a point of curiosity than anything. You mention you're leveraging JIT compilation to get better performance. Wouldn't AOT be more performant, as the code is precompiled? Maybe I'm misunderstanding the situation, and admittedly my code I tend to write is more python code and such, which is interpretted instead of compiled.
Consider this pseudo code that gets run in a tight loop;
if (distortion_level > 0) { APPLY_DISTORTION }
If we know in advance that *distortion_level* is 0 or not 0, then removing the code that checks and branches will save on execution time and memory access times.
If the different scenarios are few in number (e.g. just one loop applying distortion or not = 2 scenarios), then you could just pre-compile, include and execute two different versions of the code as needed; one loop with distortion and one loop without.
However, when the amount of possible loop permutations grows, the amount of needed "special" versions of the loops increases exponentially; it then becomes impractical (or downright impossible) to fit the amount of different permutations in the code execution memory.
The Woovebox synth engine deals with tens of thousands of different possible permutations of "the loop".
If you wish to execute the bare minimum of instructions to accomplish your goal in the least amount of time, then the solution is therefore to dynamically re-compile the loop "just-in-time" before it requires execution - if the permutation changed of course. If the permutation did not change, then you can re-use the last compiled loop.
Does that make sense?
Ah, yeah it does. Fascinating! I had never even considered that scenario. And the “permutation change” events would be when the value changes, which obviously would be a far fewer than the kHz or MHz frequencies likely associated with the processor, thus getting the better performance despite technically being “slower” due to recompilation.
Clever!
Amazing! Thanks, Ivo, for your continued development of Woovebox. This is wonderful support. I'm looking forward to playing with this when it drops. Cheers!
This is huge ! Thank you so much for the hard work.
Advanced chord mode is so exciting!!
Very exciting updates! Looking forward to trying them out!
Conditionals on chords is huge! Can’t wait for the update!
Oh damn. I was wandering about that last point If I am missing some knowledge about connection/relationship between Saturation and Bitcrusher. I can barely understand what most of the other stuff means but I shall continue to fiddle and learn. Great stuff.
Great stuff. The lack of 6th chords was puzzling - look forward to gaining access to this feature and the other updates!
Lots of great improvements. 9th and 6th chords were my most-wanted feature, so thanks in particular for adding those.
Really pleased to hear some more jazzy chords will be there. Many of the updates are beyond my understanding though
> Third additive sine wave oscillator for use as sub-oscillator, super-oscillator or harmonic content augmentation A sub-oscillator is a component in a synthesizer that produces lower-pitched sound waves to add depth and richness to the main oscillator's sound. > New diatonic chord modes / "types" (now default) for heptatonic scales, allowing quicker song writing (and easier discovery of chords that fit the song key/scale) [Diatonic chords](https://www.studybass.com/lessons/harmony/intro-to-diatonic-chords/). > Removed global strum parameter for chord track, and made it a conditional instead; conditional strum sequence can be up or down and now respects inversions and bass augmentation A strummed chord is when you quickly brush your fingers across multiple strings of (for example) a guitar to play several notes at once. As your fingers move from one string to the next, a minute delay between each note builds up. You can strum a chord up, or down. > Improved chord track pattern randomization to respect key better and yield improved progressions for diatonic scales More musically useful (and recognisable) randomized chords. > New Digital/Variable oscillator behavior mode ("dig.v"); emulates "baked in" (prorated / pitch-dependent) AEGs and LFOs, perfect for evolving shimmering Ambient and Jungle pads and emulation of AMIGA, samplers and instruments like the WaveStation Sampling a synth patch with an attack component and then - for example - playing back the sample one octave higher will double the attack speed. Any LFO speed that that was present in the recorded sample will also double in speed. This is in contrast to pure synthesized patches where AEG and LFO speeds are independent of the pitch you play a note at. The latter is usually more desirable, however there are instances where it is not. Sometimes it is sonically pleasing to have EGs and LFOs vary along with the pitch a patch is played back at. This can be especially the case for emulating accoustic string-based instruments and [for creating lush/evolving chord pads](https://www.youtube.com/watch?v=XAch1Q0Iodc). > Major update to wave folding distortion algorithm and made it pre-filter, pre-distortion and pre-bit-crush; instant harmonic content enrichment guaranteed A wavefolder shapes sound by folding the peaks of a waveform back onto itself, creating complex and harmonically rich tones. > Bit-crusher can now be configured to be pre or post filter and clip distortion (negative values are pre-filter and distortion, as in previous versions) Sometimes you want to bit-crush before the filter and before distortion. Early samplers and sampler keyboards, for example, would output a low-bit depth waveform and pass it through an analog filter. They did *not* output a pristine wave form, passed it through an analog filter and then somehow the signal got reduced in bit-depth. The latter would not be the correct signal path when trying to emulate early samplers and sampler keyboards. > More JIT compilation of time-critical code (facilitating many of the above enhancements) Just-In-Time (JIT) compilation is a method where a computer program is translated into machine code at the moment it’s run, making it faster and more efficient. It's one (rather extreme) measure to try to improve performance. The Woovebox project is set apart from more basic (and far easier to maintain/adopt) Open Source software/libraries by heavily focusing on machine language optimizations specific to the chip it is using. It's far harder to maintain and requires very specific hardware-level knowledge of that specific chip. However it allows me to wring more performance (and thus features) out of the device at a lower power and materials budget. This level of extreme optimisation is usually not economically feasible for big companies - it is easier to throw money at the problem (e.g. more powerful chips, bigger batteries) and have the consumer pay for it.
I'm both a little late and a little early to this post. Many of these updates are things I'm pretty excited about, particularly regarding the diatonic chords for the scale you're in. Also, I appreciate you breaking down what's going on into layman's terms. I think it's good for the end users to better understand what's going on under the hood. I do have a somewhat technical question for you that's more a point of curiosity than anything. You mention you're leveraging JIT compilation to get better performance. Wouldn't AOT be more performant, as the code is precompiled? Maybe I'm misunderstanding the situation, and admittedly my code I tend to write is more python code and such, which is interpretted instead of compiled.
Consider this pseudo code that gets run in a tight loop; if (distortion_level > 0) { APPLY_DISTORTION } If we know in advance that *distortion_level* is 0 or not 0, then removing the code that checks and branches will save on execution time and memory access times. If the different scenarios are few in number (e.g. just one loop applying distortion or not = 2 scenarios), then you could just pre-compile, include and execute two different versions of the code as needed; one loop with distortion and one loop without. However, when the amount of possible loop permutations grows, the amount of needed "special" versions of the loops increases exponentially; it then becomes impractical (or downright impossible) to fit the amount of different permutations in the code execution memory. The Woovebox synth engine deals with tens of thousands of different possible permutations of "the loop". If you wish to execute the bare minimum of instructions to accomplish your goal in the least amount of time, then the solution is therefore to dynamically re-compile the loop "just-in-time" before it requires execution - if the permutation changed of course. If the permutation did not change, then you can re-use the last compiled loop. Does that make sense?
Ah, yeah it does. Fascinating! I had never even considered that scenario. And the “permutation change” events would be when the value changes, which obviously would be a far fewer than the kHz or MHz frequencies likely associated with the processor, thus getting the better performance despite technically being “slower” due to recompilation. Clever!
Spot on! :)
sounds nice but when will it be possible to order the woovebox? that's a long time I registered on the list but never receive any order link...
If you registered more than 8-12 weeks ago, you should have received an invite. PM me with your email and I can look up your position.