Pianoteq 7 on Raspberry Pi 400 -- with iPad as interface! (Page 1 of 3)

Awesome, thanks for sharing. Could you please share the performance info, like performance index and a screenshot of Audio load? How is it close to potentially creating crackle sounds?

This might seem like a really stupid question, I'm a windows user and not great with Linux, but I can't find an executable for pianoteq 7. I remember having this issue when I set up the raspberry pi about 6 months ago and resorted to using an older version of 6 which did have an executable because I couldn't find one for the newest version 6.

It just asks me which program I want to use to open it, it doesn't seem to recognise or treat it as an executable. Tearing my hair out here and I don't have much left as it is, any help would be greatly appreciated.

Thanks!

Ah ha! That's got it. Thanks very much. Now, I think I can get it to auto run by simply changing everything I programmed before to point to 7 instead of 6.

A quick note to anyone attempting to do this, the arm folder is now called arm-32bit which i have discovered requires quotation marks to successfully point to the right directory. This might be obvious but messed me right up for a while.

I worked last night on replicating this setup. Here's where I'm at so far:

• I tried to launch Pianoteq in vncserver with the PI running without a window manager, but I haven't been able to get it to work yet. Part of the problem is making sure all the dependencies are installed. (fonts, gtk, etc.)

• I installed all the window manager stuff on the raspberry pi and was able to get Pianoteq running. It isn't saving audio settings between launches for some reason. I also haven't been able to get vncserver to launch it directly yet.

