Thorn: Dmitry Sches' new synth!

[] Peter:H []

Thumbs up, Dimitri...great work!

[murnau]

Lame. demo restrictions make it unusable. WHEN WILL DEVELOPERS LEARN ETC, ETC..

The demo restriction is totally fair! Demo is very usable!

What kind of restriction do you prefer? A light beep every 2nd day?

[Taron]

Hello guys, and here another 1.0.4 update goes. You could download it at the website or by these links:

For Windows: http://dmitrysches.com/files/download/Thorn_Win_104.zip
For Mac: http://dmitrysches.com/files/download/Thorn_Mac_104.zip 

Here is the change log:

- Added MSEG/STEPPER OneShot mode
- Now Thorn remembers recent folder when importing WAV-files
- Fixed Windows 32 bit stability issues
- Adjusted polyphony stealing scheme, now Thorn tries to not steal sustained voices if possible
- Adjusted LFO syncing when Arp is on
- Added "Disable MIDI Output" option to solve MIDI recording issue in Sonar
- Fixed multiple minor GUI/processing issues
- Adjusted user manual

Just few comments on this update. I wanted to add CPU idle mode for it, but it turned out that it's a quite hard task. But I'll be exploring it further, because it would be cool to save more CPU for sure.

More updates to come... Again, thank you for feedback, reports and support!

Awww, man, you ROCK!
Hey, I'm quite aware of some of the challenges regarding the idle situation, especially since you have the effects.
Looks to me like the Reverb is the biggest culprit, actually. I wonder, if you could be so bold to check for a denormal threshold, possibly giving it a last ramp to avoid the audiophiles from flipping out, though that would defeat the purpose, I imagine. Feels to me that it is a denormal thing, though, because the cpu stays up REALLY high for virtually nothing. That's a denormal classic.
A wonderful KVRler here called "aciddose" gave me a fantastic tip once to use this line in init:
_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
That's meant to avoid the denormal and seems to do a mighty fine job.

THANK YOU, for sure! Downloading right away!

[Taron]

Is it possible for you to have a look at the envelopes for modulation again, because of the attack problem!?

A drastic example goes like this:
- OSC 1: make a sine in the first cell and a sine one octave higher in the last. All in between are morphs.
- AMP ENV: attack=0% | decay = 0% | sustain = 100% | release = 0% (or whatever)
- Modulation: AMP ENV - ... - 100% OSC1 Pos

When you play this (regardless of declick, by the way), you'll get a blip from position 0 before it goes up to 100% position. But that shouldn't be! If attack is 0%, there literally shouldn't be one moment on position 0%. I know, you know this, and I must imagine that there are reasons, but this is currently for me likely the most uncomfortable frustration, since there's no healthy way around it.

Any chance you can take a look?

Other than that, everything runs beautifully. No complaints about the update for sure!

[Examigan]

Here is a preset I made while getting used to Thorn's many controls
=)
https://soundcloud.com/examigan/thorn-preset-time

[toonertik]

Is it possible for you to have a look at the envelopes for modulation again, because of the attack problem!?

A drastic example goes like this:
- OSC 1: make a sine in the first cell and a sine one octave higher in the last. All in between are morphs.
- AMP ENV: attack=0% | decay = 0% | sustain = 100% | release = 0% (or whatever)
- Modulation: AMP ENV - ... - 100% OSC1 Pos

When you play this (regardless of declick, by the way), you'll get a blip from position 0 before it goes up to 100% position. But that shouldn't be! If attack is 0%, there literally shouldn't be one moment on position 0%. I know, you know this, and I must imagine that there are reasons, but this is currently for me likely the most uncomfortable frustration, since there's no healthy way around it.

Very good point and it explains why I have had "unexpected" behaviour when using env.
Because I often use a lot of modulation, I have not spent time to de-construct exactly where the problem has arisen, though this does go some ways to explain.
My solution so far has been to use DAW auto/envs or re-work the patch.

[Sound Author]

Is it possible for you to have a look at the envelopes for modulation again, because of the attack problem!?

A drastic example goes like this:
- OSC 1: make a sine in the first cell and a sine one octave higher in the last. All in between are morphs.
- AMP ENV: attack=0% | decay = 0% | sustain = 100% | release = 0% (or whatever)
- Modulation: AMP ENV - ... - 100% OSC1 Pos

When you play this (regardless of declick, by the way), you'll get a blip from position 0 before it goes up to 100% position. But that shouldn't be! If attack is 0%, there literally shouldn't be one moment on position 0%. I know, you know this, and I must imagine that there are reasons, but this is currently for me likely the most uncomfortable frustration, since there's no healthy way around it.

Any chance you can take a look?

Other than that, everything runs beautifully. No complaints about the update for sure!

^ Looks like a very fast envelope modulation of the "POS" knob. I asked Dmitry about this some time ago and he explained that (depending on your sample rate) there's about 10 milliseconds of "morphing delay" since FFT cannot be computed in real time. Sadly, this rules out "snappy" modulations of the Spectrum Table. It's a forgivable shortcoming, since it's a processing limitation, not so much a design flaw.

[Sound Author]

delete

[Taron]

^ Looks like a very fast envelope modulation of the "POS" knob. I asked Dmitry about this some time ago and he explained that there is about 10 milliseconds of "morphing delay" since FFT cannot be computed in real time. Sadly, this rules out "snappy" modulations of the Spectrum Table. It's a forgivable shortcoming, since it's a processing limitation, not so much a design flaw.

Thanks for the info, first of all!

