But what about the inherit knowledge that it’s there?
Having listened to John Watkinson on the subject of audio perception concerning 44.1kHz sampling and speaker design, I have learnt to question many of our perceived wisdom’s concerning digital audio and our need/ability to respond to stimuli.
Some people really do seem to have uncanny abilities,. Perfect Pitch is an interesting example. Bartok (it’s it claimed had tinnitus) and his affection for 2nd’s and sixth’s might be explained, imagine the curse of accurate perception in a sea of tone.
Once you KNOW something is there it can occlude much other enjoyment from what the completely artificial rendering of digital signals pertaining to be a musical instrument is capable of …
But relax! if the issue is resolved, the human mind will grant you the favour of hardly ever thinking of it at all.!!
I now hooked up the 3A power supply for the TinkerBoard S to my RasbPi 3 and set latency to 128 samples and 2 perioids. PianoTeq is not at all usable this way, setBfree creates some xruns, too. So, more power didn’t really help apparently.
Mhhh I’d like to have some box that runs PianoTeq, Dexed and Zynthian at 128 samples/2 periods but I think there’s n o RaspberrryPi that is strong enough for this.
Pianoteq at 128 samples is probably beyond the limits of any ARM SOC we can use.
But i don’t think that running it at 256 samples is so bad … come on!!! Simply put your monitors closer to your ears (or use headphones!)
5.6 ms, that is the difference between running at 128 instead 256 samples, is the time that sound takes to travel 1.9 m. So, typically, using headphones instead monitors will reduce perceived latency by 3 to 6 ms
Well… on stage I can add the delay of digital stage box and digital mixer to the latency… plus it doesn’t look that cool to use headphones (well, in-ear plugs maybe). Playing with 256 samples simply feels like the instrument is broken. Even at 128 setBfree doesn’t feel that right. I got this Korg CX-3 here from the 80ties, reparied it for a customer, now that is something that is reacting instantly… and so did my Oberheim OB3² (but then it died, well many years ago).
These are analog devices, and very good ones …
I doubt that zynthian can do it better than the original devices, but it can do it cheaper and smaller, certainly. And of course, zynthian can do “many things” …
Remember what zynthian is: a convenient micro computer for audio synthesis & processing. The limit is CPU processing power, and i’ts contrained by technology.
If you really want more power, then you should consider running zynthian in a Intel/AMD computer. It can be done too
Well, the OB3² was entirely digital, but didn’t sound as good as setBfree. The old Korg CX-3 is analog, that is true, but its sound is totally overrated. Tell me more about the x86 Zynhtian, though… Unclear to me is how to attach the display and encoders. Fanless x86 mini computers are not that expensive any more so this might really be an option.
I suspect, but do not know, that the x86 Zynthian is a wonder if project, rather than the route out of Raspberry Pi latency problems for zynths . . .
Mind you, if we swiss army enough who knows…?
I’m sure I remember someone saying jack ran on a PC, but realistically it would want on be a linux dist on the PC . .
12c connection isn’t native on a PC ( until some tells me it is … ) so it’s probably a software only exercise, I seem to remember there is a dummy controller code somewhere out there . . . Again this is jofe’s call but I think it would really slow down development to support it in Master. . .
Interesting concept thou’
A zynth per engine and Ethernet networking might be one way of getting the buffer size down to something you might find acceptable.
The problem, IMHO, is that latency isn’t constant, at 11ms it jitters between a few ms and 11ms (+ the latency of the keyboard USB connection to zynthian, I suppose). This personally drives me crazy and I can clearly feel a difference between 5ms and 11ms.
I think you could be right. Add an issue to GitHub describing the issue with as much supporting information as you can. There were some improvements in jitter a few months ago. I fixed an issue in step sequencer and @jofemodo applied a similar fix to the router but if you are still experiencing jitter then we need to track it down.
But I think the jitter is inherent to the way MIDI input and audio output are out of sync (similar to how a computer rendering video frames running without vsync is out of sync with the monitor). And I can’t sync my own playing to the audio buffer cycles, so unless there is indeed an extra jitter from processing USB messages that can be corrected, the only way to lower that jitter is to lower the audio buffer.
BTW, what I said isn’t correct the jitter doesn’t vary from a few ms to 11ms, but rather from 11ms to 22ms, which is quite significant to the human hear.
Unclear to me is how to attach the display and encoders. Fanless x86 mini computers are not that expensive any more so this might really be an option.