• Buffer size with the built in headphone jack output had to be quite large to avoid crackling. I tried with a cheap USB sound card and got much better results. (The cheap card has a lot of noise though, so I'll have to get something better.)

Sound from the built-in analog output jack is poor, anyway. To get good sound you need to use a usb audio interface or one of the many different audio Pi Hats.  FWIW, I use the $30 Hifiberry DAC+ Standard Pi Hat which gives good sound and low latency:  https://www.pishop.us/product/hifiberry...a-version/

Awesome! Great to hear the success you've had so far as well as your experience in the past. You're almost there. Simply SSH to the pi, then from the pi command prompt type:

vncserver

Now a new virtual desktop will be started and it will launch the full graphical desktop. It will tell you which desktop it launched on -- typically it will be :1 -- so now you can connect to :1 or :5901 depending on your client and you will be able to configure RealVNC exactly as you desire (or see the instructions in the earlier link I provided).

That should work. You can quit the desktop or run this command to kill it:

vncserver -kill :1

I had no micro-HDMI to HDMI adapter when I first got my Pi, so I did the installation completely headless. Now I have a converter and if I wanted to, I could hook it up to the TV, run "sudo raspi-config" and bring it back to desktop mode -- or just run "startx" from the command line.

Cool! FYI, you can configure all this from the command-line, which is how I did it myself:

https://www.raspberrypi.org/documentati...ccess/vnc/ -- section is "Authenticating to VNC Server".

I didn't have a Raspberry Pi OS image but I used the wizard on a desktop computer to create a brand new one. It was impressively easy.

To enable SSH, all I had to do was create an empty "ssh" file in the root of the micro SD card. DHCP worked out of the box.

Awesome! I'm fairly certain you would be able to scale down the full interface to make it fit as well. The client on my iPad can resize the view, for example... works in both landscape and portrait mode.

The top menu can be dismissed as well to get some extra space.

Congrats, looks awesome! Great you got this working!

May I ask which audio interface or sound card you used?

I could not stop today, until I've got my first tones from the Berry :-).
So I can ask your last question first. I connected one USB-Port of the PI400 with my Korg B2, which has a combined USB-MIDI/AUDIO interface onboard. It has a fixed samplerate of 24-bit/48kHz.

My first smoketest was the blues demo with the demanding NY Steinway. A good and rockstable compromise seems to be 48000 Hz with 32000 Hz internal samplerate and 96 samples buffersize. Pianoteq's Performance index is 20 (foto). Chord detection and virtual-keyboard disabled.

Some of my tweaks so far ...

/etc/security/limits.d/audio.conf

@audio   -  rtprio     95
@audio   -  memlock    unlimited
@audio   -  nice      -19

(this file was placed by the installed packet jackd, I just had to uncomment the nice-factor)

... and the other ARM tips from the  README_LINUX.txt (v7.0.3).

To play this setup realtime, I set the Korg local-off and turn its internal speakers up. At the moment this is just a proof-of-concept. My main system is an Intel N4200 with Focusrite 2i2gen2, two Fostex satellites incl. subwoofer. Would be interesting to see how the N4200 (Perfindex 36) performs, when paired just with a vncserver and without a full desktop environment.

There are again a lot of great tips in your last post, thank you navindra! Some of it I knew and forgot over time, like the SSH activation with the SD. But the Auth change from CLI was new to me, very useful!

What is that "wizard" you mentioned? an image-builder? Sounds ideal for a one trick pony PC.

Btw I found a little quirk when using display number :10. When I want to start my PTQ environment on the Pi400 manually from a remote Laptop, I have to ensure it has no "ForwardX11 yes" enabled in the ssh-client. This opens per default a DISPLAY :10 at login and vncserver can't start its own :10 then. But those things can easily be sorted out.

A few things for my todo list eventually:
Timer frequency for tighter response? (1000 Hz, 250 Hz, else on ARM?)
RT-kernel? Selfcompiled kernel? Alternative for RealVNC? Jackd?

Looks wonderful! I tried a self-compiled RT-kernel when I first setup my Pi 4 but didn’t see any noticeable difference in performance, presumably because milliseconds is hardly real-time (usually measured in microseconds). Timer frequency might be more promising as the Pi default is apparently only 100Hz.

Ah, thanks! Yesterday I found https://github.com/RPi-Distro/pi-gen and thought that has been meant.

It generates Raspberry Pi OS images and I tried to generate a base desktop system (Stage 3) but it built the lite system image (Stage 2). Maybe my config line has been wrong, don't know:

...
STAGE_LIST='stage0 stage1 stage2 stage3'
...

But that's another story. -

Nice foto updates!

I imagine a Pianoteq release in the future, that has a vncserver compiled in!
Like kvm, a popular Linux virtual machine host, that can start VMs headless as vnc-service.

This I have to agree with. I bet  Modartt will sell a ton when released for the iPad OS.

These are really awesome refinements!

Did any of these result in noticeable improvement?

#!/bin/sh
/home/pi/pianoteq7.sh
vncserver -kill $DISPLAY

Why is the last line needed? When Pianoteq quits and the script completes, X and vncserver should self-exit.

Very nice! Thanks for sharing the improvements!

Thank you, navindra!

The alsa audio/midi driver is using the faster clock timer now:

$ cat /proc/asound/timers 
G0: system timer : 1000.000us (10000000 ticks)
P1-0-0: PCM playback 1-0-0 : SLAVE
P1-0-1: PCM capture 1-0-1 : SLAVE

A cyle is 1 ms now (1000.000us) and has been 10 ms with the standard kernel. System should react snappier for the cost of CPU power. It seems to be so after short live playing, but I can say more when I have recompiled the kernel for direct comparison with the default 100 Hz timer (leasts 45 min on the Pi400).

The system processes are reduced now to:

$ pstree
systemd─┬─Xtigervnc───8*[{Xtigervnc}]
        ├─agetty
        ├─alsactl
        ├─cron
        ├─dbus-daemon
        ├─dhcpcd
        ├─rngd───3*[{rngd}]
        ├─rsyslogd───3*[{rsyslogd}]
        ├─sshd───sshd───sshd───bash───pstree
        ├─systemd───(sd-pam)
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-timesyn───{systemd-timesyn}
        ├─systemd-udevd
        ├─thd
        ├─vncserver───Xvnc-session───pianoteq7.sh───Pianoteq───9*[{Pianoteq}]
        └─2*[wpa_supplicant]

(after "apt-get remove pi-bluetooth avahi-daemon")

Pianoteq just disconnects as client from the virtual display in this environment. The vncserver keeps running so I have to kill it after quit from the pianoteq binary.

The performance index represented by the top blue line seems to be slightly lower yet, not constantly 20, sometimes fluctuating to 18...20 (Blues demo v7.0.4 std NY Steinway D Prelude again). Other small changes: Went back to Modartt's recommended ...

@audio - rtprio 90
@audio - nice -10
@audio - memlock 500000

... and stopped listening to the MIDI Through Port-0 (just need the MIDI from the Korg B2).

The real performance is probably better, when the performance grapher window is closed, because it sends continuously data via the Wifi VNC connection.

I had not a single crackle so far playing my stuff (being just a short snapshot of course).

Who said that?
Of course it is more CPU intensive to use a faster system clocking (1000 Hz), I wrote "for the cost of CPU power". Maybe you have overseen it in your full quote

The idea is higher precision, faster response, less jitter for that price. Maybe the forum thread Linux clocksources/timers is of interest.

For comparison I recompiled a 100Hz-kernel on the same sources I previously used for the 1000Hz-kernel.

I gave both kernels a different name so I can reboot them alternatively by changing my entry in /boot/config.txt:

kernel=kernel7l-my1000Hzconfig.img
#kernel=kernel7l-my100Hzconfig.img

The result is stunning. I predict you would never play a 100Hz system once you tried the one with 1000Hz! Precise, quick responding keys!

With 100Hz there is a randomness / jitter in the response, the brain can't adapt to. It feels, as if the piano "resists" somehow.

As a result with 1000Hz it feels more like being connected to a real instrument. Musically and technically more inspiring, fascinating.

Cheers

Some details for the record:

cat /proc/version 
Linux version 5.4.79-v7l-1000Hz+ (pi@ptqpi2) (gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)) #1 SMP Wed Nov 25 10:15:46 CET 2020
cat /proc/asound/timers 
G0: system timer : 1000.000us (10000000 ticks)

