I was wondering how the original was operated and found this video. I like how fast he dialed on that keyboard. And another thing, there is an E-MU module in the back, I don’t know why, but I have two E-MU racks with full ROM slots. And I really like MiMi-d in Zynthian.
P.S. @ricard The offer to redraw the pictures in the manual is still valid.
Ah, yes, I’d almost forgotten about that demo.
Annotations for those that can’t follow the narration in Swedish:
0:00: Explanation of the MiMi-a oscillator structure, with a high frequency VCO (bendable +/- one octave) driving a programmable digital divider, ending with an analog sawtooth waveform generator, resulting in a slight analog pitch drift but digitally accurate intonation.
1:07 Demo of MiMi-a oscillators. There is a variable slope sawtooth, which was not carried on to the current incarnation of the MiMi-d (but I’m thinking about adding it at some point later), and the MiMi-a had no triangle waveshape.
2:49 Controls on the MiMi-a generally go from 0 to 100 instead of the more common but less intuitive 0 to 63 or 0 to 127, except oscillator pitch which is in semitones from 0 to 72 (also fine tune goes from -20 to 100 so it fits within a 7-bit range). In the MiMi-d I opted to go from 0 to 10 since I thought it would look better in a potential future GUI, and the Zynthian can show decimal values.
3:12 Sub oscillator. The oscillators in the MiMi-a are called A, B and the sub oscillator C.
3:44 Filter demo. I say that the filter was stolen from the Moog Rogue, but that’s actually not entirely accurate, as there are design elements of the Memorymoog filter in there as well. It is a transistor ladder design.
4:08 Envelope demo, with linear ramps between the sample steps to avoid zipper noise. (In the MiMi-a the envelope generation generates a new envelope sample every millisecond). In the MiMi-d this is accomplished by running the envelopes at the full sample rate rather that at some lower control rate.
5:35 LFO, demo of filter resonance as a possible mod destination.
6:18 Demo of the individual LFOs per voice in Key Sync mode.
6:46 Demo of the General Envelope Generator. The MiMi-a had one LFO and three envelopes, where the third envelope could be used as an LFO. In the MiMI-d there are two combined LFO/modulation envelopes to accomplish this.
7:27 Demo of audio rate modulation of the filter by oscillator 2 (oscillator B in the MiMi-a). Setting the this oscillator several octaves above oscillator 1, ae filternd th resonance almost at self oscillation (9 or so) results in various vowel-like sounds when the filter is swept (for instance in the MiMi-d Jaaaa sound).
9:02 Various patches. Explaining that I don’t really remember exactly why each patch sounds like it does. When you get something that is good, you save it, simply.
Yeah, the keypad work looks fast. After a while one gets good at it. 
The individual parameter pages in the MiMi-a are selected by entering the number of the page (0…11, with pages 10 and 11 being seldom used things such as the key assigner) followed by the MC button. So most often two button presses to reach each parameter page.
The E-Mu in the background is a PX-7 Command Station. I really love the pattern sequencer in the Command Stations. I basically swapped it for an XL-7 a little while after, which I still have (same machine, different color scheme). The sound generation section is a little quirky, but it does have a lot of useful sounds. I bought mine when prices were rock bottom, they go for about four times what I paid nowadays, and it’s not even vintage analog!
@ToFF I haven’t forgot about your drawing offer, but I wanted to get the factory patches and bug fixes out as fast as possible as a priority. I’ll get back to you!
EDIT: Augemented the description of audio rate filter modulation.
Today’s jam before lunch. Torso T-1 again and only 5 x MiMi-d:
I know the volume is a bit uneven.
013-MiMi-d.zss (20.4 KB)
Yes, people don’t know what to ask for, they don’t play for it and want outrageous money They should get rid of it for postage. And send it to me…
I have Proteus 2000 and Virtuoso + Protean drums, Sounds of the ZR, Techno synth construction yard, Protozoa sound, Peter Siedlaczek advanced orchestra ROMs. As I already wrote, I’m addict on it a bit
It’s actually a bit weird hearing these MiMi-d patches in someone else’s music.
Nice to hear that they are being put to good use in any case!
BTW, please do tweak or at least save local copies of the factory patches if you use them. I might certainly tweak them in upcoming releases. For instance, I’m reminded that I’ve sortof left the pan spread quite high in most if not all of the factory patches.
There’s a minor update on the master branch now (version 2.0.1). Code-wise there’s a minor bugfix for the key assigner, as well as some code cleanups. I’ve added a section on recommended key assignment modes to the manual, and corrected the name and values of the Env Retrig parameter. There are also a couple of minor tweaks to the factory patches.
As I understand it, the build script in oram pulls the latest version from the master branch so when enabling in oram, it always gets the latest release.
Next I want to do some unexciting cleaning up of the code before going on with more development.
It may do but it should not. We should define the commit / tag to bind to so as to avoid unexpected change of behaviour. During a test phase (like Oram is currently in) it may be okay to grab the latest version but certainly after moving to a stable release (like Oram will do soon) we need to be on a known, unchanging version. We would then chose if and when we move to a later version.
This could be helped by upstream tagging their releases, e.g. you could add a tag to git to define the current version (0.1, etc.) but even without this, we can chose the commit that we use. (The former allows you as upstream maintainer to indicate the state of affiars, e.g. this is a minor / major change.)
That’s fine. I’ve already taken to adding git tags on the master branch whenever a new release is made. The initial release a while back was 1.0.0, the one a couple of weeks ago was 2.0.0 and this last update is 2.0.1 . The version number is also returned by the plugin when queried and is also referenced in the manual.
Unfortunately, MiMi-d does not perform well on RPi3. I just tried it on my V3 running latest Oram and anything but the simplest patches cause the processor to overload with throttling and xruns resulting in severe audio distortion. This is a shame and possibly resolvable. Obx-d does not suffer in this way, nor does NoiseMaker (which I would have expected to trigger such issues). I don’t see what is triggering the issue yet. This is a shame because I was hoping this would be a good synth to run on all Zynthians, including our older population.
That’s a great pity, but also strange.
Certainly, MiMi-d uses more CPU than OB-Xd, but (with Economy Mode enabled), just like OB-Xd it only uses DSP for voices that are playing, so playing a single voice on the MiMi-d should definitely be less than say two voices on the OB-Xd.
When you say ‘simplest patches’, do you mean something like a single oscillator with no modulation applied anywhere?
The thing I can think of off the top of my head is if there are any build flags which are not compatible with the Raspberry 3 CPU (ARM Cortex-A53 vs ARM Cortex-A72 in the '4), but both the '3 and '4 use the same instruction set and both have DSP and NEON extensions so I can’t think of any obvious differences in that respect.
@riban : Do you think you could run a couple of gcc and build commands on your RPi3 Zynthian (running oram) and report back the results?
First, simply:
gcc -dumpmachine
and then, assuming you have the code checked out in ~/dpf/plugins: first cd to that directory, and then:
make -C plugins/mimid/ clean && make VERBOSE=1
(Skip the clean if it’s a fresh checkout).
Thanks!
Development has been slow lately because of other commitments. However, I’m working on one of the last remaining missing functions, namely, tempo sync of the LFOs. I’ve got it mostly working, testing it together with Zynseq. However, one thing baffles me. Whenever I change the tempo in Zynseq, the location information (bar, beat and tick) seems to get reset, so that while changing the tempo parameter (while the sequencer is running), the LFO continually resets to its initial phase, and when the tempo is left at its current value (i.e. when I stop turning the Tempo knob in the Zynseq GUI), the LFO continues to run at the correct speed, but is out of phase with the beat. Stopping and starting Zynseq restores sync, so all is not lost, but I still think it should be able to track the tempo also when running. I’m at a loss at understanding if the problem is in my interpretation of the beat/bar/time information, in the DPF Framework, or if Zynseq outputs incorrect time information when the BPM is changed.
@jofemodo, @riban is there another known good plugin which accepts tempo and transport information that I can try and compare with? Or is there a known issue with Zynseq? Any pointers would be helpful.
BTW @riban I saw that you’d merged a patch to display bipolar parameters in the Zynthian GUI. I’m going to have a closer look at it once I get the current set of fixes and the tempo stuff released.
The tempo and sync in Zynthian and zynseq isn’t well treated. You could consider it as a prototype or WIP. It almost certainly doesn’t work right but it hasn’t been at the forefront of our consideration. Let’s work together to improve this.
No other plugins have had much testing either.
Ok, that actually sounds reassuring. I tested MiMi-d as a plugin in Ardour tonight, and although the tempo cannot be twiddled with a knob like in (or should that be ‘on’?) Zynthian, it did seem to follow tempo changes, both manually and using automation without the same type of glitch as I experience in Zynthian. So with that under the belt, perhaps we can use MiMi-d to test Zynseq!
The thing with Zynseq is that when changing the tempo using the knob, both the metronome and any sequence that is playing follow the tempo change without a hitch, so I assumed that any transport messages would also be ok.
I’ll see if I can write a bug report (for zynthian-ui I’m assuming, since that is where Zynseq resides?).
All bug reports go to the zynthian-issue-tracker repro, not individual module repros.
Time is complex. There are various contexts and parameters that interact. Zynseq was made to work in it’s own context but there are some elements that dinner necessarily update properly. Add the ticket and we can get into the detail in the issue tracker.
Released version tagged 2.0.2 off the master branch tonight. Not a lot of changes, mainly LFO tempo sync that has been implemented (see the manual for details), which was the final functional TODO. Also cleaned out the copies of the Juce libraries that were a carryover from the OB-Xd code. Finally, a couple of new patches, including four ones that were actually included before, but were not listed in the manifest.ttl file . The one titled Temp Synced Echo showcases the LFO tempo sync feature.
Next down the line are more code cleanups, and some associated optimizations to try and eek out a few more CPU%. The envelope generator code is due for a rewrite which hopefully will eventually lead to the hold feature that @riban has been asking for. Summer is coming though, so progress will likely be fairly slow for a while.
Hi @ricard !
I just tested and pushed the patch into the zynthian updates, so everybody using Oram would get the latest MiMi-d when updating.
BTW, i tested the synced echo preset and it works fine for me when not changing tempo. Of course, you are right and it doesn’t work fine when changing tempo while playing. I will take a look.
Thanks!
Thanks @jofemodo for testing the sync. Honestly, I don’t know how useful a function it is in practice, I mostly included it because OB-Xd has it (although when testing OB-Xd both on Zynthian and in Ardour I couldn’t actually get it to work, so something has gone amiss somewhere, possibly in the LV2 Juce port in DISTRHO-Ports). So I’d see it as a low priority compared to other tasks to get it working all the way, but it’s up to you of course.
Also, @riban , I tested the bipolar control arc patch (750035c) (backporting to stable as I normally don’t run oram (yet) because of the increased latency), and it looks really nice. I like the way the arc completely disappears when the control value is 0, making it visually very easy to recognize this position. So far it only finds its use for master tune in the MiMi-d, but I’ll see about your request for bipolar oscillator detune parameters.
Increased latency??? What do you mean?
Regards