Feature request: Hold stage for envelope generators

[riban-bw]

There are lots of different envelopes implemented in various devices. The envelope generators in Mimi-d are ADSSR. I find the addition of a HOLD stage to be advantageous.

Hold is a stage that holds the level after attack has completed before delay commences. It is similar to the sustain time in your ADSSR emvelopes but occurs earlier in the process. I appreciate this is an emulation of your earlier mimi-a but you have other enhancments and I beleive this to be useful (and relatively easy to implement). The resulting envelope would be AHDSSR. I find hold to be more useful than sustain time.

[polluxsynth]

I'll have to give this some thought. It certainly would not be especially hard to implement, but I'm not sure how to squeeze in another parameter in a logical way. I actually find sustain time rather useful so I don't want to remove it. I could put a Hold parameter on the Release page (and rename it accordingly) but that sortof breaks the pre-release / release split of parameters.

I would imagine that the most useful application of a Hold stage would be to add some 'punch' to the envelope, when the attach and decay times are fairly short - is that how you tend to use it?

[riban-bw]

It is tempting to avoid adding controls because they don't fit the 4-controls-per-page UI. I have been through that thought process many times but ultimately we are building musical instruments and processors, not laying out newspapers or magazines! The UI is important for usability but must be secondary to the sound design and playability. You already have athe envelope spanning two pages so it doesn't seem unreasonable to fill that second page. You may want to reconsider pairing the envelope release on the same page and instead put all env controls together. If you did then you could keep the pre/post release split across pages (kind of):

Env 1 (Pre release)

• Attack
• Hold
• Decay
• Sustain

Env 2 (Post release and holds)

• Release
• Hold time (I know - not pre-release but there is some logic to keeping the hold times together)
• Sustain time

