From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
1) If you have alot of fast wide-ranging wild automation on a Decay knob, the decay time will bounce around, making the env sound like it is being re-triggered, since the volume goes up & down with the decay. If one looks at the Code, this would seem obvious. However, for myself & perhaps others, the expected behavior would be that on a note-on, all env parameters would be"frozen" for that note-on, so little quirks like this won't happen. Would require moving the variable setup into stage(0) it seems? Or for the Code for a check to pass parameter changes only for new processes.
2) If you want the release to be played, the Envelope Control "Hold" has to be True. Might have been mentioned before on the forum, but dang is it confusing! Maybe needs more documentation &/or better labeling?
trogluddite ·
Interesting point.
I would say that this falls into the category of 'user expectations' rather than a bug per se...
The 'freeze envelope parameters' behaviour seems to have been the standard for a long time, ever since synths went digital - I suspect that historically that's simply been to save the CPU cycles of continously re-calculating the envelope parameters.
OTOH on a genuine analogue synth (which is what most SM users would be trying to emulate), the envelope times are almost always dynamic. This is the kind that I prefer, simply because it's what I got used to on my old analogue synths.
I think the best solution would be to offer both 'flavours' of envelope, so that it is the designer's choice to have the response that they prefer.
infuzion ·
trogluddite wrote: I would say that this falls into the category of 'user expectations' rather than a bug per se...
I think the best solution would be to offer both 'flavours' of envelope, so that it is the designer's choice to have the response that they prefer.
I'd say it is more of an 'user expectation' as well, though it should at least be documented, which I'm doing now.
A configuration for "Hold parameter at note-on" might be the best choice, just like "Smooth retrig".
Tzarls ·
The solution could be in stage(0) - if only we could store "external" values into code(0)´s variables....
infuzion ·
Tzarls wrote: The solution could be in stage(0) - if only we could store "external" values into code(0)´s variables....
Yea, that was my first thought. /cry 😝
MegaHurtz ·
you could run em thru like this..
stage (0)
{out=in;}
infuzion ·
MegaHurtz wrote: you could run em thru like this..
stage (0)
{out=in;}
Tzarls & I were just talking about that; we do not think stage(0) can read the green inputs. I've heard stage(0) is unable to modify data coming in. If you want to disprove us please do; I'm not 100% certain.
trogluddite ·
Reading green wouldn't be a problem...
Not quite sure I get what you mean about 'modifying the data' - you would always have to store values in a variable to pass them to stage(1). If you changed an output during stage(0), it would just get overwritten by any changes in stage(1) anyway.
Reading data from mono or poly that only execute in stage(1) could be problematic in some situations, because of the stage execution order - not really sure how likely you'd be to need that.
Re-triggering of stolen voices might be a problem for envelopes though - as I understand it, there's no stage(0) executed when a voice is stolen after max. poly is reached.
Tzarls ·
I just remembred having a problem related to this some time ago... the problem was that I was using a certain envelope in blue and the ADSR vales were being read inside stage(0)... so the env only updated it´s values when I forced a recompile.
I made this simple schematic, seems like it should work, but I don´t have a keyboard controller at hand right now. Let me know if this actually does what you need.
trogluddite ·
Ha ha. 😀
We must have tuned into each others thoughts!
Tzarls ·
Must be one of those global-warming effects. 🙂
So this actually works?
trogluddite ·
Seems to...
I've used it before to pass 'default' values into stage(0) for initialising buffers, or just for setting constants that I want to tinker with without having to edit the code every time.
As far as I can tell so far, you can do anything with stage(0) that you can with the other stages, as long as you are careful with the order that things execute. The only time I've had problems is with SMs stock primitives - they mostly seem to execute in stage 1/2, so if you feed their outputs into a stage(0) code, the value isn't there yet when stage(0) tries to read it. If you're writing your own code, you can usually get around that by making sure that you always include a stage(0) routine to initialise everything.
infuzion ·
Thanks guys; demos seem to work!
trogluddite wrote: The only time I've had problems is with SMs stock primitives - they mostly seem to execute in stage 1/2, so if you feed their outputs into a stage(0) code, the value isn't there yet when stage(0) tries to read it. If you're writing your own code, you can usually get around that by making sure that you always include a stage(0) routine to initialize everything.
Maybe since other Code in the same OSM has stage(1) & not stage(0) in them?
MegaHurtz ·
trogluddite ·
infuzion wrote: Maybe since other Code in the same OSM has stage(1) & not stage(0) in them?
Yeah, I guess not many of them would need it. You have to be careful with some of them (delays perticularly) because they also use stage(2) - seem to remember a thread somewhere about the single-sample delay appearing to be a 2-sample delay when fed into stage(1) because of this.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker