There is a new coarse/fine control. With encoders, you press and turn for fine control. With touchscreen you swipel left/right for fine control. I haven’t yet looked to see how you might do the fine control with bound control like CUIA binding. @jofemodo, did you consider this when adding this feature?
Aha! I’ll try that!
Instinctively it sounds like it would conflict with long and bold encoder presses - I’m assuming the UI senses that you are turning the knob and disables the long/bold press until the knob is released again - which might be an issue if one like me is hesitant about parameter changes. (I.e. “let me fine tune this parameter”, press the encoder, no, changed my mind, release it, and I’ve instead created a button press event). But I’ll have to see how it behaves in practice rather than speculate. I suppose this is not some behavior that is user selectable? I know Elektron machines use the ‘press for fine’ paradigm and I never really took to it when I’ve tested Elektron gear.
EDIT: I tested this and yes, of course, it’s the new ‘press for fine control’ feature. I still think that the coarse resolution does not always correspond well to the parameter value range (I’ve discussed this in more detail in the issue tracker).
Personally, while I appreciate the fine control that can be achieved, I’m still not completely convinced in the case of Zynthian, because especially in a live situation, there’s a large risk of accidentally short/bold/long clicking the knob, thus selecting a completely different function than intended. Another option is to implement coarse/fine control with ‘knob acceleration’ (i.e. detecting if the knob is turned quickly). Perhaps this is already done to some extent. Knob acceleration can be tricky though, especially if encoders with different resolutions are to be supported.
Released version tagged 2.0.5 on the master branch.
This release brings no major surprises. I was hoping to have more optimizations in order to reduce the CPU load especially on RPi3 based Zynthians, but ran out of time for more than the few listed below.
A new addition is the appearance of a ‘zynthian’ branch, which adds features to support the new graphic envelope editor in upcoming the vangelis release. The version numbers on the zynthian branch track the main versions, with the addition of a ‘z’. So the corresponding zynthian version is tagged as 2.0.5z .
- Envelope code clean up.
- A hold phase for the envelope was added but considered out of scope
for the upstream MiMi-d . It remains in the code, including the
parameter settings callback, for future use, or if someone wants
to fork the code effortlessly. - Minor optimizations to the oscillator code (BLEP/BLAMP tables
optimized for insertion into the waveform, keep sizes of delay
lines to a minimum, remove delay lines and use BLEP/BLAMP buffer
directly, speed up exponentiation function), reducing CPU load somewhat. - Minor fixes in the manual (description of LFO DC mode, improve description of oversampling parameter).
- The maxmum voice count has been increased from 8 to 32, to take
advantage of the arrival of the arrival of RPi 5 based Zynthian v5.1 .
An RPi 4 based Zynthian will play about 15 MiMi-d voices with
oversampling enabled; an RPi 3 Zynthian about 7. - A number of new Factory presets have been added. In addition,
a number of the already existing Factory presets have been updated. - A new Default preset sets all parameters to their defaults, and can
be used as a ‘clean slate’ from which to start.
For 2.0.5z (zynthian branch) additionally:
- The envelope parameters have additional “lv2:designation param ”
tags so that the corresponding parameters can be identified by the Zynthian
graphic envelope editor. - For the graphic envelope editor to behave consistently, all envelope
parameters need to be in the same page group. Since this breaks the
mainstream MiMi-d feature of having the release parameters for both
the filter and loudness envelope on the same page, on the zynthian
branch, a separate page is used for each release parameter, which
then is part of the same parameter group as the rest of the parameters
for that envelope.
I was considering turning oversampling off for all presets (and have off as the default setting), in order to give a better out-of-the-box experience (essentially, half the CPU load) for RPi3 users, but I think the majority of users will be using RPi4 or RPi5 based Zynthians, and the distinct disadvantage to having oversampling off is the appearance of digital artifacts when things like xmod or VCA drive are taken to extremes. Admittedly this is not the case for more than a handful of factory patches, but when experimenting on one’s own starting with a factory patch it is easy to get into the danger zone while twiddling, so I figured it’s better to give a clean as sound as possible out of the box, and users who are running out of DSP can disable oversampling in their snapshots if they want. For most of the presets when played from an ordinary 5 octave keyboard the difference is minimal.
I should also add that if anyone has any especially good presets that they’d like to share, I’d be happy to include them in the Factory bank in future releases. Or possibly in a separate Contributions bank if that would be better.
8 Likes
For V5 and MINI owners, there is also the “ALT” key way to get the fine adjustment. Probably the most comfortable way.
Regarding the press-while-rotating-knob, it’s been carefully implemented and you shouldn’t have issues with accidentally triggering other push actions. Test it, please!
Finally, regarding CUIA, i probably missed from the list when implementing fine, but it would be very easy to add an optional “fine-flag” parameter to the call. I will do right now.
Regards
2 Likes
Having a “fine” parameter for zynpot CUIA doesn’t really fits well. Fine adjustment is something you do in parameter controllers, so i’m not going to add the parameter.
For fine adjusting with CUIA, you should enter ALT mode using CUIA and then send the zynpot CUIAs. I think this would fit any CUIA -based workflow.
Regards,
2 Likes
Hi everyone, it’s been a while, with a hiatus over the holidays and the preparations leading up to them.
A couple of weeks ago I started on some optimization and refactoring work to prepare the code for future updates. This mostly affects the way modulation is applied, where the code now more closely reflects the UI with modulation destination selectors, rather than the original OB-Xd switch based selection. Also, oversampling is now only applied to the audio portions of the plugin, not the modulators (LFOs) and envelopes, reducing CPU load somewhat. Together with other optimizations, this means that it’s now possible to get 20 (instead of the previous 15) voices on an RPi4 based Zynthian.
I have now pushed release 2.0.6 to the master branch, together with version 2.0.6z on the ‘zynthian’ branch, which as before adds the necessary features and parameter structure to support the graphic envelope editor.
As far as releases go, thus, this is probably the most boring update yet; it’s more of preparation for things to come, although it does come with the benefit of reduced CPU load.
- General code cleanup.
- LFO code optimization.
- Restructuring of modulation routing, reducing CPU load and preparing
for future updates with more modulation sources. - Run modulation processing at the sample rate, regardless of oversampling,
in order to reduce the CPU load. Tests have shown that further reduction
is possible without audible artifacts, but more tests are needed to
determine exactly how much is possible. - A few new Factory presets have been added.
- A couple of Factory presets have neen updated.
Speaking of future updates, one of the things at the top of my list is to introduce more modulatiors - I’m always running out of LFOs, and they don’t cost a lot of DSP so having more of them is easily motivated. Also, some direct paths from controllers such as aftertouch and velocity to selected modulation destinations might be in order, to avoid the ‘trick’ of setting a modulator frequency to 0 (DC) , which uses up a modulator just for a control signal path.
However, all this would result in additional parameters added, which means that old presets will not set all required parameters when loaded. We discussed a while ago that jalv could load the default values for parameters whose values were not stored in the preset .ttl file. I don’t think any work has been done on this [EDIT: @jofemodo I do see that some work has been going on on the ‘asyncli’ branch though, so perhaps it’s not worth trying to do something until that branch has been merged?]; if it’s not on someone’s agenda, I could have a go at it, before moving on with MiMi-d work.
11 Likes
Some of the most productive work I’ve ever seen is the result of precisely this approach. This is very welcome!
1 Like
Ciao ricard
how can I know which release is installed in my Zynthian?
how can I update Mi-Mi-d engine and presets?
I think we walked throu’ a lot of this sort of stuff at the top of this thread, but I haven’t revisited it yet to get the context back . . .
I’m living in the past in the sequencer at the moment . . .
Actually, that’s a good question [finding out the installed plugin version]. Since MiMi-d has no GUI of its own it can’t show it anywhere. There is an LV2 function called getVersion() which is defined in the plugin file, which I was hoping would be read by something like jalv or the lv2info application, or that it would have been extracted to the plugin .ttl file (/usr/local/lib/lv2/MiMi-d.lv2/MiMi-d_dsp.ttl), but I can’t see it any of those places.
Otherwise, it’s easy to rebuild from the latest source on master, just log in to Zynthian using ssh and run
sh /zynthian/zynthian-sys/scripts/recipes/install_mimi.sh
from the command prompt. It takes a couple of minutes to build and install. Afterwards, reboot in order to get detected properly.
Even after installation it seems Zynthian doesn’t recognize the new presets. I don’t know if there’s a better method, but I usually go via webconf: Software → Engines → Search for presets, and when the page has finished loading (takes a minute or so), reboot Zynthian.
Sounds like this should be a feature request to show plugin version in webconf.
I just added the update to vangelis branch, via “prebuilt” package.
Thanks @ricard !
2 Likes
Thanks @jofemodo ! It will be nice for users to have it prebuilt as the time to build from scratch is rather long (the first time, upgrades which only rebuild the synth itself and not the framework take less than half a minute to build). (BTW, it also seems to be on the oram branch as both seem identical at the moment).
I might point out that both the old build script and the prebuilt image builds from the MiMi-d master branch, which does not have support for the graphic envelope feature in Zynthian. As noted above, checking out the ‘zynthian’ branch includes this feature.
I would also like to reiterate a question which might have gotten lost: a while ago we discussed if jalv should set the default values for parameters which are not in a specific preset file. That way, if parameters are added to new versions of the plugin, they will be set to their default values if a preset is loaded which does not specify values for the new parameters. (Load default settings prior to loading new patch · Issue #1222 · zynthian/zynthian-issue-tracking · GitHub). I wouldn’t mind having a look at the existing Zynthian fork of jalv to implement this, but I don’t know if it’s on anyone else’s agenda, and also I see that @jofemodo has done some refactorization on the ‘asyncli’ branch which might conflict with the default setting feature. (I know work is focused on the upcoming oram 2502 release at the moment so I realize jalv might not a priority right now).