The current settings are not working for me.
When I play the Steinberg very fast, I get click noise and the yellow flash of underpower appears.
The MKII works fine for me.
So I played a little with the settings.
The multicore is set to max right now. When I set it to ON, the yellow flash is gone most of the time.
And I reduced the voices down to 24.
Hence I changed zynthian_engine_pianotec.py at line 87 to
PIANOTEQ_CONFIG_INTERNAL_SR=22050
PIANOTEQ_CONFIG_VOICES=24
PIANOTEQ_CONFIG_MULTICORE=1
It’s better but still not perfect. Only if I reduce PIANOTEQ_CONFIG_INTERNAL_SR down to 11025, the performance is sufficant. But especially MKII doesn’t sound anymore.
I don’t know, who wrote lines 330 and following and hardcoded -multicore max
I deleted those if/else statements and only called
self.base_command = PIANOTEQ_BINARY
I think this I wrote that lines. At the time of writing (6.01) this was unproblematic and after that a newer version which needed more CPU power was released. Julien from Modartt told me to do so.
I have a Pianoteq-Raspi-3B+ (with an HDMI touch display) which runs also with this optimizations and I never had problems the last year.
A little warning: the yellow bolt signals an ELECTRIC underpower: not enough current to support the board as is.
And it should never happens, unless the system is pulled beyond its physical limits (and this is not the case) or something powered from rPI is consuming too much power.
I am working with cpu_isolation for this: 1 core for the GUI and the rest only for Pianoteq (note: not on Zynthian, but on my PIanoteq-only-Rapsi-3B±with-HDMI-touch)
True, but using every available resource does not qualify as “pulling the system beyond its physical limits”
I have installed a video system with the rPI fully overclocked and every core busy at almost 100%.
It needed a huge heatsink with fan, and even with a 5A power supply, I changed 5 USB cables to find one that worked and showed no yellow bolt.
I am using a dual 3A Meanwell power supply and had only one connected so far.
But the 5" screen and the Midibox connected via USB to the raspi was too much.
Now I connected the Midibox to the second Meanwell outlet and the flash is gone.
Holger, could you explain how to do the cpu isolation? I am running a recent Zynthian (3B+) without any other device connected, but I still get occasional overruns.
Best, Chris
This might be of interest.
When I connected the AudioInjector Ultra, the yellow underpower flash appeared again when playing the Steinberg.
I have a 5Inch screen powered over USB as well.
That’s why I bought a new 6A power supply replacing the 3A.
When I have the MidiBox powered over USB, the flash doesn’t disappear.
Only when I power it directly with the second outlet of that 6A power supply, the flash is gone.
So for all the MidiBox users… don’t power it over USB
I am getting x-runs but not seeing low-voltage power error. If I play the Steinway D/Prelude with several notes I get x-runs every 20s or so. This is mashing the keys but not beyond what a decent pianist would do. (I am not a decent pianist!) A pianist could easily exceed 32 note polyphony whilst playing many genre of music so my mashing is simulating such playing, e.g. Chopin often calls for many sustained notes.
I have disconnected all USB devices and driving from MIDI master keyboard without aftertouch or other controllers so it is just note on / off events. I feel this needs to be addressed if users want to purchase Pianoteq licenses. @mheidt did you manage to reserve processor cores for specific processes? (Note: My experience of multi-core audio applications is that core switching can lead to discontinuity of sync which is similar to xruns so it may even be better to retrain Pianoteq to a single core - but technology may have improved since then.)
[Edit] Further investigation shows that x-runs occur when Pianoteq reaches 100% on a single core so could be related to core switching.
Does it need to be specifically configured to use multiple cores to avoid core switching issues? Does Jack need any special handling for multicore applications?
[Edit] Increasing the Jack2 buffer size to 512 removes the x-runs (at least for now). I can hold sustain pedal and mash the keys to hit maximum polyphony (whatever that is) without seeing or hearing any x-runs. This isn’t an ideal solution because a latency of 23.2ms (at 44100 with 2 x 512 frame buffers) is too high. 256 frames is about as high as we would want, giving 11.6 ms latency at 44100 and 10.6m at 48000. This is at the limit of impacting live performance. (Half this would be better.) So we should continue to look for a way to improve Pianoteq performance. I would say it would be acceptable for it to work with 256 frames but ideal for a lower configuration.
Hi @riban, I’m an incompetent pianist (and the less skilled guitarist I know) but after changing the PSU - even if I play Pteq full pedal down with lots of note - I have to put effort into it to have some xruns (I’m on Z v2 - RPi 3 B+ with HiFiB DAC+ and all my master keyboards are powered with external PSU).
But… with one exception: if I leave VNC on (with an open session or not) Pteq goes from epic to miserable…
And about the multicore option I think it’s on by default as well the 32 notes polyphony and the 22KHz internal/44.1KHz external sampling rate.
Pianoteq needs all the 4 cores if you want to play seriously. Pianoteq is a curious case because it sitdown just in the limit of RBPi 3B+ process capacity. I mean … If you have a well configured zynthian and plays Pianoteq seriously, it will use the 4 cores and you will be in the limit. If you play really hard or “abuse” the sustain pedal, you could get XRuns (or not!), but certainly you will be using the 4 cores at a quite high %, so if you reduce the number of cores, you certainly will get a lot of XRuns.
I’m pretty sure that Moddart people have done a good work with the parallelization, but you have to think that Pinoteq runs a quite complex mathematical model on real-time. I supposse this implies solving (aprox.) some (many!!) differential equations, what probably means doing lot of operations with huge matrix (i hope quite sparse!). This is a kind of problem that can be parallelized “more or less”, so they do it. Most of zynthian engines only use 1 core because parallelization is not possible or not affordable.
Of course, the RBPi4, when it comes, should solve our performance problems.
Moreover, we could imagine some ways of improving the performance of Pianoteq, that Moddart people could try if they think it could be profitable for them:
Using the RBPi GPU for massive math calculation also could solve the problems (or perhaps an external TPU or VPU??), but Moddart should be convinced that this is profitable for them. And this is another interesting question …
I mean … Moddart has released an ARM version of Pianoteq, what is really great for us, of course. Not too many commercial plugins manufacturers are doing such a thing. True?
But … why they did it? IMHO, that probably means they are interested in embbeding Pianoteq engine in commercial hardware products, licensing their technology to bigger actors. Imagine the next generation of digital pianos, not powered by sample engines, but accurate and much more flexible physical modelling software
I tested some pianoteq installs which I downloaded from my account.
I wondered why pianoteq would make much more occasional xruns than before and it installed flawlessly through the webconf.
Following table shows version number of pianoteq and the corresponding performance index:
Pianoteq 6.6.0. index 8…10…11
Pianoteq 6.5.4. index 8…10…11
Pianoteq 6.5.0 index. 6…8
Pianoteq 6.4.1 index 13…15…18
Pianoteq 6.4.0. index 13…15…18
This was all tested with my licensed version of the Electric Collection with the Mk1 Basic stock preset and the internal Pianoteq MIDI player demo song while ssh-ing into it with XQuartz on a mac.
Shall I update my system to the latest os version to test the different Pianoteq versions? Since 6.4 I use the Grand C.Bechstein DG and I get along with this quite well.
Are those Pianoteq performance indexes reproducible??
