Perhaps it’s been fixed by now, but a while back I did some latency testing comparing stable to oram prompted by @riban I think, and while stable exhibited a latency of three times the buffer size (i.e. 5.8 ms times 3), there was an additional buffer time of latency in oram, which I think we concluded was something to do with Zynmidirouter.
It would help is if you could dig out that conversation and ensure it is recorded in the issue tracker. I vaguely remember but this old brain isn’t good at retaining such info for long!
[Edit] This is recorded in ticket #858 but has not been deemed sufficiently impactful to block Oram release. This will mean that Oram will be released with this behaviour and become the Stable release, effectively leaving anyone using the old (current) stable without any further software support. I advise @ricard to review the ticket and validate whether any updates have resolved the problem. (There has been some significant changes to audio routing to improve latency but I don’t think we did too much on the MIDI side.)
1 Like
Ah yes, that’s the ticket; originally the issue was regarding an extra period of latency that it turned out was added when Superlooper was present in the global effects chain, but it was then piggybacked to become a ticket regarding the difference in latency between stable and oram - at any rate the title of the ticket is still valid and it makes sense to keep a complete log in one place of the various latency related issues.
I can certainly test again with oram and see if the issue is still present.
For me the added latency makes the system rather useless as I experience a definite lag when the latency goes from below 20 ms to above. I have been considering halving the buffer size though on my unit anyway though, even on stable - the system seems to be stable enough with half the buffer size, and even if the added overhead cuts down on total polyphony, the lower latency is more important than maximum polyphony for me.
EDIT: Rereading the latency issue thread, this is one of the findings: "[…] I bypassed zynmidirouter and connected the MIDI input of OB-Xd directly to the MIDI input (what is it called - uart midi?). That brought the latency down from about 23 ms to 18 ms. So it appears zynmidirouter introduces a one period delay. "
Has there been any work done on zynmidirouter lately? I should test nevertheless, it could be that something else has changed which was what was actually causing the problem.
3 Likes
Running MiMi-d on an oram Pi 3 .
The Piano like playing seems to be quite an Xrun generator, which is perhaps to be expected.
@wyleu Is it only that preset that causes xruns? I wouldn’t expect it to depend that much on which preset was playing. The heaviest CPU loading comes from the filter and oscillator antialiasing, which are used in virtually every patch (however, with oscillator 1 set to Off, the code for the oscillator 1 waveshaping, including antialiasing, is cut out). Also, the CPU load is proportional to the number of voices playing. Do you get problems when playing single notes or only when playing chords?
As I wrote higher up in the thread (a couple of weeks ago), I’m surprised that performance suffers so much on an RPi3, as the CPU architecture is fairly similar to the RPi4. I posted a couple of commands at that time too, originally for Brian to try, to try and get an idea if the firmware build is missing some optimization flags. Please try the commands and report back if you have the opportunity.
EDIT: On another Zynthian (v4, RPi4) which I have access to, which is not using an original power supply, I had random xrun issues which I initially thought was a software issue until I realized it was a power supply issue. Running the command
gencmd get_throttled
on Zynthian will tell you if the system is or has experienced undevolting (see [How to] Interpret RPi vcgencmd get_throttled - General Support - LibreELEC Forum for interpretation of the resulting printed value - basically 0x0 is good, other values indicate that the system has throttled down for various reasons).
I was oodling with the MiMi-d in oram, and noted that the sustain pedal response was erratic, especially when a lot of notes are played. Switching back to stable brought back normal behavior. Tested OB-Xd and Dexed in oram, and they have the same problem, but not ZynAddSubFX (which is not an LV2 plugin if that has any bearing on this). Have created a ticket for this Bug: LV2 plugins sometimes miss sustain pedal messages in oram · Issue #1062 · zynthian/zynthian-issue-tracking · GitHub .
1 Like
Version 2.0.3 tagged and released on the master branch. A very minor update which I thought I’d pushed out earlier: The detune range for the oscillators is now from -1 to +1 instead of just 0 to +1, matching the UI updates in oram that display bipolar parameters as arcs starting from the central (0) position rather than always starting from the left.
5 Likes
Fun playing around with it this morning…
1 Like
And, if someone has some spare time on their hands (I think @riban mentioned that he might) and has access to an RPi 3 Zynthian, could someone run the following and report back the results:
It might help me diagnose why MiMi-d seems to consume an inordinate amount of CPU on an RPi3.
Funnily enough I 've just fired up a Zynthian running Pi3 and it’s even got oram on it…
It’s zynthian-amp.local . . . .
With a couple of speakers on the amp…
And it’s got a behringer motor 61 connected to it.
Not a bad starting point for testing a MiMi-d clone is it?
It’s just getting a damn good updating…
Which fixed the none working select pot…
I’m running MiMi-d in single voice…
and it seems pretty solid …
Changed to a new patch . . . .
Here’s one for consideration for those sunning themselves on foreign shores, If one changes a setting like number of voices on a particular engine, how can this be propagated to ALL the stored patches so that you can browse patches with reduced voice?
It’s obviously a globally sort of thing but it’s required in this sort of scenario… ?
Could particular parameters be marked global . ?
@ricard Which parameters did you tend to have selected on your pots on the MiMi-A ???
It seems like a sensible approach for the Motor 61 to allocate accordingly . . .
Seems ok on Polysynth patch with 4 voices.
5 voices produces a yellow heart occasionally on Polysynth & MiMistrings( 50% CPU load)
Got splashy and bangy with a zynthian update (oram today)
(venv) root@zynthian-amp:~# gcc -dumpmachine
aarch64-linux-gnu
Pretty sure I’m running your most recent version. It splats and bangs a little bit…
4 Likes
Could you log in using ssh and see how much CPU the jalv process running MiMi-d using top (easy to spot - it’ll be at the top of the list when playing)? On the RPi 4, I get about 22% with 5 voices playing (and 34% with 8 voices) (MiMistrings patch).
Otherwise 50% with 5 voices on RPi sounds a bit excessive, given that the average speed increase on the RPi4 vs the Rpi3 seems to be 25% or so.
Do I understand correctly that it worked fairly well until you upgraded Zynthian?
Regarding the MiMi-a parameter knobs, there were 6 of them so they don’t map too well to the 4 on the Zynthian or the 8 on the Motor 61. Furthermore the MiMi-d is not a literal clone of the MiMi-a so there are quite a few differences.
At any rate, on the MiMi-a, there were 12 parameter pages: Osc A, Osc B, Osc C (= sub), Filter, Filter env, Loudness env, LFO, General env 1, General env 2, Bend, Assign, Misc
Osc A: Fine, Coarse, Wave, Shape (PW), Sync (on/off), Level
Osc B: Fine, Coarse, Wave, Shape (PW), Filter mod amount, Level
Osc C: Wave/octave, Level
Filter: Cutoff, Resonance, Key track, Env polarity, Env mode, Env amount
Filter env: A, D, S, S, R, Env amount (same as on previous page)
Loudness env: A, D, S, S, R, Volume
LFO: Freq, Wave, Key sync (on/off), Amount, Destination
General env 1: A, D, S, S, R, Amount
General env 2: Mode, Polariy, Bi/Unipolar, Amount, Destination
Bend: Bend amount, Bend destination
Assign: Cyclic/Reset-to-zero, Voice mem, Voice rob, Multi/single trig, Voice restore
Misc: VCA mode (lin/exp), Osc freephase/reset-at-gate-on, Env reset-at-gate-on, Hold/sostenuto pedal
(The envelope modes were Normal (one shot), Continuous Repeat, Key synced repeat, Key gated repeat).
Not all pages contained 6 parameters, furthermore some parameters had strings for their values that were longer than the 3 characters allocated to each parameter value in the display, filling up the space even when fewer than 6 parameters were used (for instance, the LFO and General env destinations had names such as “FILTER” and “SH A+B”).
3 Likes
Here’s a baseline. No notes pressed MiMistrings loaded.
Five notes pressed and 5 not selected in voice count
8 notes it Xruns and goes silent…
It all seems a little more stable this morning, given the amount of reconfiging it’s had it probably benefited form a nights rest.
Sorry about the presentation but the easiest way to do this was as screenshots. And of course given my qwerty keyboard is wider between Fn key & F12 button I had to hold a screwdriver in my hand to press on one key whilst pressing with my little finger on f12 whilst playing a chord on the Behringer… Should we set up a sequence or MIDI file that we can use to produce defined test case input…?
If we are clever enough we might be able to turn this into a Capture Workflow…
The Grecian based fishfood has pointed out I haven’t recorded a log file from the build. Do you need one and how do I contrive the state into something that suits your comprehension. IN essence what would you want me to type to generate it…?
I’e got 8 patch buttons on the Motor 61… Which patches did you tend to use on the MIMI-a and how close are they on the MIMI-d?
Probably the easiest way to create a log would be to go to the checked-out build directory for the MiMi-d and type:
make -C plugins/mimid/ clean && make VERBOSE=1
and make a screenshot of that. Alternatively
make -C plugins/mimid/ clean && make VERBOSE=1 2>&1 > log
and post the log file.
I’m honored by your attempts to create the MiMi-a experience when it comes to patches. I haven’t really thought of the MiMi-d patches in terms of accurately recreating specific ones on the MiMi-a, as I see the MiMi-d as an improvement on the original design, rather than attempting to be an accurate clone. My favourites would be MiMistrings (original name MIMISTRING, as the MiMi-a had a 10 character patch name limitation, upper case only), Mod Strings (MOD STRING), Upright Piano (PIANO) and Whiter Shade (WHITER SH). There are a also a sevceral which I’ve not attempted to carry over. I should probably do that.
Thanks for the htop screen dumps. I’m a bit ashamed to say that I’ve actually never used htop with the MiMi-d before. It’s interesting that htop has the same CPU load for both the real time and non real time threads in jalv, whereas ordinary top it seems only shows one of them. I’ll have to review the dumps and compare them with the RPi 4 results. Offhand it doesn’t seem like anything is wrong, but I’m a bit surprised at how high the load is on the RPi 3.
IT’s a compliment to the incredible effort you put in. I thought of similar devices at the time but you did it. The insight that provides is easily overlooked because it must have seemed natural to you, but I am wildly impressed.You’e done good.
MiMi-a was a gigging instrument and it’s sensible to preserve the intelligence derived from it.
I’m treating it as a mono synth at the moment on the Pi3, and I think I need a little bit of ctrldev
Classic Sync is something gorgeous on the Behringer’s pitch bend.
(venv) root@zynthian-amp:~/audio-plugins# ls -las log
4 -rw-r--r-- 1 root root 2993 Sep 3 10:38 log
(venv) root@zynthian-amp:~/audio-plugins# cat log
make -C dpf/dgl opengl
make[1]: Entering directory '/root/audio-plugins/dpf/dgl'
make[1]: Nothing to be done for 'opengl'.
make[1]: Leaving directory '/root/audio-plugins/dpf/dgl'
make WITH_LTO=true NOOPT=false all -C plugins/mimid
make[1]: Entering directory '/root/audio-plugins/plugins/mimid'
Compiling MiMi-d.cpp
g++ MiMi-d.cpp -Wall -Wextra -pipe -MD -MP -fno-gnu-unique -fPIC -DPIC -DNDEBUG -O3 -ffast-math -fdata-sections -ffunction-sections -fvisibility=hidden -fno-strict-aliasing -flto -DHAVE_ALSA -DHAVE_JACK -DHAVE_LIBLO -DHAVE_PULSEAUDIO -DHAVE_RTAUDIO -DHAVE_SDL2 -I/usr/include/dbus-1.0 -I/usr/lib/aarch64-linux-gnu/dbus-1.0/include -DHAVE_DBUS -DHAVE_X11 -DHAVE_XCURSOR -DHAVE_XEXT -DHAVE_XSYNC -DHAVE_XRANDR -DHAVE_CAIRO -DHAVE_OPENGL -pthread -std=gnu++11 -mcpu=cortex-a72 -mtune=cortex-a72 -fvisibility-inlines-hidden -fvisibility-inlines-hidden -I. -I../../dpf/distrho -I../../dpf/dgl -I../../dpf/dgl/src/pugl-upstream/include -c -o ../../build/MiMi-d/MiMi-d.cpp.o
Compiling DistrhoPluginMain.cpp (LV2)
g++ ../../dpf/distrho/DistrhoPluginMain.cpp -Wall -Wextra -pipe -MD -MP -fno-gnu-unique -fPIC -DPIC -DNDEBUG -O3 -ffast-math -fdata-sections -ffunction-sections -fvisibility=hidden -fno-strict-aliasing -flto -DHAVE_ALSA -DHAVE_JACK -DHAVE_LIBLO -DHAVE_PULSEAUDIO -DHAVE_RTAUDIO -DHAVE_SDL2 -I/usr/include/dbus-1.0 -I/usr/lib/aarch64-linux-gnu/dbus-1.0/include -DHAVE_DBUS -DHAVE_X11 -DHAVE_XCURSOR -DHAVE_XEXT -DHAVE_XSYNC -DHAVE_XRANDR -DHAVE_CAIRO -DHAVE_OPENGL -pthread -std=gnu++11 -mcpu=cortex-a72 -mtune=cortex-a72 -fvisibility-inlines-hidden -fvisibility-inlines-hidden -I. -I../../dpf/distrho -I../../dpf/dgl -I../../dpf/dgl/src/pugl-upstream/include -DDISTRHO_PLUGIN_TARGET_LV2 -c -o ../../build/MiMi-d/DistrhoPluginMain_LV2.cpp.o
Creating LV2 plugin library for MiMi-d
g++ ../../build/MiMi-d/MiMi-d.cpp.o ../../build/MiMi-d/DistrhoPluginMain_LV2.cpp.o -Wall -Wextra -pipe -MD -MP -fno-gnu-unique -fPIC -DPIC -DNDEBUG -O3 -ffast-math -fdata-sections -ffunction-sections -fvisibility=hidden -fno-strict-aliasing -flto -DHAVE_ALSA -DHAVE_JACK -DHAVE_LIBLO -DHAVE_PULSEAUDIO -DHAVE_RTAUDIO -DHAVE_SDL2 -I/usr/include/dbus-1.0 -I/usr/lib/aarch64-linux-gnu/dbus-1.0/include -DHAVE_DBUS -DHAVE_X11 -DHAVE_XCURSOR -DHAVE_XEXT -DHAVE_XSYNC -DHAVE_XRANDR -DHAVE_CAIRO -DHAVE_OPENGL -pthread -std=gnu++11 -mcpu=cortex-a72 -mtune=cortex-a72 -fvisibility-inlines-hidden -fvisibility-inlines-hidden -I. -I../../dpf/distrho -I../../dpf/dgl -I../../dpf/dgl/src/pugl-upstream/include -fdata-sections -ffunction-sections -Wl,-O1,--as-needed,--gc-sections -Wl,--strip-all -fno-strict-aliasing -flto -Werror=odr -Werror=lto-type-mismatch -Wl,--no-undefined -ldl -pthread -shared -Wl,--version-script=../../dpf/utils/symbols/lv2-dsp.version -o ../../bin/MiMi-d.lv2/MiMi-d_dsp.so
make[1]: Leaving directory '/root/audio-plugins/plugins/mimid'
Generate ttl data for 'MiMi-d_dsp', basename: 'MiMi-d_dsp'
Writing manifest.ttl... done!
Writing MiMi-d_dsp.ttl... done!
(venv) root@zynthian-amp:~/audio-plugins#
And before the baying hordes start banging on for a sound sample that ain’t happening until I can operate the Zynth recorder from the transport controls…!!
Behave!!
Where is the sound sample? 
Well at present it is a nacent bit of code skulking away on the wyleu git hub proud of its name …
zynthian_ctrldev_behringer_motor61.py
How this magic is configured is explained here…
Course I’ve had to be a little bit devious cos, the Desperately limited resources of the Pi3 mean that trying to configure Visual Studio Code (VSC) to run against it is rather too much for the poor little brain of the Pi 3. So the USB of the Motor61 has been connected to ANOTHER Pi4 ( zynthian-rack6.local) to allow code development on a machine that shows enough potential to actually do some device driver development…
Because nothing is easy, the observant amongst you will notice that our fine German friends have thrown a Ö into the ident string to increase the pleasure of trying to detect it’s existence…
dev_ids = ["BEHRINGER International GmbH MOTÖR61 Keyboard"]
Why then couldn’t they ensure it closed down all sounding notes on it’s USB Port? and will this prove to be an issue on the Pi 4 and would a ctrl device driver be able to address it…?
Frankly, the questions one ends up answering have an alarming habit of spreading, literally, across the planet . . .
I wouldn’t hold your breath on that record button getting pressed, any time soon…
And given I now have 2 Zynths plodding away, I have the problem of which Pi I should record on…?
It does of course sound tremendous! 4 channel multizynths.
This is developing a perverse interest in the Yamaha TX816 especially after I heard it did this lead line…
Does MiMI-D do low note priority?
No, in Mono mode, it’s always last note priority. It will bounce back to any previously held note when KeyAssign#2:VoiceRestore is on, so you can do trills holding one note and repeatedly playing another, both up and down.
Regarding the CPU load, it would be interesting to compare with what OB-Xd uses on the RPi 3. When set up similarly to the MiMi-d, I get about 42% in htop for the two MiMi-d threads with 8 voices playing, and 34%/32% for the OB-Xd threads. The values fluctuate quite a bit, like from 40 to 44% for the MiMi-d; the important thing is the ratio between the two.
To be comparable, I’ve set OB-Xd Filter#2:FourPole to ON as well as Filter#2:Filter_Warm to ON (the latter corresponds to the MiMi-d DSP Control:Oversampling parameter). I also set the oscillators to generate sawtooth waveforms only.
(Regarding oversampling, I think I’ve set it to on in all MiMi-d Factory patches, but it only really makes a difference when FM or VCA overdrive are employed, so I should really review this setting for all patches and turn it off when it doesn’t make a difference).
If you don’t want to sit holding notes, you can turn off DSP Control:EconomyMode in the MiMi-d which corresponds to Ctrl#1:EconomyMode 0.0 in the OB-Xd, and adjust the number of voices being run using the voice count parameter. With EconomyMode off, the DSP code for all configured voices is run regardless if the voice is actually playing or not.
(One of these days I should really get around to rewriting the .ttl file for OB-Xd, as a lot of the parameters are in strange locations, or have strange value ranges (like continuous ranges for boolean parameters such as EconomyMode). But I don’t know how much that would be appreciated, if people have gotten used to the current layout).
I’ve been trying to ascertain how much more performance one can get out of an RPi4 compared to an RPi3. Some figures say something like ‘not even twice the performance’ and others say ‘three times as much’. The latter would correspond with my findings, as (if I patch the code) I can get 15 or 16 voices using MiMi-d on the RPi4 before I start hearing glitches, which would then correspond to 5 voices on the RPi3, Apparently the difference in clock frequency is not that great, and both share the same arm64 architecture, but the Cortex-A72 CPU in the RPi4 has other improvements over the Cortex-A53 CPU in the RPi3 which add up.
A colleague of mine has an RPi I might be able to borrow and do some experiments for myself.
Regarding the MOTÖR61 keyboard identification string, it’s ironic that the German word for motor is Motor, with no diacritics. A bit of German humor there I suppose. I always thought Waldorf was one of the more humurous German manufacturers, but you never seen them launch a Blöfeld, or Access trying to sell a Virüs.
I’ve slowly been getting back to MiMi-d development, and come up against a small issue regarding parameters3. . @riban suggested an addition in the form of an additional ‘hold’ parameter for the envelopes, which inserts a steady-state period between attack and decay. However, when adding the parameter it seems that since old presets don’t have the parameter, when loading a preset saved with a previous version of the plugin which lacks the parameter, the parameter value is never set by the Zynthian OS. Fair enough, in a way, but it means that the parameter will retain its value and not be set to the default which was what I was counting on. The MiMi-d has no preset management of its own, and relies on the Zynthian OS for all parameter management.
I haven’t done too much research; there are a couple of options I’m considering:
- If there is some sort of signal or event which occurs when a new preset is loaded, which is picked up by jalv and passed on to the plugin that it can trigger on, it can set all parameters to their default state before loading a new preset.
- The Zynthian OS could consult the current .ttl file when loading a preset, and send default values for all parameters that are missing in the preset being loaded.
Any ideas or suggestions?
(BTW, @wyleu , my previous post (MiMi-d - creating a new software synth for Zynthian - #80 by ricard) contained a suggestion for comparing the CPU load for the MiMi-d to the OB-Xd. It would be interesting to see the results of this, as the former is based on the latter, and so, although slightly more taxing, should be in the same ballpark. I realize everyone is probably pretty busy with oram and Zynthian V5.1 at the moment though.)
The parameter-based preset recall mechanism acts like an overlay which sets values for any parameters in the preset and leaves any others unchanged. You have already discovered this. As you say, this may give undesirable effects if a new parameter is added. The ideal behaviour would be a neutral value for the effect to reduce the impact it has on the sound. (This may not always be completely neutral, depending on the effect the new parameter controls.)
I suppose there could be a reference ttl preset that is pre-loaded before the parameters are modified or maybe better would be to use the default parameters from the main ttl if absent in the preset being loaded. This is your option 2. There is sense in that but we would need to validate behaviour with other engines. Some may have heavy resources, such as audio impulse files that you may not want to reload.