This happens because we have a known amplitude difference (from max to sustain level) in the decay but the fade is less obvious. We don’t want to drop the curve to zero during fade because we need to indicate the release phase. Also, we split the y-axis into segments with a maximum width representing a fraction (based on the quantity of phases) of the total width. Both appoaches are simplistic and could be improved. Please raise a feature request describing the issue and propose some possible curve representations. (If one mind is considering the problem you don’t always get the best implementation!)
Probably true. Raise a feature request and we can consider how this best works. Controls can be flagged as logarithmic (which probably covers all the non-linear curves you describe). This may provide a hint to how to render the curve. We need something that makes sense for each synth’s envelope and may not be a true representation but if something is very obviously wrong, we should improve it.
We can add this to the editor. It is only really plotting level and duration points so not too tricky. (I did this for my VZ-1 editor software and abstracted the envelope editor.) Please add a feature request. (I know - but I already have reported 44% of the open issues!!!)
I like the option. A MiniMoog had just knobs that you twiddled but they were all there in front of you. Zynthian also has knobs you can twiddle but only 4 at a time. I immediately enjoyed and benefited from @jofemodo’s initial implementation of the envelope editor and with more complex envelopes added in more engines and with touch drag, I love how easy it is to control the whole envelope from one place. It helps to suspend your logical alignment of time and space and use it as a tool to make relative rather than absolute adjustments (as you would when knob twiddling) - “I want a little longer on the attack”, not “I want 1.254s attack”. I think this (and possible other, future widgets) does provide benefit and is not just a pretty gimick, but we can all chose which features we want to use in the quantiful provision of the zynthian.
Absolutely! This is implemented but commented out in the code. Slightly different to your suggestion, I put a vertical line where the release occurs, i.e. indicating a trigger point in the curve. I too saw the benefit of indicating the key held/released phases of the curve but my implementation was a bit “ugly”, so we removed it and awaited user comment. And now we have one. @jofemodo what do you think of @ricard’s cool suggestion of indicating the key held period with a bar along the bottom of the display? We would want to avoid using too much vertical space but it could overlay the curve if necessary. Alternatively we could indicate the release point with an icon of line of change of shading. (Avoid colours as they are less accessible and can make the display less attractive (to some).)
Indeed, each synth may implement each phase in very different ways. Some may invert values (rate rather than time), some may have offsets / bipolar values, etc. We will try to accomodate as many in a common, automatic implementation but if necessary we may need to flag some behaviour. The most urgent example is the couple of synths that have bipolar fade phase. I have reported this as issue 1247.
I feel we are wandering into the realms of full plugin editor GUI which is not our aim in the zynthian UI. Simple sound crafting is possible from the limited UI. Complex sound crafting should be done with the native GUI which may provide much better control and visualisation of the plugin’s parameters. I would prefer to work on exposing the native GUI more easily to users, e.g. via a HDMI output. (It is more complex than this but that is the subject of a different discussion.)
I just added parameter groups and envelope marking to 2 synth engines:
Calf Monosynth => It has a “sloped sustain” phase, so it’s good for testing the envelope widget
Vex => It naturally fits quite nicely the 4 parameters/page zynthian design, so i decided to make it was worth the effort. On the way i got hugely pleased by some VEX “hidden” features that i was not aware. I prefer to describe the details in this thread:
I understand, but you essentially have the same problem already when the sustain level is set to zero - let’s say the decay time is 1 second and the release is 3 seconds. If you release the key before the decay is up it will continue at the release rate, but the graphic assumes the note is held for the duration of the decay phase and will show the curve dropping to zero before the release.
I don’t have any good ideas on how to solve this though, I think it’s a question of playing around with ideas in small increments. It is problematic, because depending on how long the note is held you will or will not notice the release phase, which is difficult to combine in one graphic.
I agree that one ‘exponential-like’ (or ‘logarithmic-like’ depending on you look at it) alternative should be enough, given that the exact mapping is not known anyway.
But quite frankly, are there any envelope generators that have linear controls for envelope times? Certainly it’s not something a hardware synth designer would ever consider, but plugins tend to vary wildly in their attention to detail so perhaps it’s more prevailant there.
I don’t really have much of an opinion on the layout of such a function, except that given that the x axis represents time, to me it makes sense to draw the ‘gate’ or ‘note on’ time in the same manner, rather than think of note on and note off events, which is a MIDI-centric way of thinking of it, but I don’t think that’s how most humans intuitively think.
BTW, I initially didn’t realize even from the name that one could edit the envelope right in the graph using the touch screen. I really like the way the segment is highlighted when touched, making it very clear which segment is being affected. I’m not a big fan of touch displays as synth UIs because they require much more concentration on the UI (especially if one has to pick up a stylus) which takes concentration away from playing, compared to knobs. But when the display is there of course it should be put to good use.
Knobs are good but we have designed zynthian to be used with knobs and/or switches and/or touch/mouse so we try to make it fully operational in all UIs.
Yes, and it’s an amazing feat to get the system to work more or less seamlessly in all these environments. I recently loaded up Zynthian on an bare RPi3 to test the CPU loading on that platform, and I was pleased that everything worked more or less out of the box with some minor (and rather obvious) configuration done via the webconf. I fairly effortlessly ran the UI using a mouse and pointer via VNC.
I think this (and possible other, future widgets) does provide benefit and is not just a pretty gimick, but we can all chose which features we want to use in the quantiful provision of the zynthian.
Absolutely! This is implemented but commented out in the code. Slightly different to your suggestion, I put a vertical line where the release occurs, i.e. indicating a trigger point in the curve. I too saw the benefit of indicating the key held/released phases of the curve but my implementation was a bit “ugly”, so we removed it and awaited user comment. And now we have one. 
