N00b with Pianoteq 6, a VPC1, a Surface Go, and a Focusrite Solo

Is it too late to swap your Focusrite solo <https://focusrite.com/en/usb-audio-inte...rlett-solo> for a 4i4 <https://focusrite.com/en/usb-audio-inte...arlett-4i4>?

The reason I suggest this is that the 4i4 has a MIDI input; you would connect your VPC1 to the Scarlett 4i4 with a MIDI cable and have only the Scarlett to connect to the computer.

I do not have direct experience here, so others might be able to document this being irrelevant.  I can only say that if I were setting it up, I'd want to have only a single interface connecting to the computer to minimize ways for things to go wrong.

Current generation Focusrite Scarlett interfaces use USB-C connectors, but I think they come with a USB-C/USB-A cable, so you'll need a USB-C/USB-C.  Despite the USB-C connector they are USB 2.0, though, so you only need a cable capable of USB 2.0 (that allows for a longer cable than if you needed, say, USB 3.1).

As to whether the Surface Go 2 M3 is up to running PianoTeq... I have no idea.

Thank you for your thoughtful and thorough reply.  The VPC1 is an awesome instrument.  I have a hub on hand, so I'm set there.  I'll follow your instructions now and see what happens.

Thanks again!

I agree with klaberte. I used a (very) cheap USB-C hub on my PC, for my sound card and USB-MIDI cable, it worked fine but sometimes it was unstable, perhaps you have to try a couple before having good results. To install focusrite drivers, just plug the sound card to an USB port and a new USB storage unit will be detected (like if the focusrite was a pendrive). Inside this unit there is a HTML document with step by step instructions. Hope it helps.

Update (even though the original post issue should have been solved, it may be useful for others):
I bought a generic USB 2.0 hub and I get not significant difference of latency if I connect both the USB-MIDI and the audio interface to the hub or if I connect them to different free USB ports on my laptop.
I get 10 ms of real latency (measured with an oscillosope, on PT interface it says 48kHz * 64 buff = 1.3ms). The use or not of the hub does not change this figure. I don´t know how to paste images to the forum, but the difference is not noticeable.
By the way I'm using a MP11 with its USB-MIDI output (not the DIN5 connector) and a miniDSP 2x4HD sound card (all effects by passed) with its own ASIO driver. The laptop is an MSI GL62M 7RD (Intel 7700hq) in power saving mode.

Hi, I generated the MIDI messages with a Teensy mictrocontroller. Then, at the same time the messages were sent, a digital pin was set high. I chose the trigger of the osc to be the digital pin signal, and the other channel the audio output. The time is between the digital pin signal (rising edge) and the audio signal.
I know the best option would be to trigger the oscilloscope with the DIN5 TX wire but the way I made the measurement is easier.

EDIT: I should measure this again to share the values because I only took photos with my mobile phone.

Yes, your scheme is correct

Well, you gave me an idea, and this weekend I am not very busy so just for curiosity, I made some latency measurements with the oscilloscope.
I covered the following items:
*Time between key stroke and MIDI message (on a Kawai CL35)
*Time between MIDI message and the sound produced on Kawais CL35 and MP11
*Time between MIDI message and the sound produced by Pianoteq
*Difference in latency between GNU/Linux and Windows
Hardware used: OWON SDS 1022 oscilloscope, Kawai CL35 digital piano, Kawai MP11 digital piano, MSI GL62M 7RD laptop (cpu: i7 4770hq), generic Chinese laptop (i7 4710mq), miniDSP 2x4HD audio interface, ESI UDJ6 audio interface, ESI MIDIMate II USB-MIDI interface.
Software: Pianoteq 6, Windows 10, Ubuntu Studio 20.04.
I discovered that it is possible to watch MIDI events on the oscilloscope with a non-invasive method, just attaching the probe to the MIDI cable, without any electrical contact, as shown in the following picture:
https://postimg.cc/fJBRPrfW

This way, I got the waveform corresponding to the MIDI protocol, somewhat distorted , but good enough to trigger the scope. Notice, the duration of a bit, corresponding to 31250 baud, the speed of MIDI serial communication.

