Ok, yes, that is an important point of course.
Good idea. Or perhaps the other way around, so that jalv by default keeps its old behavior, and a new command is implemented which has the new behavior. That would certainly limit the amount of testing needed (and also limit the worry that something will go wrong due to the changed behavior).
Hi @ricard !
Would you like to group the envelope parameters to work with the new ADSR widget?
The 2 release parameters would be moved to its matching envelope group. The bad, they will be alone in a second controller screen for each envelope group. The good, a nice AHDSR graph will be shown when editing the envelopes. Your plugin, your decision 
Regards,
That sounds interesting @jofemodo . How flexible is the widget; can it handle the āsecond decayā sustain time parameter that the MiMi-d envelopes have?
(Before adding the hold parameter, the envelopes were ADSSR, with hold they are now technically AHDSSR). I donāt really mind the release parameters being in their own separate page for each envelope, but I would like to keep the ADSS parameters one one page since they are the ones that most interact with each other, and then put Hold and Release on a second page.
The parameters for each envelope MUST be in the same group, and ordered in the right order, so you must group together the 6 parameters for each AHDSSR envelope. Zynthian will show the first 4 (AHDS) in the first page and the other 2 (SR) in the second one. We could re-order the 6 parameters as you prefer, but i think itās better if the order is related to the graph. I mean, users would expect parameters interact with the graph from left to right, following the envelope denomination: AHDSSR. Having the H in the last page, between S & R, feels strange to me.
BTW, could you send me an example plot for the AHDSSR? Iām not sure of how implement the second S (or itās the first one?).
Regards,
If you imagine an ordinary ADSR curve such as:
In the MiMi-d, when the sustain level is set to maximum, the sustain time is infinite, i.e. it behaves like an ADSR envelope with a constant sustain level.
How does the ADSR widget know when it should draw an envelope? Does it go by the name of the parameter group (i.e. if it contains the string āenvā for instance)? Or does it look for a parameter group with the name āattackā, ādecayā etc in it?
It does both
def get_screen_type(self):
if self.screen_title:
# Some heuristics to detect ADSR control screens ...
# TODO: This should be improved by marking ADSR groups!!
if " Env" in self.screen_title or " ADSR" in self.screen_title or\
("attack" in self.zcontrollers[0].name.lower() and
"decay" in self.zcontrollers[1].name.lower() and
"sustain" in self.zcontrollers[2].name.lower() and
"release" in self.zcontrollers[3].name.lower()):
self.screen_type = "adsr"
else:
self.screen_type = None
return self.screen_type
Thanks for the explanation,
I am working on a modification to the envelope gui which uses parameters in the ttl (or hardcoded into the non-LV2 engines). Each envelope control has one of the LV2 EnvelopeControls Port Group elements:
*fade is not actually in the LV2 spec but is used by a couple of Calf synths and I think behaves similar to the MiMi-d sustain time parameter so I will lobby to have it added to the official spec,
The new code does not use heuristics to detect envelope. All envelope controls must be tagged with one of the EnvelopeControls PG elements and all must be in the same Port Group to act on the same processing module, e.g. Filter Envelope.
This development is in the touch_envelope dev branch and should work for any engines that have these tags in their ttl. Currently only zynsampler is changed in the repo and I have tested against obxd and MiMi-d (dev version from github) using these ttl files:
MiMi-d_dsp.ttl (54.0 KB)
Obxd.ttl (30.9 KB)
With the right config most (hopefully all) envelopes with one or more DAHDSFR parameters should work. I am yet to look at the more generic / flexible envelopes used by Dexed which has four stages of rate+level.
Please, could someone please explain what the procedure is to get the UI to pick up new Factory patches? Iāve installed a new version of the engine, and an updated factory bank is available in /usr/local/lib/lv2/MiMi-d.presets.lv2, including an updated manifest.ttl in that directory. But the preset browser in the UI still shows the old Factory bank, even after trying āSearch for new presetsā in the webconf, in various combinations of rebooting both before and after. Itās like it has some case that refuses to get updated even though there are changes available. (Currently running Vangelis, so perhaps it is actually a bug somewhere).
EDIT: It seems that to make the new presets take effect, one must either add a new instrument chain with the plugin in question, or bold-click Select and Replace the engine with itself. Does this mean that the preset list is actually cached with the snapshot itself, on a per-chain basis (having the same plugin in multiple chains doesnāt mean that all get access to the newly installed presets; only the chain added or replaced since the new preset installation have access to them).
Last week I began to get a bad āforcing a round peg into a square holeā feeling about the ongoing adjustments to the MiMi-d envelope and related UI. Iāve given the matter a lot of thought over the weekend, revisiting some of the design goals of the MiMi-d. I wanted the MiMi-d to be a compact synth which still offers a lot of features, by utilizing the available modules as much as possible. This is inspired by instruments such as the Prophet 5, MicroMoog and Juno -106, which have a fairly small set of modules, yet utilize them to the max, in order to create a versatile and flexible instrument without requiring a sea of parameters to set it up. The range of sounds that can be achieved from these machines is astonishing, given their fairly limited features set. The latter also makes them eminently tweakable. That is why the MiMi-d has audio rate oscillator and filter modulation, and variable sync level. Thatās also the reason that the envelopes are basic ADSR types, with an additional time parameter for the sustain phase.
In the MiMi-a, with its 6-knob user interface, ADSSR envelopes made very good sense, mapping to five knobs, with the sixth one being an amount control. For Zynthian, with its four-knob interface, I was considering giving up the sustain time parameter altogether, but early on decided that I really do find the it valuable enough that itās worth including. The current layout with ADSS on one page for each envelope, plus a separate page for the Release parameter for both envelopes I feel is a good compromise, and has the added bonus that the release parameters can be tweaked from the same page without jumping back and forth, which is something that after implementing it I found more useful than I originally thought is would be, as often the release times of the two envelopes do need to be balanced against each other. Also, the first page is everything from note on up to note off, and the second page with the Release parameter is what happens after note off.
For me being able to quickly and swiftly reach the different parameter pages is very important. Some might disagree, arguing that when were dealing with an instrument that is page oriented, there is a lot of jumping about between the different pages, so we just have to get used to it. But I feel that there is a lot to be gained by a well crafted page layout, for really the same reason - itās cumbersome enough, so it needs to be alleviated as much as possible. I do a lot of live tweaking when playing, and I want others to be encouraged to do the same. To aid this, on my Zynthian I set up the ā3ā and ā4ā softkeys to be āupā and ādownā in the parameter list (although I have yet to manage this in oram; havenāt tried to do it for a while though so maybe it works now), to be able to quickly reach adjacent pages.
So what this boils down to in this case is that Iāve decided to heed @jofemodoās
comment:
and not implement the envelope hold phase in the MiMi-d, and also not adjust the parameter pages to put each envelope in its own page group, but rather keep the envelopes as they are today. I know this is a letdown for especially @riban who has put a lot of work into both discussions and testing related to the hold parameter and its implementation and also the work for the graphic envelope rendering feature. I value all the suggestions that Iāve received (such as among other things the bipolar detune parameters for the oscillators), but the āholdā phase is simply out of scope for the MiMi-d.
Part of the rationale for this is that logically, in terms of order, the first envelope parameter page would be AHDS and the second one SR, but that means a lot of jumping back and forth between the parameter pages for the ADSS parameters which interact a lot with each other when creating sounds. My latest suggestion was to put ADSS on one page and RH on the another, in order to keep the ADSS parameter together, which is a split I think one could get used to, but is questionable from a logical point of view.
In the end though, it boils down to just one feature too much for the envelopes. I have had a lot of similar reasonings while putting together the MiMi-d in its present form. Some of the suggestions that have been discarded have been:
Thatās not to say that I will not add a couple of more functions to the MiMi-d. The number of modulators is a bit on the tight side so I think the instrument would benefit from a few more. Pitch scaling of the envelope times is something I would like to have, and Iād like to implement PWM (renamed shape) control for the sawtooth and triangle oscillator waveforms. Before it comes to this though, I need to clean up and optimize the code, partly with the ability to run (more) successfully on RPi 3 based Zynthians in mind. There is a lot of baggage carried over from the OB-Xd, some of which sorely needs an upgrade.
(Given all this, some of the current parameter choices could certainly be debated. Why are there two pages of key assign parameters, most of which will seldom be used? Why two pages of spread parameters for virtually every one of the voice modules? Should there even be a page of DSP parameters in what purports to be an analog-like synthesizer? Part of the rationale for these is that the more esoteric parameters are at the top or bottom of the parameter list, and thus do not infringe on the core parameters for the modulators etc. Also, what is an instrument if it doesnāt have a few quirks. 
).
So I hope I havenāt stepped on too many toes (or at least not too hard ). Having more envelope stages is certainly useful, especially if there is a graphic representation available., but I feel strongly that it is out of scope for the MiMi-d. In the back of my head Iām considering putting together a bigger version of the MiMi-d, letās call it MiMi-e for now, which has a lot of bells and whistles such as three or four oscillators, additional multimode filter, more modulators and envelopes, with more stages, etc, etc, but is not as compact as the MiMi-d. Itās along way off, but somewhere on the horizon.
Regardless, if thereās something I can do that would make it easier to add the graphic envelope feature despite the current parameter page layout, like additional tags or whatever, Iāll be happy to help.
The page layout you will provide in the upstream MiMi-d will break zynthian envelope generator because there will be parameters from multiple curves on the same page so we are likely to create a custom ttl for MiMi-d like we had to for other synths to present the parameters in the right groups / pages to make things work on zynthian. This will provide zynthian users with consistent behaviour. You will have to manually override this to get back your preferred upstream behaviour. Iām not sure how the display will work for you. You may get a GUI editor that displays the wrong thing with drag operating on the wrong parameters. Itās a shame when we had a fully working implementation but we donāt control upstream projects. We can only lobby for our preferences then make adjustments in zynthian to make them work how we want.
Iām surprised that you are dropping the hold feature after spending so much time getting it working. Itās appearance in the release page (upstream) doesnāt impact page layout and it makes MiMi-d envelopes even more flexible. Oh well! We tried but you are the boss.
@jofemodo, given our need to create a custom ttl to place controls for each envelope generator on the separate pages, is it worth forking MiMi-d to use the development that includes these changes and hold?
The more logic way of grouping parameters is having all parameters for each āmoduleā in the same group. I hope @ricard decides to group the parameters for each module in a semantic, UI-agnostic way, leaving the representation of groups and parameters to the UI abstraction layer. This is the right way.
Regarding the the secondary āholdā phase, iām agnostic about keeping it or not. This is strategic decision about MiMi-dās sound architecture and i will be happy with the decision @ricard takes.
So, i would like to avoid forking the TTL and of course, i donāt consider forking the DSPās source code just for keeping the āholdā envelope phase.
All the best,
What? So youāre saying that each module needs to have its own parameter group? This requires a complete rethink of many aspects of the MiMI-d UI. One of my goals with the parameter layout in the .ttl file has been to minimize the number of parameter pages, because the more pages there are in the UI, the more cumbersome it becomes to scroll between them. (Also, I usually set up the ā3ā and ā4ā softkeys so that they step up and down in the parameter list, so that I can easily reach adjacent parameter pages.)
For instance:
This is quite frankly a bit of a shock for me, and it pains me because Iāve put considerable effort not only into setting up the parameter pages as appropriately as I can, but also into an infrastructure within the plugin which allows effortless configuration and reconfiguration of the UI.
Ok, so I guess Iāve made a mistake thinking that I can take advantage of the parameter
groups feature in order to create what I think is a terse and convenient user
interface. The ability for the plugin to be in control of the UI I thought was
a great feature. Itās pity that no one took the time to comment on this earlier,
after all the MiMi-d has been in the wild now for half a year, and I have not
had any comments that the UI was set up incorrectly.
I agree with @jofemodo that (from a simplistic viewpoint) it would be more logical to simply group the parameters together on some form of module basis, but I also think that blindly adhering to this makes for a worse user experience. I think we really should consider the fact that the UI is the way it is (four knobs), and if possible attempt to provide a UI experience which takes advantage of this.
First things to note are that the LV2 documentation is suboptimal. It is challenging to fully comprehend and variously ambiguous. Zynthian developers struggle with this as much as any LV2 plugin developer. We are not experts and interpret it as best we can. If we notice what we believe to be its misuse, we warn upstream. If we see a way to use it better, we do so and occasionaly make requests upstream (of LV2 or plugin devs).
The use of LV2 Port Groups to group together common or related parameters is good practice. The LV2 documentation states:
It is a fair assumption that a group may describe a module in a model of an analouge synth, e.g. Enveloper and that each paraemter in a group would have an appropriate designator, e.g. Attack.
Zynthian tries to use groups to show related parameters on the same or consecutive pages, otherwise it puts them in their default (numerical) order on consecutive pages. If groups exist, then each page of controls has the group name, with a number appended if there are too many parameters to fit on a page. There is a further hint from an option port parameter called displayPriority which, if present, zynthian uses to order the parameters within the pages.
So we try to present the parameters to the user as the plugin developer has hinted they should be. Grouped and ordered in a logical or workflow based manner. For the most part, this is fine. We end up with oscillator params together, filter params together, etc. This has worked fine because if one plugin dev wants to put their oscillator level control with their oscillator parameters whilst another wants to group them in a mixer then the user simply sees them as such, much like if you look at the panels of two different hardware synths you will see different layouts.
What changed recently is that we built a GUI representation of envelope. We like the idea of showng a graphical representation of each envelope for each synth in a fairly consistent way. Of course this is a challenge as each plugin presents these parameters in different ways but we have done a good job of abstracting the envelope representation. We may want to do similar for other common modules (although maybe few of them are as obviously presentable in a GUI form).
The way we did the envelope GUI is that, if you select a page that has an envelope parameter on it, then the envelope editor is shown for that envelope. It uses the group symbol to associate envelope parameters, e.g. the attack parameter in group A and the decay parameter in group A are represented in the same editor. Because zynthian orders its pages and parameters based on LV2 groups, the parameters of the same envelope end up on consecutive pages.
What would break this is if there were parameters from different envelopes on the same page. When you select the page, it will show the envelope editor for the first envelope parameter it finds so, adjusting parameters on the same page for a different envelope will not show in the graph. By using groups, this is avoided.
A technical note is that we actually use the LV2 Parameters designations to identify whether a parameter is in an envelope and then its group to associate parameters to the same envelope. If a parameter does not have an appropriate LV2 designator then we do not show an envelope editor and it behaves just like any other control. We support the standard LV2 DAHDSR curve plus an additions Fade parameter (which has been requested upstream to be added to LV2 standard).
I donāt think you have been working in vain. We have been collaborating closely to integrate MiMi-d with zynthian because we love MiMi-d and I think you quite like zynthian. If we had noticed something odd, we would have said. Indeed, since implementing envelope editor, that is exactly what we are doing. All plugins will integrate better with zynthian if they have ttl definitions that work in this way. We have tweaked many other pluginsā ttl files to make them work and hoped that we would not need to do so for MiMi-d, because of our collaboration but, if you make a design decision that effectively breaks the envelope integration then we will simply do a similar tweak to our version of the ttl to make it work how we want it to within zynthian, just like we have needed to do for several other plugins.
We have little or no influence over upstream design decisions. We can only lobby for what works in zynthian, adjust our code to accomodate upstream decisions (usually based on most common practice or interpretation of LV2) and tweak upstream configs or code if absolutely necessary. Our aspiration is to provide as many good plugins with consistent, or at least logical workflow for zynthian users.
I love MiMi-d. A few months ago it became my favourite model of an analogue synth. Building such a synth is what I was doing before I found zynthian and I have been disappointed in some way be each of my previous favourites. I have simple taste but oddly, have been difficult to please! MiMi-d is so very close to my ideal synth. Some of the changes I would love to see, you have already decided not to implement and they have mostly been icing on a cake which was already very pleasant so I donāt hold out for those enhancements. (If I really wanted them I would fork MiMi-d - but life is too short!) Maybe they will appear in MiMi-e. (Dear Santa, ā¦)
In a world so egocentric it is like a sun ray to read a warm compliment to a work of other person.
Thanks to both.
Hi @ricard!
I think itās better to have more pages but good and logical descriptors for each page, so you can find easily the parameters you want to change. Itās good a newcomer can understand the basic synth architecture by simply reading the control page titles.
Itās OK to make some exceptions to avoid groups with a single control, or grouping all āoscillator volumeā parameters in a āmixer groupā, etc.
What is not OK is too mix parameters in the same group just for ācompactingā pages, specially if the mixed parameters break functional groups, like envelope parameters. I mean, if you put all the release parameters for the 3 envelopes in the same group, you are breaking the graphic representation of envelopes. We need all envelope parameters in the same group for this.
Same would be true when we implement Bode plots for filters, bar-plots for EQ, etc.
Finally, think that although currently we have a fixed 4 parameters/page layout, this could be extended/changed at some point. The less we depend on this, the better.
All the best,
Just played around with MiMi-d for a bit and it sounds amazing. Thank you for making this 
I also have to say: MiMi-d is a great extension for Zynthian. Sounds amazing! Thanks so muchš
First of all, thanks for all the kind words. It is really heartwarming, especially in this slightly heated debate.
Look, we can argue about the interpretation of the LV2 standard and parameter grouping back and forth (and putting both release parameters on the same page is not just done to keep the page count down, having done it turned out to be very practical); in the end it boils down to a question of priorities. I personally consider it to be more important to be able to as quickly as possible reach all envelope parameters, especially once one starts to get into serious tweaking, whereas the vision of graphic envelope presentation has sailed up as of primary importance in mainstream Zynthian. I got the
impression that as a plugin designer I had a choice in the matter, but I have come to realize that this is not the case.
Frankly, I can understand the need to provide a consistent user interface across the Zynthian platform. @jofemodo and others are striving for the greater good of the platform and the community and that of course is highly commendable. I still feel the need to lobby for my case though, as I feel very strongly about it, even though it is only one voice among many. (I also feel that currently there is a graphic envelope craze which I think eventually will cool off somewhat. For one thing, I think that cleaning up some of the .ttl files (a case in point is OB-Xd) should have much higher priority in terms of user friendliness - still, an open source project like Zynthian depends on contributors enjoying what they are doing, so whenever someone steps up to a task like @jofemodo and @riban have done when it comes to the envelope graphics it should naturally be commended even thought there objectively might be other priorities).
With Zynthian as (currently) the only platform for MiMi-d (indeed, Zynthian is the definitive home for MiMi-d) there seems little point in having an āupstreamā which is going to be immediately mangled by an overriding .ttl file, forcing the core Zynthian team to maintain such an override (as if there is not enough to do already). So I will endeavour to provide upstream versions which put all parameters for each envelope in their own parameter groups.
Whether this will be on the master branch, or on a specific branch for Zynthian Iām not sure of right now; Iām assuming either would be acceptable @jofemodo ?
In closing, yes, I think Zynthian is an amazing platform, with an amazing community. To me it truly feels like the next generation of community-driven sound and music generation platforms. Not to diminish the hard work of all other contributors, my hat is off to @jofemodo who possesses a unique combination of hardware and software talent as well as management and people skills, and a spirit of positiveness to boot. I think very few if any other people in this world could have spearheaded the Zynthian project in this manner.
EDIT: It strikes me that even with the release parameters on the same page, a graphic could be displayed for the main envelope page, representing the parameters on that particular page at least. A compromise between both worlds.
EDIT2: Actually, testing this, this actually works for the main pages, except that the release phase is not shown (because itās in a different parameter group) (thereās a certain logic to it - there is no release parameter on that page). The release page just shows a flat line so a bit confusing; on the other hand, given that, itās irrelevant which envelope it is showing anywayā¦ that issue itself is remedied just by removing the lv2:designation param:release line from the release parameters.
Again I have to appreciate the Mimi-d Synth:
The preset āSweeping Resonant Padā in combination with TAL Reverb III, air plate, sounds absolutely incredible 
I just noted a really nasty thing in oram. First I thought it was just vangelis, but I just downloaded and flashed a new oram and itās the same there.
The problem is this: the parameters no longer seem to have the fine controlled detail of previous versions. The filter cutoff parameter in the MiMi-d goes from 0 to 10, and in previous versions the increments were 0.05. Now they are 0.10 . Not too bad for the filter (but worse than it was before when I figured the resolution was about 1/200 of the parameter rane), but the oscillator detune goes from -1 to 1, and the increments are 0.10 there too now which is far too coarse for that parameter (this means that the resolution is 10 cents which is far too coarse). Is this an intended change or is there something amiss, or is it something the plugin can control in some way? I can file a bug report but Iām not really sure where to start here.
EDIT: I filed a bug report for Zynthian to get things started:
I donāt know why I havenāt noticed this before. For now, Iām going back to the old 32-bit image in order to be able edit MiMi-d patches.