I am not suggesting removing any parameters. I can see how useful the sustain time (hold) is in sound design. (I may add it to the Zynthian Audio Player's envelope.)

The purpose of "Hold" is to allow a sound to persist for a duration (that may be longer than a short "punch") before decaying but allowing the decay to reach the sustain and persist. This may be a sound that needs to enforce the note for a while (a few beats) than persist as a pad or pedal (or drone) for much longer. It provides a similar automation that sustain time does but earlier in the envelope. (TBH I haven't done nearly as much sound design recently as I would like but did find this hold to be sufficiently useful when building my last envelope to add it: AHDSR - which also broke the 4-per-page boundary.)

[polluxsynth]

A lot of questions on details here ... first of all, in your suggestion you've listed Hold on Env page 1 and Hold Time on Env page 2. Are they the same parameter in two locations, or are you envisaging two types of hold?

Currently all the segments in the MiMi-d envelopes (except release) persist only as long as the envelope is triggered, i.e. as soon as the trigger stops (key is released), the envelopes go into their release phase. The 'sustain time' does not lengthen the sustain phase in any way, it rather acts as a second decay, i.e. instead of the sustain phase ending in a constant level (the sustain level), once the sustain level is reached, a second decay phase kicks in, governed by the Sustain Time parameter.

(So perhaps a better name should be chosen for the parameter. I chose 'Sustain Time' because Attack, Decay and Release are implicitly 'time' parameters, but perhaps that should be spelled out in the UI to make it clear that sustain time has a similar behavior).

A hold phase would be a departure from this, so the question is if it should unconditionally stretch the end of the attack phase until the decay phase starts, or if it can be prematurely interrupted when the envelope trigger stops? Having it unconditional I think would be odd in that if the trigger is released during the attack phase, the hold phase will never be reached so the envelope shape will have a vastly different character when short notes are played . I have been considering adding an 'unconditional' mode, where the attack-decay phase (or attack-decay-sustain if sustain time is less than max) is always run through, regardless of when the trigger stops.

I can understand that when used in an instrument which plays back samples where one always wants at least a certain portion of the sample to be played that a hold time would be a big advantage.

Actually, come to think of it, one can simulate a hold time in the current MiMi-d envelopes: Set the sustain level rather high but not maximum, so that the level transition during the decay phase is negligible. The sustain time then functions as a decay control, and the decay time as a hold time.

[riban-bw]

Hold on Env page 1 and Hold Time on Env page 2 Sorry - that was a mistake. I meant to suggest ADSR on page 1 then hold time & sustain time for each env on page 2.

I think "Sustain Time" is fine. It could be supported with "Sustain Level" - it is often confusing that ADR are times (or slopes) and S is level. I often have to remind myself!

A hold phase would be a departure from this I don't think so! The hold phase is a time that the level is held after the attack phase and before the decay phase. It only occurs whlist the key is pressed and is ignored / interrupted when the key is released.

hold phase will never be reached Yes, exactly! The hold phase is only for long held notes that pass through attack to decay. Its purpose is to retain the full (end of attack phase) signal until the decay (or release) starts. If notes are shorter than the attack period then the hold and decay phases are skipped and the release phase starts.

simulate a hold time in the current MiMi-d envelopes No, this is just changing the decay phase to hold but loses the purpose of both. The hold phase is distinct. It is effectively another (full level) sustain period. You can consider the hold phase as a sustain (between attack and decay rather than between decay and release) but without a level, just a period. (A more advanced implementation might offer level too which would allow the signal to decay or increase further during the decay period but I do not suggest implementing that!)

My proposal is for an envelope that:

• Starts from zero (or possibly a non-zero value if configured to use previous, unfinished envelope) when a key is pressed
• Increases towards a maximum level whilst the key is pressed at a rate defined by attack time / rate
• Remains at the maximum level whilst the key is pressed for a duration defined by hold time
• Decreases towards a sustain level whilst the key is pressed at a rate defined by decay time / rate
• Remains at the sustain level (defined by sustain level control) whilst the key is pressed
• Decreases to zero after the key is released at a rate defined by release time / rate

As soon as the key is released the envelope jumps directly to the release phase, no matter what phase it is in.

[polluxsynth]

@riban-bw I'm finally getting around to implementing this, and I was wondering what sort of times you were thinking for the hold parameter. In the discussion above you mentioned 'a couple of beats', which implies sortof on the same scale as the attack time. On the other hand, if the focus is to accentuate the envelope peak, then perhaps a second or so would be a reasonable max (which would allow for more fine-grained adjustment of the time).

[riban-bw]

Maybe 2 seconds?

[polluxsynth]

@riban-bw Do you want to try the hold feature out before I merge it to master and release (hm, unintentional) a new version? Currently what's on the dev branch is the final version of this function unless some issue turns up. Basically, the hold parameter is on the same page as the release parameters, and goes from non-existent to 12.5 s at max.

[riban-bw]

I checked out dev branch and run make and make install then in webconf, search for engines, search for presets but the the envelopes still show ADSS then both releases on a separate page.

[riban-bw]

I have done some more kicking and managed to get it to show the 6 envelope stages. Release and Hold are still on a page shared between amp and filter and not consecutive with their associated controls which, as discussed here and in zynthian forum, feels incorrect.

The values for the envelope parameters seem arbitrary. Low values seem to do nothing and the value don't align with any sense of time or level.

Attack range is 0..10 with 0 being instant and 10 being 18s. Decay range is 0..10 with 0 being instant and 10 being infinite (or longer than I was willing to wait!). Values below 3 are barely discernable. I wonder if this should be a logarithmic control? Sustain range is 0..10 with 0 be zero level and 10 being full level. I guess this is similar to controls that go up to 10 (or eleven!). Sustain Time range is 0..10 with 0 being instant and 10 being infinity. (I guess a similar slope to decay.) Values below 3 are barely discernable. Maybe this should also be logarithmic? That would make the upper range = infinity make more sense. Chosing 10 as the max value seems rather arbitrary and illogical. Also, it isn't clear until you use this control that it adjusts the sustain slope (effectively a second decay). "Sustain Time" is not intuitive to understand. Most users probably think of sustain as a constent level. (I may be mistaken - it may be just me that does not intuitively understand this parameter.) It feels like this control should be inverted so that a value of zero has no effect and increasing the value increases the slope. Release range is 0..10. It seems to have the same dynamics of the decay and sustain time parameters with <3 having little effect and 10 being infinite. Again, this makes more sense as a logarithmic control. Hold range is 0..10. It seems to have the same behaviour as Release and my comments are the same.

[polluxsynth]

Wow, thanks for the thorough testing! I was really just thinking about the hold parameter and how the envelopes behave in relation to that.

Yeah, when building a new version on Zynthian I find it's not always straightforward to actually get the new version to show up properly. Just installing a new version seems to be a question of a make install followed by a reboot, but when there are UI changes there seem to be various caching schemes going on in Zynthian that are not always easy to penetrate. I think that in order to get UI changes to take effect, I've had to scan for new plugins, then do a reboot afterwards, perhaps even repeating the procedure once more.

Regarding parameter values, most parameters in MiMi-d, like on most physical synths I would say, go from 0 to 10 in some form of arbitrary unit. Originally I had 0 to 1 but I got comments that that was a strange range even though mathematically it makes sense to go from 'nothing' (0) to 'everything' (1) - especially considering that in the world of DSP, audio signals generally by convention have an amplitude of 1. The only parameters which aren't in this manner are ones where there is an obvious mapping to a physical property, such as pitch (semitones) and detune (also semitones, albeit in the range -1 to +1). For the filter cutoff, the mapping turns out to be in octaves, but that's more by luck that the control range in octaves matches the parameter values. For the resonance it is ... what it is. One could have some form of measurement of the resulting Q factor of the filter but again I don't think it's terribly helpful.

The mapping from parameter values to actual times has been given quite some attention. A trivial linear mapping would be as useless as a linear volume control - everything seems to happen at the low end, with not much apparent change in the upper end. Another given option is an exponential mapping between parameter value and time, and in fact synthesizers such as the Pro One and Prophet 5 which are based on the CEM 3310 envelope chip have this mapping, as this envelope chip offers exponential control inputs for the time parameters. (The term used sometimes is 'logarithmic', and indeed potentiometers designed for volume controls are labelled 'logarithmic', but it's actually a misnomer as the mapping from angle to output value tries to approximate an exponential curve, with very little change happening at the start of the rotation, and larger rates of change the further it is turned in the clockwise direction). The problem is that in practice, true exponential mapping gives the reverse experience compare to linear - everything seems to happen at the top end, with very little noticeable change up to about 2 or 3 o'clock on the knob. If you've ever worked with a Pro One you'll know what I'm talking about.

In the MiMi-d I initially was planning to opt for a cubic mapping. This is used in some audio software such as Pipewire for mapping volume control settings against actual the actual volume. However, when I tried it out, it was too much like linear mapping, too much happened to the left of 12 o'clock (or below 5) and not much happened in the right hand of the parameter mapping.

So in the end, the mapping I opted for is a power-of-five mapping. To me it gives a reasonable compromise between pure exponential mapping, which is too extreme, and cubic (power-of-three) mapping which is too close to linear. The only gripe I have is that quite literally nothing happens below 1, which is an oversight, had I realized it in time I might have added some offset so that things started changing already just above 0.

I know that some synthesizer manufacturers, most notable Moog (at least on the older instruments) label their envelope controls with actual times. However, most synths don't do this, and I don't feel it's very useful, one doesn't think of envelope times in terms of milliseconds, but rather in terms of feeling - turn the knob until you get the sound you want, basically.

It's true that the scaling for the attack parameter is different form decay/sustain time/release. I felt that very long attack times were not really useful, and it's better to have tighter control over the times as the attack portion tends to be very critical being the onset of the sound.

The decay/sustain time/release parameter maximum values are not infinite, but they are very long, I think reaching just over two minutes. Partly it's done this way as long sustain times tend to be useful; the sustain time is akin to the sustain of a piano, which is fairly long, and I wanted to have the same range for all three parameters.

As for the terminology for the Sustain Time, it feels quite logical to me, and it's the terminology used by the Access Virus for instance. Another term I've seen is Second Decay which also makes sense. (On the Korg DW-8000 the corresponding time was called Slope which always seemed a useless description, like calling one of the envelope segments Time.) Basically the Sustain Time is like the Decay time - it controls the rate with which the envelope decays downwards (towards the Sustain Level for Decay, and zero for the Sustain Time as it is for Release). Incidentally, the Sustain Time parameter is different from the others in that when it is set to 10, the time really is infinite - the envelope then behaves like a standard A(H)DSR. Having infinite Decay or infinite Release doesn't make sense to me - if one wants an infinite Decay, one can simply set the Sustain Level to max, and having infinite Release means the voice never goes silent ever.

Another way of looking at the Sustain TIme parameter is that it causes the envelope to behave as if it went into the release phase as soon as the decay phase is finished and it reaches the sustain phase - albeit with a different setting for the release time.

The parameter grouping I've also given some thought. The thing is that I feel that attack/decay/sustain/sustain time are the four parameters which interact most with each other, and which control the core of the resulting envelop curve, and therefore I want to keep them on the same page so that one can quickly manipulate them without having to change pages. In this respect, the Hold parameter is a bit of an outsider, as it's not a slope but a pure time. I agree that from a logical progression point of view, having AHDS on one page and SR on another makes more sense, but that would in practice mean flipping back and forth between two pages in order to set the sustain time vs decay time and sustain level, which I find cumbersome.

However, I'll have to give this some thought, as with José's latest graphic envelope widget, the advantage of having graphics may outweigh the awkwardness of flipping between parameter pages. (Honestly though, I'd rather spend the effort extending the widget so that the parameters don't have to be in order).

[polluxsynth]

In MiMI-d thread in the Zynthian forum I offered this explanation for the Sustain Time parameter; I'll repeat it here just for reference. This is of course a standard ADSR envelope shape; what the ADSSR variant does is that instead of the sustain segment being at a constant level, it slopes downward just like the decay segment does, the slope being set by the Sustain Time parameter, just as the slope downwards from the attack peak to the sustain level is controlled by the Decay parameter.

The reason for naming it 'sustain time' is thus that just the way the Decay [Time] parameter controls the time spent in the Decay phase by way of the slope downwards, the Sustain Time parameter controls the time spent in the Sustain phase in the same manner.

There are a couple of intricacies involved which hopefully should not be noticeable in any negative way, quite the contrary I hope: For one, the standard curve shape for most ADSR envelopes are not linear ramps as in the picture, but rather exponential decay functions: This means that as curve approaches the target (asymptote) level, the rate slows down, and in some sense, the level is never reached. This gives the most natural sounding decay, which is one reason it's very popular in synthesizers - the other reason is that it is the easiest curve to implement using analog electronics. This 'never really reaches the asymptote' behavior is the reason that the attack segment has an asymptote that is higher than the actual attack level, as it gives a more well defined end of the attack segment, as well as a sharper attack which doesn't seem to dwell at the attack level before transitioning to the decay phase. (The most common attack asymptote seems to be 1.3 times the attack peak level; certainly the CEM 3310 envelope chip uses this, and so that is what I've used in the MiMi-d).

Now, in ADSR mode (Sustain Time parameter set to max = 10), the MiMi-d envelopes behave as in the graph above. However, to get a well defined transition to the decay phase when the Sustain Time parameter is set lower than maximum, the decay phase asymptote is set lower than the sustain level, and the time is lengthened appropriately so that the perception is the same slope downwards. The transition from decay phase to sustain phase still happens at the Sustain Level setting in either case, but if you'd look at an oscilloscope trace of the envelope, the end of the decay phase looks a bit like the end of the attack phase (but inverted of course) in that the transition to the sustain phase happens a bit before the curve has reached the sustain level.

BTW, as you might know, in the MiMi-d it is also possible to set the envelopes to generate linear shapes (like in the first graph), as unusually that was what was used in the MiMi-a. At the time it was a reasonable design choice given the software envelope design, but I really like the traditional exponential ADSR curve better.

[polluxsynth]

It's strikes me that if you do find the behavior, or some part of it, of the envelope chaotic after this rather long-winded explanation, you might have found a bug, which of course needs to be fixed. The envelope code was partly rewritten leading up to the Hold parameter implementation, and there have been a couple of cases primarily when parameters interact with each other in strange ways, such as the Sustain Level parameter not having the intended effect until the Decay time is changed. I think I've ironed out the bugs, but I'd be most grateful for any description what would lead to fixing anything still remaining.

[riban-bw]

Thanks for the detailed descriptions of the envelope behaviour. You describe many of the nuances of making it sound right whilst presenting to the user a simpler high-level interface / envelope view.

Envelopes tend to consist of multiple stages of target level and rate/time. A traditional ADSR envelope has three stages:

• The first phase is triggered by note-on. It starts at zero and heads towards maximum level at a rate set by the attack parameter.
• The second phase starts at maximum and heads towards the level set by the sustain parameter at the rate set by the decay parameter.
• The third phase is triggered by note-off. It starts wherever the envelope level happens to be and heads towards zero at the rate set by the release parameter.

I have used the term "rate" but in fact these are durations. The slope or rate of change is derived from the duration and difference in level and as you have described has various factors influencing the shape of the curve.

Some synths add more stages, e.g. the hold paramter requested here traditionally adds a phase between the first and second (described above) that has a target level of maximum level and a duration set by the hold parameter.

The traditional sustain isn't really a phase, it is the result of there being a time and level setting for the decay and a trigger for the release. Your sustain time actually adds another phase to the envelope, with a target level of zero and a duration.

The Casio VZ range of synths provided up to 8 of these phases, each with level and duration so that you could draw complex envelopes. You could add the sustain (actually release) parameter to any phase. This is quite a good way to build envelopes. The envelope is flexible and the phases don't really need to be ADSR - they are simply P1, P2, P3...

If we consider the MiMi-d AHDSSR envelope in this way, we actually have a 5 phase envelope:

Phase 1 starts at zero. It has a target of 100% and duration defined by the ATTACK parameter. Phase 2 starts at 100%. It has a target of 100% and duration defined by the HOLD parameter. Phase 3 starts at 100%. It has a target defined by the SUSTAIN parameter and duration defined by the DECAY parameter. Phase 4 starts at the level defined by the SUSTAIN parameter. It has a target of 0% and a duration defined by the SUSTAIN TIME parameter. Phase 5 is triggered by note-off and starts at whatever level the envelope happens to be at. It has a target of 0% and a duration defined by the RELEASE parameter.

Regarding infinite duration on each of these parameters, it can be advantageous, e.g. I have a patch in my VZ1 that creates a sine wave without any release curve so that I can press and release a key and the tone persists. This was for engineering purposes but one may want a pedal note or drone. One may even want to do this with attack so that nothing happens until the key is released... there are some odd people out there (here).

Regarding zynthian pages, I absolutely understand the desire to provide a workflow-based interface rather than a technically logic. We are likely to take the rules I describe in this post as our basis for creating various envelopes used by different engines. We would prefer to use metadata in each parameter to define how they act on the curve and get rid of the current heuristic approach that is fundamentally flawed and won't scale well. So, when we define that we will ask that you tag your parameters appropriately and then it may not matter the order they appear... maybe! I do think they should be sequential though. Yesterday, whilst testing I found it awkward to jump between the parameters of the same envelope because some were a couple of pages away.

[Edit] After changing the ttl file in the lv2 directory, zynthian must be restarted. I think it has a global reference to the lv2 lib which is not refreshed during runtime (due to the slow update mechanism) so needs to be reloaded by an app restart. You don't need to search for plugins in webconf.

[riban-bw]

To move the AHDSSR parameters in consecutive pages, simply change their group to be the same. Zynthian will create consecutive pages for each, e.g.

• Filter Env#1
• Filter Env#2

By default the parameters show in the order they are defined so your preferred order is preserved but this can be overriden with hint displayPriority parameter.

[polluxsynth]

You have a point that it's a bit awkward to have the Filter Release parameter two pages away from the Filter Envelope page.

While it's true that people might want to do strange things sometimes, I don't think I'll be implementing infinite release. Especially for the MiMi-d I want to keep the analog aspect of it without too many bells and whistles.

Didn't the Casio CZ series also have 8 stage envelopes? While I agree it's very flexible, it is also awkward to configure as one has to remember where the sustain phase happens to be located this time. With the MiMi-d I'm trying to keep the configurability fairly limited because I think its inspirational not to have too many options that need to be configured. It's certainly flexible but it also makes it more of a chore to grab a preset and understand what is going on. It's all a question of compromises of course.

[riban-bw]

LV2 has parameters to identify DAHDSR envelopes which covers most common envelopes. Today I implemented the GUI envelope editor for this (not yet committed) so that we can support most synths. MiMi-d, Calf MonoSynth and Wavetable have the extra decay stage. Calf call it, "Fade". I will figure out a way to support it. Dexed has 4-stage rate+level envelopes.

I will make zynthian capable of handling arbitrary quantity of rate+level phases which may require extending the LV2 protocol. I will let you know how to implement the LV2 ttl to make it work.

[riban-bw]

I have implemented GUI control of envelope in zynthian that supports all MiMi-d envelope stages: AHDSFR (F=fade). Using this ttl, it works well. MiMi-d_dsp.zip

[polluxsynth]

Great job! The MiMi-d ttl is automatically generated by the DPF framework (which ultimately means that in the MiMi-d there is a single include file which controls all aspects of the parameters, meaning that it's very easy to add new parameters or move things around without having to manually adjusted parameter indices etc), and it looks like DPF doesn't support this LV2 extension out of the box. I think the easiest route is to do some post processing on the .ttl file in the Makefile after DPF has generated it. (In the longer run, falkTX might be persuaded to add this feature to DPF).

Getting back to the original feature, you seemed to have initially found the MiMi-d envelope behavior confusing, is that still the case, and if not does the Hold phase and associated parameter behave as you evisaged it?

[riban-bw]

The hold phase works as expected, thanks. The timing and control of the hold (and other phases) feels suboptimal to me. You have described how you have considered this and designed what you feel to be a good implementation but I find a lack of fine control across the range. The time soon becomes long. There should be finer control of short times... but that should be the subject of a different issue report.

DPF does seem to support designation. The description of the ParameterDesignation says, "Each designation is unique, there must be only one parameter that uses it." which I believe to be a misunderstanding of the use of designation. Maybe the documentation is misleading or maybe the implementation is wrong, but it is worth trying.

Indeed - I just did a quick test and was able to set every control port to lv2:designation lv2:enabled ; (which is the bypass defined by kParameterDesignationBypass). Also the audio output ports are flagged with lv2:designation pg:left and lv2:designation pg:right. So, the lv2:designation parameter is supported by DPF. The challenge is to use it in a meanginful way.

[Edit] I have reviewed the DPF code (specifically dpf/distrho/src/DistrhoPluginLV2export.cpp) and see that designation is not fully implemented. There are a few specific cases where it is written but mostly it is not. This would require a feature request against DPF which you could try. As you say, you could add a build stage that performs some processing of the ttl file.

[riban-bw]

An example bash script that can add these tags:

#!/bin/bash

#TTL_FILE=./bin/MiMi-d.lv2/MiMi-d_dsp.ttl

if [ "$#" -ne 1 ] || [ ! -e $1 ]; then
  echo "Error: Pass valid ttl file as only parameter"
  exit 1
fi

TTL_FILE=$1

if grep -q "lv2:designation param:attack" "$TTL_FILE"; then
  echo "Error: Update already applied"
  exit 1
fi

sed -i 's/lv2:symbol "filterattack" ;/lv2:symbol "filterattack" ;\n        lv2:designation param:attack ;/;
  s/lv2:symbol "filterhold" ;/lv2:symbol "filterhold" ;\n        lv2:designation param:hold ;/;
  s/lv2:symbol "filterdecay" ;/lv2:symbol "filterdecay" ;\n        lv2:designation param:decay ;/;
  s/lv2:symbol "filtersustain" ;/lv2:symbol "filtersustain" ;\n        lv2:designation param:sustain ;/;
  s/lv2:symbol "filtersustaintime" ;/lv2:symbol "filtersustaintime" ;\n        lv2:designation param:fade ;/;
  s/lv2:symbol "filterrelease" ;/lv2:symbol "filterrelease" ;\n        lv2:designation param:release ;/;
  s/lv2:symbol "attack" ;/lv2:symbol "attack" ;\n        lv2:designation param:attack ;/;
  s/lv2:symbol "hold" ;/lv2:symbol "hold" ;\n        lv2:designation param:hold ;/;
  s/lv2:symbol "decay" ;/lv2:symbol "decay" ;\n        lv2:designation param:decay ;/;
  s/lv2:symbol "sustain" ;/lv2:symbol "sustain" ;\n        lv2:designation param:sustain ;/;
  s/lv2:symbol "sustaintime" ;/lv2:symbol "sustaintime" ;\n        lv2:designation param:fade ;/;
  s/lv2:symbol "release" ;/lv2:symbol "release" ;\n        lv2:designation param:release ;/; ' "$TTL_FILE"

echo "Success: $TTL_FILE updated"

[polluxsynth]

Thanks for the script. That should do nicely. I'll pull it in soon.

Yeah, I looked at the lv2:designation usage in DPF, and it was only used in a couple of hard coded strings, for specific features as you noted.

[riban-bw]

My comments on behaviour of each envelope control are not directly relevant to this ticket. As I use the synth more I may submit a more targetted ticket.

The hold stage of the envelope does what I requested so, I suggest you release a version with the AHDSFR envelope, including the lv2:designation parameters in the ttl and close this ticket. Note that zynthian is gearing up for a point release which includes the envelope GUI and it would be advantageous to include this latest versoin of MiMi-D in that release.

Thanks for your attention to this.

[polluxsynth]

Agreed, I wasn't planning to make any immediate changes to the response of the envelope parameters at this time anyway. (It might have been an advantage if there are changes to be made to make them early on though, but it's too for now anyway).

Point taken about including the lv2:designation parameters. I've been otherwise occupied with other tasks the past week, but have gotten back to MiMi-d again now. The only thing remaining are really the addition of those parameters, and also some rearrangement of the menus to keep the envelope controls in the same parameter group (I might also take the opportunity to move some parameters like linear/exponential to the relevant envelope pages). Also, I've got a bunch of patches that are ready to be included in the Factory bank.

[polluxsynth]

I've added the lv2:designation param: to the output .ttl file on the dev branch now. Please test it if you feel daring; I have not tested it yet, but the resulting file looks ok. Also I've restructured the envelope parameters so that all parameters for a single envelope are in the same parameter group. This might need further adjustment but at least it should allow MiMi-d to work with the graphic envelope renderer.

[riban-bw]

Nope! That breaks it!!!

I couldn't pull dev branch. There must have been some significant changes to the history. Anyway, I removed my working copy and cloned a fresh copy then run make and make install (after manually deleting the previously installed copy). Zynthian does not find MiMi-d. lv2info https://butoba.net/homepage/mimid.html shows it but there is no Name parameter (which zynthian probably uses to display the plugin in webconf and subsequently, zynthian UI. I wonder whether your post-build scripts are breaking the TTL?

I notice you did your own post-build script for the designation. It looks like your approach rewrites the file many times. I avoided this by putting all the modifications in a single sed command. (Just FYI.)

I now don't have MiMi-d available in my zynthian V5! How will I cope???

[riban-bw]

The problem is the ttl is missing a definition of what param is:

@prefix param: <http://lv2plug.in/ns/ext/parameters#> .

Adding this to the ttl fixes it. Also, please give your opinion (on the zynthian forum) on the slope indication of the fade (sustain time) stage of the GUI envelope editor. Do you think it sufficiently and appropriately represents that part of the curve?

[polluxsynth]

Ah, thanks for finding that. I'll fix it this evening. And have a look at how it looks in Zynthian.

Yes, it's true it rewrites the file multiple times, I might optimize it at some point.

The dev branch is frequently rebased, so it very often can't be pulled from without tons of merge conflicts, but a git reset --hard origin/dev always works.

[polluxsynth]

BTW, are the updates for the graphic envelope rendering in Oram, or do I have to fetch something from a specific branch? EDIT: Ah, vangelis. Got it.

[polluxsynth]

Updated the dev branch with the @prefix line above. Tested in vangliis, and it correctly triggers the envelope display where appropriate, and the mapping of parameters to displayed curve segments is correct. I'll post some comments in the Zynthian forum.