In order to get the time at which keys are pressed, I opened the CL35 and connected the other probe to one of the OR diodes of the scan matrix. I don´t know whether that diode corresponds to the first or second sensor. The connection is not visible, but the picture gives an idea of how it was made.

Keys are scanned at 11kHz, as can be appreciated in the waveform:


So, until now, we can have the times between the keys being played, and the notes being sent through the MIDI cable.
Just for comparison, I measured the latency of the digital piano (from keys being played to sound being reproduced). I performed these measurements on my Kawai CL35.

Next, I wanted to know, the latency of a digital piano when playing notes from an external source, in this case I tested both CL35 and MP11. To achieve this, I sent notes from the PC and watched for the time between the arrival of the MIDI message and the production of the sound. In this section, we don’t know the time added by the USB to MIDI conversion, we are only looking at the latency between MIDI and audio.

Same procedure was followed to measure latency of Pianoteq with different interfaces and buffer settings, and, in this case, we can estimate the total latency as:
Total latency= key press to MIDI message latency + MIDI message to sound latency.
It is worth noting that latency is not constant among different successive tests.
Results:
The following values are averages of at least 3 measurements:
*CL35 Key press - MIDI message sent latency: 3.98 ms
*CL35 Key press - sound produced latency: 5.92 ms
*CL35 MIDI event received - sound reproduction latency: 1.97 ms
*MP11 MIDI event received - sound reproduction latency: 2.50 ms
So, if we want, for instance, to play MP11 sounds using CL35 keyboard using a DIN5 MIDI cable (who would do that?) we would hear the sound from the MP11 3.985 + 2.50 = 6.485 ms after having pressed the key, instead of the 5.92 ms that takes the CL35 to play its own sounds. Curiously, the higher end MP11 is a bit slower than the cheaper CL35.
Now let’s turn to PC’s latency, here the image gets a little more complicated because we can set different buffer values. In addition, we can choose in Windows between the native drivers and ASIO4all. For Ubuntu GNU/Linux there are many settings which can be improved but I used the stock image. Sample rates were chosen to be 48kHz and the buffer size 64 and 128 in most cases. Measurements made on the MSI laptop are marked with M, the ones made on the generic laptop with G. Just to add some information, I took old values from this post of mine in pianoworld forum, from year 2013, in which I complained because I wasn’t able to get a decent latency (http://forum.pianoworld.com/ubbthreads...._USB_.html). I had tested some latencies taking the difference in time between audio signals coming from Pianoteq and CL35. In order to make a fair comparison, we need to add 1.97 ms to those old values.

The PC was a laptop with an Intel Pentium 2020m processor. Finally, I took the measurements from this another post, https://forum.modartt.com/viewtopic.php...13#p967413 employing an ODROID XU4 (ARM processor, Raspbian Linux OS) with the UDJ6. This way we get four extra values for UDJ6 interface under Linux. I indicate these last values as 2020M and ARM.
It is worth mentioning that the delays measured with this procedure (timing between MIDI signal and sound) match perfectly with the ones measured with the Teensy microcontroller procedure mentioned before.

Generally speaking, I feel that latencies of about 10 milliseconds are OK. I don’t feel comfortable in those cases which latency is about 15 ms and above. I don’t know if anybody else experimented this, but I get my hands tired if I play with this latency.
To make a comparison, taking the speed of sound in air to be 343 m/s, 3 ms of latency are equivalent to 1.03 m of distance from speakers, so 15 ms of latency would be equivalent to have speakers at about 5 meters, which I don’t think is very far, but I started doing those measurements in 2013 because I noticed the latency (at that time, I thought that the word ASIO was a warranty of 0 latency).
It is interesting that driver ASIO4all performance varied widely for different systems with the same interface. The best option seems to be the internal sound card, but I must point that both ESI UDJ6 and miniDSP 2x4HD are not intended as audio interface for live playing, the first one is for DJs (not offense intended, but they don’t play in the same sense a pianist plays) and miniDSP is more an audio processor than an interface. I wonder how well would an entry level Focusrite / Behringer / M-Audio, etc. perform. By the other hand ALSA is not great but consistent among systems.

Appendix: values of latency

*miniDSP 2x4HD
M, Profile ‘minimum latency’, sample rate: 48 kHz, buffer size: 64 samples, latency: 10.6 ms
G, Profile ‘minimum latency’, sample rate: 48 kHz, buffer size: 64 samples, latency: 11.65 ms
M, Profile ‘minimum latency’, sample rate: 48 kHz, buffer size: 128 samples: 14.19 ms
G, Profile ‘minimum latency’, sample rate: 48 kHz, buffer size: 128 samples: 15.14 ms
M, Windows Audio Exclusive mode, 48 kHz, 192 samples: 23.28 ms
M, ASIO4all, 48 kHz, 64 samples: 13.84 ms
G, ASIO4all, 48 kHz, 64 samples: 15.36 ms
M, ASIO4all, 48 kHz, 128 samples: 14.3 ms
G, ASIO4all, 48 kHz, 128 samples: 16.4 ms
M, Linux (ALSA direct hardware without any conversion), 64 samples: 15.16 ms.
G, Linux (ALSA direct hardware without any conversion), 64 samples: 15.19 ms.
M, Linux (ALSA direct hardware without any conversion), 128 samples: 23.6 ms.
G, Linux (ALSA direct hardware without any conversion), 128 samples: 22.35 ms.

*Onboard sound chip
M, ASIO4all, 64 samples: 9.27 ms
M, ASIO4all, 128 samples: 12.6 ms
M, Linux (ALSA direct hardware     without any conversion), 64 samples: not usable (pops).
M, Linux (ALSA direct hardware without any conversion), 128 samples: 11.33 ms.
G, ASIO4all, 64 samples: 9.28 ms
G, ASIO4all, 128 samples: 11.88 ms
G, Linux (ALSA direct hardware without any conversion), 64 samples:  8.68 ms.
G, Linux (ALSA direct hardware without any conversion), 128 samples:  11.77 ms.
*ESI UDJ6
M, ESI driver, 48 kHz, 96 samples (interface default): 10.44 ms
M, ESI driver, 48 kHz, 128 samples: 12.66 ms
G, ESI driver, 48 kHz, 128 samples: 13.57 ms
M, ASIO4all, 48 kHz, 64 samples: 37.47 ms
G, ASIO4all, 48 kHz, 64 samples: 7.76 ms
M, ASIO4all, 48 kHz, 128 samples: 42.63 ms
G, ASIO4all, 48 kHz, 128 samples: 10.99 ms
M, ALSA (direct hardware without any conversion), 48 kHz, 64 samples: 12.10 ms
G, ALSA, 48 kHz, 64 samples: 12.06 ms
M, ALSA, 48 kHz, 128 samples: 20.33 ms
G, ALSA, 48 kHz, 128 samples: 20.5 ms
2020M, ALSA, 48 kHz, 64 samples: 15.9 ms
2020M, ALSA, 48 kHz, 128 samples: 15.9 ms
ARM, ALSA, 48 kHz, 64 samples: 12.1 ms
ARM, ALSA, 48 kHz, 64 samples: 20.3 ms

Yes perhaps there is not statistical significant difference, I should have added the standar deviations and the number of repetitions, but I was in lazy mode. As I wanted to do many measurementes and just for curiosity, I only made three o four of each, and sometimes there were up to 2 milliseconds of difference between consecutive measurements. I think there must be some kind of queue of events, plus some jitter, so you get what you get...

I think the point where the scan matrix detects the contact is a good approximation to the touch of key surface. I thought of placing a mic to capture the sound, but that would had been dependent on the speed (force) applied to the key.
By the way, could you paste the link to your post on MIDI jitter?
Thanks

Hello again,

the opposite of non-invasive is ...

I sacrificed a MIDI-cable, cut through one of its two wires and soldered a shunt (100 Ohm) between the ends. Your guilt, Marcos! ;-)
When a MIDI event passes I get a voltage over the resistor that I sent to the analog input of a soundcard. Not sure, if really needed, but to protect my soundcard I put a hum-destroyer/transformer at the input.