But it's not the problem! If you invert the process, setting the position to 100% and use an envelope with slow attack and set modulation to be -100%, then it starts from there, which is the same that should happen at an attack of 0% with modulation at 100%. So, this is not the problem. Even if there was a switch that would understand attack 0% means start at the given modulation amount rather than ramping there, it would do the trick. If an attack of 1% would then deal with the 10 millisecs, everything would be fine. Just that 0% attack should be 100% what ever the modulation amount is at the start!

[Sound Author]

^ Looks like a very fast envelope modulation of the "POS" knob. I asked Dmitry about this some time ago and he explained that there is about 10 milliseconds of "morphing delay" since FFT cannot be computed in real time. Sadly, this rules out "snappy" modulations of the Spectrum Table. It's a forgivable shortcoming, since it's a processing limitation, not so much a design flaw.

Thanks for the info, first of all!

But it's not the problem! If you invert the process, setting the position to 100% and use an envelope with slow attack and set modulation to be -100%, then it starts from there, which is the same that should happen at an attack of 0% with modulation at 100%. So, this is not the problem. Even if there was a switch that would understand attack 0% means start at the given modulation amount rather than ramping there, it would do the trick. If an attack of 1% would then deal with the 10 millisecs, everything would be fine. Just that 0% attack should be 100% what ever the modulation amount is at the start!

Well, as you pointed out, the Spectrum Table is ramping from 0-100% instead of just starting at 100%, so my guess is that the morphing delay is causing that blip. But you make a valid point. If there was a way for envelopes to tell the Spectrum Table not to even bother with the attack stage when attack is set to 0%, then yeah, the Spectrum Table might smoothly morph from the decay stage, and if you did the same with the decay stage (when set to 0%) then the Spectrum Table would just line up with the sustain stage and wait for the release.

Of course, I'm no developer. It's all easier said than done.

[D Midas]

Anyone know how many presets are in thorn? I couldn't find it listed on the website

[sqigls]

about 375 factory patches so far i think

[Taron]

^ Looks like a very fast envelope modulation of the "POS" knob. I asked Dmitry about this some time ago and he explained that there is about 10 milliseconds of "morphing delay" since FFT cannot be computed in real time. Sadly, this rules out "snappy" modulations of the Spectrum Table. It's a forgivable shortcoming, since it's a processing limitation, not so much a design flaw.

Thanks for the info, first of all!

But it's not the problem! If you invert the process, setting the position to 100% and use an envelope with slow attack and set modulation to be -100%, then it starts from there, which is the same that should happen at an attack of 0% with modulation at 100%. So, this is not the problem. Even if there was a switch that would understand attack 0% means start at the given modulation amount rather than ramping there, it would do the trick. If an attack of 1% would then deal with the 10 millisecs, everything would be fine. Just that 0% attack should be 100% what ever the modulation amount is at the start!

Well, as you pointed out, the Spectrum Table is ramping from 0-100% instead of just starting at 100%, so my guess is that the morphing delay is causing that blip. But you make a valid point. If there was a way for envelopes to tell the Spectrum Table not to even bother with the attack stage when attack is set to 0%, then yeah, the Spectrum Table might smoothly morph from the decay stage, and if you did the same with the decay stage (when set to 0%) then the Spectrum Table would just line up with the sustain stage and wait for the release.

Of course, I'm no developer. It's all easier said than done.

Absolutely. I am a developer and sometimes it's not the fix that's the problem, but the guaranteed change this will have on existing presets that have 0% Attack. Though, my guess is that it will not hurt. Rather that suddenly those presets sound like they were originally intended.

I'm assuming the problem is the universal nature of how something like spectrum tables responds to the modulation stage. I figure, it acts in such generic way to the modulation values that it does not (have to) know what the routine does that feeds the modulation, but only know the range of values it gets. It always initializes to the originally set value and then receives the incoming value and deals with it from there.
This, of course, is bold, I think. Probably nice and easy at first but I would put a tiny routine into the init part of each modulation that goes: compute me the first value with the given range (parameter value + (modulation value-parameter value)* modulator) and init with that! Though, I don't know the code, of course. ...could really just be a matter of changing the order of events right after midi (or in midi) to evaluate the modulation before starting off the processing.

ALSO this would solve that exact same trouble with all other modulation sources, because it happens, of course, with everything, I believe... ENV, LFO, MSEG, etc...simply because of the order of the process. I'm not sure why it is that way, but apparently the chain of events currently has modulation in a spot that doesn't feature into the init of a sound's parameters. Once this was addressed, everything would act far more predictable or as expected. Would be fantastic!

[Chris-S]

AMP ENV KEY scaling:
concerning the manual this should shorten the envelope times for higher notes.
But I see no effect, when setting this to 100%.

SOLVED. It just takes some time to overtake the new setting. Have to play 10-15 notes and then the new envelope timing is fully active.

Thanks for the 1.0.4. The graphical glitches in the Harmonic Filter display are gone.

[toonertik]

compute me the first value with the given range (parameter value + (modulation value-parameter value)* modulator) and init with that! Though, I don't know the code, of course.

ALSO this would solve that exact same trouble with all other modulation sources, because it happens, of course, with everything, I believe... ENV, LFO, MSEG, etc...simply because of the order of the process. I'm not sure why it is that way, but apparently the chain of events currently has modulation in a spot that doesn't feature into the init of a sound's parameters. Once this was addressed, everything would act far more predictable or as expected. Would be fantastic!

I think this MIGHT be what I am expecting.. certainly sounds about right!