That is really old (22nd Sept). Please update.
that was it. I updated a couple of times over wifi. I didn’t get any error messages, but apparently the update was not succesful.
ZynaddsubFX is not in this list, right? Is there a way to enforce a ADSR filter over an engine in the form of a plugin?
ZynAddSubFX is a feature-rich synth with a lot of parameters, including envelopes. Most of these parameters are hidden in its native UI.
Few are exposed in zynthian control views. It may be possible to expose more parameters but there comes a tipping point where there are too many parameters to make sensible sound-design decisions without a richer UI (like the native one). You could raise a CRQ to change which parameters are exposed. There could be an argument that simple sound design would benefit from a different set of parameters (maybe including envelope).
I don’t know if there is an audio + MIDI plugin that provides envelope. You would have to look. Using webconf’s search feature in the SOFTWARE->Engines page can help but be aware that the descriptions of many plugins has not been written yet.
1 Like
Thanks for your fast reply.
What is a CRQ?
Oops! That is a term used at my business where it means “Change Request” - I forgot I was in public and should talk normally!!! 
I should have said Feature request.
1 Like
Isn’t BShapr this kind of plugin?
I found vswell (GitHub - GModal/vSwell: vSwell is a volume envelope audio effect plugin. In LV2, VST, VST3 and CLAP formats.) too, but I think it’s not in the zynthian universe yet.
Regards
BShaper is not installed on Zynthian. If I install from Debian repository (and search for plugins then reboot) it installs but I can’t figure out how to make it do anything useful. I suspect that to act as an envelope would require some MIDI routing that is currently not done by zynthian.
vSwell does not compile. I have reported upstream.
[Edit] I got BShaper working but it is too resource hungry, loading 3 of the CPU at 100%. It is not suitable for use in zynthian.
Ok, I’ll give vSwell a try this weekend, if I find some time. Having some experience with hvcc, dpf and pd.
Regards
1 Like
I compiled vSwell. DPF plugin name was changed to lv2, instead of lv2_dsp, like in earlier versions.
In vSwell.json and vSwellST.json, you just have to change some lines of code:
...
"plugin_formats": [
"lv2"
]
...
I also recommend to use a virtual environment, not to get conflicts with the distribution’s pip installations.
Following the installation instructions leads to the lv2 plugin inside vSwell/bin/vSwell.lv2 resp. vSwellST/bin/vSwellST.lv2 folder.
Unfortunately it does not use the ADSR parameters to use it with the ADSR widget, but has it’s own special idea of envelope creation. But is nice and works.
Is it worth to have a “real” ADSR plugin? I think, I could program it, but discussions about triggering it should be made. And it could not be polyphonic.
Regards
I added your findings to the upstream bug report and managed to compile vSwell. I had to change the ttl to have type lv2:EnvelopePlugin (was lv2:InstrumentPlugin). I tried some manual MIDI routing but not sure that helped. The plugin does its own level based trigger detection then follows its envelope so feeding it with a hard attack signal will allow it to smooth the attack (quite like a limiter) and follow a user-defined decay curve. I am sceptical on the value or benefit such a plugin offers. There are other envelope shapers already installed in zynthian:
1 Like
that’s the one I found as well. The Attack time is pretty limited. On my keyboard I can get an attack of around 5 sec. That’s really nice if you want to add a nice swell to the strings.
which one?
Tested the new envelope widget with MiMid (dev branch) tonight.
First of all, it looks nice! Although it’s a bit surprising when it suddenly jumps out at you when you reach one of the envelope pages…
Regarding the sustain time parameter (called ‘fade’ in LV2 parlance, and ‘second decay’ in some cases), looking at it, the rendering is a bit off, though I’m not sure how to improve it completely. For instance, if the attack, decay or release times are set to 0, the corresponding segment is vertical as the corresponding phase is instantaneous (or as near as dammit). However, when the sustain time set at 0, the corresponding droop is rather gradual, going from the sustain level to about of half that, before the release phase starts in the graph (the ‘half of the sustain level’ thing rings a bell; I might even have suggested it). So while the transition from infinite sustain time when the parameter is set to max i.e. a horizontal line for the sustain phase, to a long sustain time with a slight droop, looks good, the short times are far off from the actual slope. So in the graph below, the sustain phase should really dive down like the decay phase does. (This is a bit of a convoluted example, as one would normally not set up the envelope like this, as the sustain level would not be visible either and the release would not be visible either - but the point of the illustration is to show the difference in rendering of zero decay and sustain times when they should look identical).
Now, the MiMi-d may be unique in that setting the sustain time to 10 (or rather, technically above 9.91) results in infinite sustain, but at least the Access Virus behaves similarly, except that it has a zero point in the middle, and values below that cause a decaying sustain phase (like the MiMi-d) whereas values above that cause an increasing sustain phase (back up to the attack asymptote level). If on the middle point, an ADSR curve is achieved.
One related issue is that the times shown seem linearly mapped to the parameter values, so that for instance an attack time of 10 is shown as twice as long as an attack time of 5. Now of course the mapping of parameter values to times is a bit of a rabbit hole especially when it comes to envelopes, but most synths have some form of Real analog synths tend to have log pots for this and Curtis CEM3310-based synths like the Prophet 5 tend to have true exponential mapping. The MiMi-d uses a compromise with a power-of-five mapping. But at any rate, having some form of exponential-like mapping between envelope time values and displayed rates might help alleviate the sustain time issue as well as more accurately render the relationship between differently set envelope times.
Of course, it will always be a compromise, as the mapping/scaling may be different for different segements of the envelope, and certainly different between different synths.
Another comment is that most envelopes have exponential decay and release phases, i.e. like this:
I can certainly understand that it may be overly complex to try and render the envelope this way though. And also it’s an assumption that does not always hold true (indeed the MiMi-d for instance has switchable linear/exponential envelope shapes).
2 Likes
Thanks for the detailed feedback and your work on MiMi-d, including envelope design.
The graphical envelope editor in zynthian is in its infancy, having been introduced by @jofemodo just a few weeks ago and further enhanced over that period, e.g. adding touch control, increasing quantity of phases from ADSR to AHDSFR, etc. It now works pretty well with most engines and I think we should be proud of our progress, but of course, this is just the start of our journey. 
I agree with this but think that the benefit of seeing the longer list of parameter pages when a widget is not available is sufficent to justify this behaviour. We could have a wasted space if no widget is available but that would be style over design… we are not Apple!!! 
I took a design decision to represent the fade phase of the curve as a slope: between end of decay phase and start of release phase on the time (x) axis and between the sustain level and half sustain level on the amplitude (y) axis. This is not a true representation of the curve but allows us to represent it in a way that, with some contextual desciprtion / understanding, can be comprehended by a user. Each engine will behave differently and the same engine may behave differently based on its configuration. This implementation of envelope editor is generic for all engines and hence is a compromise. There must be a perceivable identification of each phase of the envelope curve and it is impractical to draw the curve as an accurate representation of the real time/amplitude curve. (It may have too large or small variation in each axis for each phase to be drawn in a useful way.) The user must therefore consider it as a hint of the curve rather than the true curve.
The fade phase is added specifically for MiMi-d but used by a couple of other engines. Some of those engines have bipolar ranges with negative and positive ranges antenuating or boosting signal over the fade phase. I haven’t yet checked how each behaves and worry that they may vary in incompatible ways… What I have observed is that the curve for those is wrong. We will look at that in the future, at which point we will also consider how best to represetn short fade times.
The choice of straight, linear line representation is a pragmatic one. We wanted to get something available quickly. We will consider how to modify the curve in a more sympathetic manner in future itterations. (Feature and bug reports in the isse tracker are welcome.) Obviously, drawing straight lines is easier than drawing exponential / logarithmic / power-of-five beizer curves but we may make it prettier…
This is quite similar to the curve we have in synths like MiMi-d except the Korg doesn’t decay after it reaches the sustain level whereas the MiMi-d has two decay phases. I like the configurable curves of the Casio CZ/VZ which are similar to (but better than) the Yamaha DX. They have a number of phases, each with level and slope. You define where the release point is so you can create a complex curve with several attack and decay phases, a sustain and release with further attack and decay within the release phase. Dexed provides 4 of these phases for each of its envelopes. We do not support this in the envelope editor yet.
I suspect that the envelope editor we currently have in Vangelis (testing) branch is what will be in the next point release to Oram (stable) and that the fantastic feedback we are getting may influence future development. I would quite like to resolve the issue with bipolar fade but may not have time before the next pont release.
1 Like
My biggest gripe with this (referring to the MiMi-d) is really that two parameters (decay and sustain time) which have similar behavior are rendered very differently in the graphic. Thus it ends up not really being a good hint at all. I think it’s perfectly acceptable that the curves are drawn with straight lines for simplicity and because the true shape is not necessarily known without a lot of characterization or reverse engineering (for instance, the OB-Xd envelopes have a strangely implemented decay phase, where the asymptote is zero regardless of the sustain level, meaning that for high sustain levels, it approaches a linear ramp, whereas for low sustain levels, it behaves like a traditional exponential decay curve. This is different from the behavior of most analog style envelopes). I also think that the mapping from parameter value to curve slope will also naturally be a compromise, much for the same reason. But I do think that something should be done about the sustain time representation.
I think one thing that would help would be to have some form of at least semi exponential mapping of parameter values to slope times. That would mean that large parameter values would show up as long slopes to a greater extent than they do now. I’m convinced that all synths have some form of similar mapping, because a straight linear mapping of parameter value to envelope rate would bunch up all the useful envelope times at the very bottom of the parameter range. The mapping doesn’t have to be perfect, and indeed will never be as all synths do it differently, but I think it would be a vast improvement to do this at least partially. A good compromise may be a cubic approach, i.e. scale the parameter range to 0…1, and then raise the result to the third power, resulting in a range which is still 0…1 but with a cubic distribution instead.
A problem with this on the other hand is that short envelope phase times will be swamped by longer ones in the graphic. But perhaps that is of lesser consequence, because the main point of the graphic is to give a representation of the general envelope shape.
A larger issue here I feel is that the usefulness of graphic envelope representation is rises sharply with more complex envelopes, such as the six stage Poly-800 envelope above, the 8-stage DX envelopes, etc, but it is precisely those envelopes which are hard to interpret in a generic renderer, whereas the classic ADSR is so ubiquitous that it barely needs to be displayed in graphic form at all. Indeed, graphic rendering of an ADSR can even add more complexity as we now have two representations of the envelope (one with the parameters and one in the graphic) which don’t necessarily match up. I.e. the question “why does my preset sound the way it does” will be answered in two slightly distinct ways depending on whether on if one is looking at the graphic or the parameters. When working with a synth, one builds a mental model of how the parameters work and interact, and now we have a graphic that partly aids that understanding but at the same time may conflict with it. Still, a graphic representation will be useful especially to newcomers, functioning as a live tutorial. So I definitely don’t want to put it down, but at the same time I have some doubts when going beyond the initial joy of seeing the lovely graphic.
A thought struck me: Especially with more complex envelope shapes, it would be advantageous if the key on period could be indicated in the graph, somehow (thick line at the bottom, or coloring/shading, or vertical lines representing note on and off, etc).
I see another issue on the horizon when it concerns the MiMi-d vs other synths with similar ‘second decay’ or ‘sustain time’ phases. In the MiMi-d case, sustain time values over 9.91 are considered ‘infinite’ (the envelope reverts to standard ADSR). But it’s not given that all synths will operate that way. Ultimately one would need a parameter which governs when this happens, if at all. Perhaps this is on a too detailed level at this point. But it will need addressing eventually.
What would be really excellent would be if the synth plugin itself could generate a rendering of its envelope shape. I’m not sure how one would go about, but basically, some form of callback would generate the data points for the envelope, given its current settings, which could then be plotted by the renderer. I suppose such an idea is far off, but it does remind me of how ZynAddSubFX plots its filter responses - these are not just estimated filter plots, rather, the plugin actually does a sweep of a separate instance of the filter with its current settings, and plots that.