In my tests I noticed that Pianoteq is not maintaining the plugin’s advanced operating settings.
I noticed that every time I restart the application, settings such as “Internal sample rate” are lost and return to the default value.
In my investigations I saw that when closing Pianoteq it correctly saves the settings in “/root/.config/Modartt/Pianoteq.prefs”, the example of “Internal sample rate” is in the “engine_rate” field, but when activating Pianoteq again it overwrites this file and returns to the default value.
I ran my tests on the stable firmware release.
My Pianoteq is licensed and is on version 8.1.3
Yes! Zynthian configures Pianoteq to allow it to interface correctly. Zynthian depends on several configuration elements to run correctly. Raising the internal samplerate causes xruns.
In my tests I was able to increase the internal sample rate to 32000Hz without experiencing XRUNs after setting the Rasp overclock to “Medium”.
I would like to save this setup because the sound of the pianos was much superior to my ears.
At 24000Hz, the Pianoteq’s sound is inferior to the commercial libraries Giga and SFZ.
Yes I agree that Pianoteq’s beautiful sound is undermined by the reduced samplerate. We currently limit to half the soundcard samplerate. At 44100 this means an internal SR of 22150 which rolls of the frequency response below 11kHz which is quite noticeable. 32000 would give a 15kHz response which is the same as FM radio and much better. We should do more testing with Zynthian under load to see how that would work on RPi4. (RPi3 definitely needs the lower rate.) We probably need to allow use to decide because some may have heavier loads and prefer the lower rate. We could add a manual setting in webconf to force internal samplerate. Sounds like a feature request is required!
If you are going to enter it as “Feature request”, I would like to suggest a different approach: I think a more appropriate option would be a screen in the Zyn-UI where the user can adjust the sample-rate and also the polyphony and these adjustments can be saved within a snapshot.
This would be interesting as it would give the user the opportunity to set a higher quality for Pianoteq sounds only in snapshots where the user deems them most necessary. The standard remains within the traditional strategy of the sample-rate cut in half.
I think it would be more appropriate if you submitted the feature request. You can make the request with suggestions on implementation. There may be constraints, e.g. some parameters may not be adjustable at runtime (via an API or similar). Submit the request and we can see what’s possible.
Tend to concur.
It’s very helpful to have git features and bugs reported by the person recognizing the issue and it’s an excellent aid to the community, to widen the use of these tools.
I did some investigation today and neither samplerate nor polyphony are exposed in the API so this would require restarting pianoteq to assert the values. Possible but not optimal!
An interesting observation on this subject is that 32000Hz is the samplerate from the Roland JV-1080 to the XV-5080…
So if we were able to use this samplerate definitively it would be a pretty cool value.
The maths is simple for factors of the soundcard samplerate, e.g. a soundcard (and hence JACK) samplerate of 48000 is converted to 24000 by a one opcode shift-right command. To convert to 32000 requires more complex maths (multiply and divide) so every sample has maybe a ten-fold overhead.
This is theoretical and thickness may differ under the bonnet but we may see significant impact on performance by selecting a suboptimal samplerate.
If you run your soundcard at 32000 samples per second then you will see a significant improvement in performance but all sound will be limited to 15kHz bandwidth and some soundcards do not natively support 32000.
Regarding the calculations to adapt the sampling rate, Pianoteq itself suggested the best adjustment.
I did my tests by accessing the Pianoteq interface through VNC x.x.x.x:6081.
In the Pianoteq interface I went to “Options/Perf” and on that screen Pianoteq suggested a Buffer size of 192 samples to match the “Internal sample rate” of 32kHz with the 48kHz that I use in my audio interface.
Also on this subject, I left my 32kHz setting as definitive, I discovered that the file “/zynthian/zynthian-ui/zyngine/zynthian_engine_pianoteq.py” is responsible for editing the Internal Sample Rate. There is a loop that checks if the sample rate is greater than 24kHz in the preferences file and makes the adjustment before calling the Pianoteq binary. So I edited the file to not perform this step. Now I’m able to run my Pianoteq at 32kHz without any problems. (Yes)
Below is a PDF attachment of my Zynthian’s telemetry, notice the resource consumption after 11pm which is when I was using Pianoteq.
Speaking of the Pianoteq’s duty cycle frequency set by Zynthian, I understand your perplexity, in having to run the instrument at half the default sample rate, because in this way the simulated sympathetic resonance loses all of its shine and brilliance.
Still, the choice of the Zynth developers is very reasonable, if not plainly necessary, since - at least for the time being - a Raspberry Pi-based music system is simply not powerful enough, to munch the sheer amount of calculations exacted on the CPU by the algorithm of an advanced physical model.
Personally, I reckon that the main question lies at the very core of mathematical real-time synthesis, meaning that, for all of their conceptual elegance, the physical models aren’t simply (yet) there, in terms of plausibility of simulation.
I deem that a whole upper order of magnitude in computational power will be required, for achieving convincing acoustic results.
As for the instrumental quality of Pianoteq itself, I lately found myself using it quite seldom, since my Roland RD-2000 - which employs a hybrid engine of samples and physical modelling, with accurate sympathetic resonance - sounds head and shoulders above any piano software instrument that I have tried (my only exception is that I haven’t played Ivory 3 yet, which seems very inspiring and life-like, at least judging from the first YouTube reviews).
Hello @Aethermind
As described in my previous post, I managed to run Pianoteq on Zynthian at 32kHz and it was excellent sonically. Mainly due to the fact that I use Zynthian mainly live, where the difference between 32kHz and 48kHz is not very evident.
Speaking of computing power, I believe that when Zynthian is available for the RPi5 these issues will be irrelevant.
Of these piano softwares, I really love TruePianos, I’ve been trying to convince Rowel to port TruePianos to Zynthian, apparently TruePianos requires less CPU than Pianoteq and I believe it would perform better on the RPi4, but they are very focused on finalizing the version 2.0.