The Pianoteq sound generated by this MIDI event I sent to the second input channel of the soundcard.
Recording both signals (MIDI and Audio) shows the latency between both signals:

I repeated it more than ten times and always got 12 ms between start of the MIDI-byte and start of the Audio (as shown in the picture).

Of course the latency depends on the sample-frequency in PTQ, on my netbook I'm using just moderate 44.1 kHz with 64 samples.   

Some of the other parameters of the chain:
- 5-pin DIN MIDI-output of an old Goldstar GMK-49.
- MIDI-to-USB Interface Edirol UM-1SX
- Netbook CPU Intel N4200
- Pianoteq v7.2.0, Ant. Petrof Prelude (like to play Blues atm)
- Linux/alsa kernel 4.9.x (compiled)
- USB-Audio Scarlett 2i2 gen2

Cheers

Wow I hadn't seen this!
When you say you got 12ms, do you mean that the time was excactly the same?

Could it be related to focusrite drivers?
In this PW post, some years ago, I had found a relative standard devition between measurements ranging from 1.6 to 19%

edit: I forgot to paste the URL
http://forum.pianoworld.com/ubbthreads...._USB_.html

I'm having access to an oscilloscope in the meantime and tested another Pianoteq hardware. Although two main components have changed (CPU and USB-Audiointerface), I found again around 12 ms latency between incoming MIDI Note-On byte and generated audio:

Platform this time had been my Raspberry Pi 400 with ARM  Cortex-A72, PiOS 64-bit beta and the internal USB-Audiointerface of a Korg B2 Digitalpiano.

(my previous test had been with an Intel N4200 based Laptop, Debian Stretch 64-bit and Focusrite 2i2 gen2.)

In both setups the same MIDI-to-USB Interface (Edirol UM-1SX) was used at the input.

To generate cyclic MIDI Note-On events I used a software-sequencer this time (Muse).

The internal Korg audiointerface has a fixed samplerate of 48 kHz and so it had a small advantage in this competition against the 44.1 kHz that I used in my Focusrite rig.

Interesting discussion. In doing quick by the ear comparisons using analog audio sent back into the piano, so that I hear both the piano internal sound and the Pianoteq sound, what makes a difference in latency for me is the host sample rate, which can be different than the internal sample rate even when "direct sampling without conversions" is used. I use a PI4 with sound via hdmi but once converted to analog sound latency is negligible. I would also speculate that some of the usb jitter could be due to the polled nature of usb 1 and 2. Don't know about usb 3.

With the data from the previous posts (in this topic and the ones referenced), I've built some graphs. It seems that ALSA takes 3n the size of buffer (with n=1,2 or 3), depending on who knows (?). By the other hand, ASIO4all and the vendor's drivers show slopes between 2 and 3. Notice that except in the three trends lines I present, the slopes are calculaed based just with two points.

https://i.postimg.cc/x1XjHxrw/plot0.png

... an update with the Focusrite 2i2 gen2 on the Raspberry Pi 400:

Its trend line equation is f(x) = 6.1x + 3.3. Slightly lower latency, than the Korg B2 interface. Probably because the 2i2 gen2 supports the UAC2 standard and the B2 not.

You are right too, when you take the bar labeled 'Gfast internal' into account.  I guess that was the internal / onboard codec of your 'generic Chinese laptop (i7 4710mq)'.

I just meant all the USB-Audiointerface combinations we both examined. With Alsa we just found 6x or 9x the buffer size represented by the slope -- but not one with 3x.

So it seems at the moment that the README_LINUX.txt of Pianoteq is not applicable to USB-Audiointerfaces:

"With the Alsa driver, the latency is 3 times the buffer size (a buffer of 64 samples at 44100Hz gives a latency of 4.3 ms)."

But more important: Should 3n (with n=2 or 3) be the rule for Alsa+USB -- what is the deeper reason? The more I meditate on it, the more I'm confused