cat /proc/version
Linux version 5.4.79-v7l-100Hz+ (pi@ptqpi2) (gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)) #2 SMP Fri Nov 27 21:05:36 CET 2020
cat /proc/asound/timers 
G0: system timer : 10000.000us (10000000 ticks)

No, I just followed https://www.raspberrypi.org/documentati...uilding.md
and changed the kernel feature "Timer frequency" via make menuconfig:

Based on this https://passthroughpo.st/config_hz-how-...ffect-kvm/ it seemed like 250Hz would be a good value to try from the 100Hz default.

pi@pianoteq:~ $ uname -a
Linux pianoteq 5.4.79-v7l+ #1 SMP Sat Nov 28 23:34:16 PST 2020 armv7l GNU/Linux
pi@pianoteq:~ $ cat /proc/asound/timers 
G0: system timer : 4000.000us (10000000 ticks)

However, so far I can't tell the slightest difference between the 2 kernels. I'm not sure this change is worth it.

I tried 1000Hz as well and I think the performance characteristics are definitely very different -- but unfortunately I suspect the change is for the worse in informal stress tests. I'm not 100% certain. I'll have to record and run the same MIDI file against both to know.

I will park here for a while and compare the two. I'll probably default to my 250Hz kernel since it's newer than the original one.

pi@pianoteq:~ $ cat /proc/version
Linux version 5.4.79-v7l+ (ubuntu@diligent-newt) (gcc version 10.2.0 (Ubuntu 10.2.0-8ubuntu1)) #2 SMP Sun Nov 29 01:38:40 PST 2020
pi@pianoteq:~ $ cat /proc/asound/timers
G0: system timer : 1000.000us (10000000 ticks)

Summary: In my informal tests, I can't really perceive a difference between 100Hz and 250Hz, but I believe there is noticeable negative performance impact on CPU usage with 1000Hz in stress tests -- more spikes. I will stick to 250Hz, but if one is currently happy with 100Hz, I don't believe there is a need to change this setting.

OK, you got me exited to give the 1000Hz kernel another try
It is compiling while I'm typing.
Would be great if things work out this time.

Yeah, I know, but I needed to try myself
So I managed to compile the kernel and everyting boots fine
/proc/Asound/timer shows that 1000Hz is used.
Playing with Pianoteq feels a little more responsive, but the performance index is decreased 1 point.
The output load graph also shows it's closer to being maxed out.
Ah, well, I'm just gone try it for a while and revert everything if I don't like it.

Somehow I thought 1800 MHz would be the limit, thanks for that idea!

Under my test-conditions the higher PerfIndex (23) decreases the audio-load a bit, but it is not really necessary (screenshot before/after):

Although I used your entries ...

over_voltage=6
arm_freq=2100

... my Pi400 decides to use 2200 MHz instead of 2100 MHz. Probably some turbo mode ongoing.

Good to know some more headroom is available.

Late EDIT: Hz->MHz

Just discovered, that 'Multicore rendering: MAX' is selectable in the GUI of Pianoteq v7.0.4.
The CLI option '--multicore max' seems to be not necessary any longer on arm-32bit.

Hello,
it takes 25 seconds (using your autostart via crontab).

The wake-up time could be ~10 seconds less, I guess, when the Pi400 would start without WiFi networking. Starting the network and obtaining the DHCP-address takes 9.3 s (dhcpcd.service) in my boot plot.

$   systemd-analyze plot > mybootplot.svg

After the network is ready, the user environment is started containing my autostart cronjob with VNC and Pianoteq.

I am thinking about configuring one key on the Pi400 to switch on/off Wifi arbitrarily (never tried that before).