@ingox said:

latency-tester right,

it's not. here some fixes:

latency-tester2.pd

[throw~] and [catch~] do bring some latency with them as far as i know...

It depends on the execution order, described in 3. G05 of Pd documentation.

Patching like this has no latency for your 2nd and 3d version, as for dyncatch~ and throw~ chatch~ and s~ r~.

But there is other trouble with the 2nd and 3d version:
Deleting by 'dynamic-mouse-clicks' doesn't work if I use Pd's zoom-in, as I usaually do.
This is a bug of Pd: it messes up the coordinates.
Same happens if I undo after moving an object, it reappears somewhere else...

@ddw_music said:

In SC, I can arrange mixer channels in the order source --> target
[...] looks like the only way to force order is using an explicit patch cable

Not sure, but I belive only the order of objects is important, and even msend~ v1 could have 0 latency, if it would care about creation order!? Even across multiple patches? Creation order = execution order ?

Edit: yes and no: it's the creation order of the whole chain ...
in latency-tester2.pd:
[pd latency-meter] is the first object, [pd click] comes later,
... so deleting the patch-cord between [pd s] [pd r] brings back block-latency.

@ingox said:

[msend~] and [mreceive~]

yes!!!

@lacuna said:

dynamic patching:

but both introduce latency dyncatch~ 1 block, msend~ mreceive~ ~3blocks

http://www.pdpatchrepo.info/hurleur/latency-tester.pd

https://forum.pdpatchrepo.info/topic/7710/latency-on-output-and-input/2

@whale-av I opened the s~r~NoLatency patch I posted above and swapped the [-~] inputs. The latency (or lack thereof) didn't change.

Then I recreated the patch where every object is created in top to bottom order, the permutation in row 18 of the spreadsheet, and swapped the [-~] inputs. Again no change in latency.

If I've understood your theory, I think this disproves it, no? I wouldn't have guessed that audio sends and receives are simply replaced by audio connections by the interpreter because it would suggest that Pd's dsp loop detection is more sophisticated than what I've observed it to be.

If my conjecture in the original post is correct, then for any patch with non local signal connections (and that does not contain feedback), you should be able to make it latency-free with the following procedure:

{1] trace backwards from the end of the audio chain to the first set of [r~] or [catch~] you encounter. Cut and re-paste them.

[2] continue tracing from their corresponding [s~] and [throw~] until you reach the next set of [r~] or [catch~], if any. Cut and re-paste those.

[3] repeat [2] until you have nothing but audio chain heads. Cut and re-paste them.

This worked on a patch I made when I started investigating this, one that I decided was too complicated to be able to see what was going on.

Edit: This procedure also worked on a patch with delwrite~/delread~ to overcome the minimum 1 block delay: delwrite~read~.pd
You can watch the minimum delays go away by starting DSP, cut/pasting [delread~ delay2 0], then [delread~ delay1 0], and finally [phasor ~1].

@Harlekin If you want TouchOSC to control OBS you don't need Pd....... just connect TouchOSC directly to the ports of osc4obs and make your remote.touchosc layout file.

If you want to do some other processing in Pd then connect TouchOSC to Pd directly (in and out)...... and then connect your processed control from PD to osc4obs directly (in and out).
osc4obs facilitates that by creating separate OSC in and out ports.
You will have to do that also if you want to use TouchOSC and Pd in an either/or situation as osc4obs only has one set of osc ports and is making a tcp connection with OBS.

OBS websocket is a tcp connection and so it is possible that osc4obs is requiring tcp for the OSC connections...... in which case remove the -u flag from [netsend] and [netreceive] in my examples below.
It could also be expecting ascii instead of binary in which case remove the -b flag (but I doubt that)....

Externals for Pd are written in C so if you are adept there is some help in Pd/doc/6.externs .....
Basically you need to make a websocket client that replicates osc4obs with outlets and inlets instead of the osc ports.

BUT... you could try the iemnet [tcpclient] first (NOT the [udpclient]...!).... and that should work.
Just replace both [netsend] and [netreceive] with the one [tcpclient]...... connect it to OBS and look at the output using a [print] object.
If OBS is on the same computer the connect message will be [connect 127.0.0.1 4444(
Remove the password from the OBS websocket unless you find that a password can be added to the [connect( message for [tcpclient]...... before or after the port number? preceded by "password" or "passwd"?...... guesswork...... and [tcpclient] might well not accept a password as it is not mentioned in the help file.
Once you are looking at a print of the received messages the problem will be to decode the proprietary message format (it will not be OSC)....... it might be easy.... or not.
If lucky there will probably be the ascii strings you are looking for or a decimal representation of them somewhere in the message.

If you go the osc4obs route then it is quite easy to use [oscformat] and [oscparse] in vanilla instead of creating an external.......
...... vanilla osc.zip

P.S. try to avoid integers within the OSC address (header) as they arrive in Pd as symbols at the output of [oscparse] ....... and are then difficult to route. So what/ever/6 data is best avoided if possible and what/ever/six data is easier to deal with in Pd...... but I have included a solution in the zip file above.

Be careful in TouchOSC to avoid message feedback (much like midi feedback)......... and the same applies in Pd. In Pd you can include "set" at the start of a message (without the quote marks)...... which will set a message in the next object or message box but not send it onward until that object or message is banged.
David.

I know that using send~ and receive~ introduce latency

Not necessarily. You can in fact force the receive~ to be scheduled after the send~, in which case there is no latency, just like with delwrite~ and delread~.

and am wondering whether using subpatches via inlet~ and outlet~ also introduce latency.

No, unless the inner patch has a bigger blocksize than the outer patch. In that case, the latency is the difference between the two block sizes.

Does send (without tilde) introduce any latency?

"latency" doesn't exist in the message domain. When you send a message to [send], it is delivered instantly to all receivers. There is no semantic difference between using [send] or patch cords.

Does using subpatches rather than one big page introduce latency?

No.

Yes and a topic that I like very much.
We're in 2020! Like I always say, we sent a spacecraft to the moon with a 2.048 MHz computer

@cheesemaster said:

-Ubuntu Studio, maybe an RME PCI card

Why RME PCI, you can find good external soundcard, I guess it depends on the computer that you will choose (more on that later). Yes I like Ubuntu Studio, good choice.

-Really only doing audio (oscillators, arrays, filtering, delays) No graphics.

Perfect, start pd with -rt -nogui
Use [pd~] only if topping 100% CPU (pd is single thread).

-Keeping the the machine quiet (low fan noise) is VERY important.

Fanless is possible, again depending on the computer you choose.

What CPU specs matter most for common audio and MIDI tasks in PD? Number of cores? Thread count? Clock speed?

Clock speed = lowest latency (you can push jack to buffer 64) without xruns. If you are not playing live (for example using ADC) you don't need low latency configuration (I am lucky and not very good at detecting latency, my setup is around 38ms (round-trip). You can detect latency using jack_iodelay.

RAM is important if you want to load samples in PD in advance (avoiding glitches).

NVMe SSD if you can.

If I run other apps (VCV rack, Carla, various Jack plugins) will those processes distribute to the other Cores?

Yes, again Pd is single thread. Others are usually better (GUI on a separated thead for example).

Does Pd benefit from a more powerful GPU card? Or will there be no difference if I use the GPU embedded in the CPU? Is it different if I launch Pd without the gui? (-nogui)

If you don't use Gem you don't need a dedicated GPU card.

Here's some ideas for you, I've been building some setup over the years:

Theremin à crayon:

Using a Surface Pro 3 running Ubuntu Studio with a "old" USB 1.1 sound card. Heavy patch using lots of software : Bitwig, SooperLooper, Guitarix and of course PD. Midi (PD), OSC (Bitwig, SooperLooper). Very quiet but the Surface gets hot (fans are kind of quiet like a good laptop).

Heavybox:
https://www.workinprogress.ca/projects/heavy-box/

Similar setup, a quiet PC using a big heat sink and a overrated power supply so the fan never start. Noctura fan on the side (expensive but quiet). Old soundcard (firewire) but I can do low latency. 8 ins/8 outs.

Biscuit box computer:
https://www.workinprogress.ca/biscuit-box-computer/

Mini-pc not quiet, not very fast in this case a cheap usb soundcard (you know +- 8$ barely better than the embedded one).

Phimatics:

A raspberry pi 2 with wolfson audio card. Using only PD with Alsa, I am getting very good result (low latency) quiest setup. But of course I need to be careful with the CPU.

JAS:

Working on a new project, I found this midi keyboard in the trash / snow. I will put Khadas VIM version 1 (ARM) with a BEHRINGER UCG102 (usb soundcard for guitar). Quiet, no fan can be run on a battery (5V). Will post the project when over.

Lattepanda:
Never worked with it, but looks very powerful. There's a price tag. Maybe for the next project.

Cheers

@MDobleZ Pd will give you 1.45ms of additional latency at its standard 64 sample block size.
But the round trip os latency will depend on the phone and its settings. Google finds some fixes for phone latency but they cannot be universally applied....... and your students will have to apply them to their phones.
Distortion is obviously not normal. But if you set the audio buffer too low..... so as to reduce latency.... you might have introduced distortion.
Even an app like this....... https://play.google.com/store/apps/details?id=com.google.android.accessibility.soundamplifier&hl=en&showAllReviews=true presumably written in Java, will probably have too much latency (there are complaints in the reviews).
David.

@jancsika said:

Where is the specification for ableton link?

Relevant bit is: https://github.com/Ableton/link#latency-compensation

"In order for multiple devices to play in time, we need to synchronize the moment at which their signals hit the speaker or output cable. If this compensation is not performed, the output signals from devices with different output latencies will exhibit a persistent offset from each other. For this reason, the audio system's output latency should be added to system time values before passing them to Link methods."

abl_link~, by default, doesn't do this. But, at https://github.com/libpd/abl_link/issues/20, I was told that [abl_link~] response to a "offset $1" message where a positive number of milliseconds pushes the timing messages earlier.

Using that, it's actually easy to tune manually.

This was undocumented -- intentionally undocumented, for a reason that I can't say I agree with. So I'll put in a PR to document it.

Also-- Assuming that arbitrary devices are to be able to connect through ableton link, I don't see how there could be any solution to the design of abl_link that doesn't require a human user to choose an offset based on measuring round-trip latency the given arbitrary device/configuration. You either have to do that or have everyone on high end audio interfaces (or perhaps homogenous devices like all iphones or something).

As far as I know (and I haven't gone deeply into Link's sources), Link establishes a relationship between the local machine's system time and a shared timebase that is synchronized over the network. Exactly how the shared timebase is synchronized, I couldn't tell you in detail, but linear regressions and Kalman filters are involved -- so I imagine it could make a prediction, based on the last n beats, of the system time when beat 243.5 is supposed to happen, and adjust the prediction by small amounts, incrementally, to keep all the players together.

Then, as quoted above, it stipulates that the sound for beat 243.5 should hit the speakers at the system time associated with that beat. The client app knows what time it is, and knows the audio driver latency, and that's enough.

So, imagine one machine running one application on one soundcard with a 256 sample hardware buffer and another app on a different soundcard with a 2048 sample hardware buffer. The system times will be the same. If both apps compensate for audio driver latency, then they play together -- and because the driver latency figure is provided by the driver, the user doesn't have to configure it manually.

The genius of Link is that they got system times (which you can't assume to be the same on multiple machines) to line up closely enough for musical usage. Sounds impossible, but they have actually done it.

Put another way-- if you can figure out an automated way to tackle this problem for arbitrary Linux configurations/devices, please abstract out that solution into a library that will be the most useful addition to Linux audio in decades.

Ableton Link actually is that library.

https://github.com/Ableton/link/blob/master/include/ableton/Link.hpp#L5-L9

license:
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.

@toddak I use TouchOSC for Android for a monitor control system I built 6 years ago.
Originally it controlled Pd Extended using MrPeach objects.
I have nearly completed an update for Vanilla. My problems left to solve are not with the comms..... TouchOSC is working fine with Pd Vanilla, and is probably still the best app for OSC and midi control.
Pd updates the TouchOSC interface too, changing fader names and colours for example.
I can certainly help you with that.

Here are some objects I built...... MrPeach Vanilla.zip..... that can directly replace (apart from [routeOSC]...... see the note inside) some of the Extended MrPeach objects. They have the same names as the MrPeach OSC objects and the contents of the zip can be tipped into the same folder as an old Extended patch to make it work in Vanilla...... apart from [routeOSC] where you will have to add a [route] after its output.

I originally used [dumpOSC] to receive from TouchOSC (it was in the old TouchOSC help file) and so that is the object that I replaced.
Obviously it needs an argument so...... [dumpOSC 8000] I think matches TouchOSC as it is download "out of the box".......... pretty sure it sends to port 8000.

This is the setup for one of my tablets....

Anyway.....
Host is the IP of the computer TouchOSC will be talking to (the one running Pd).
Port (outgoing) is the port for sending to Pd..... in this screenshot you would use [dumpOSC 8099] in Pd.
Port (incoming) is the port you would send to for updating TouchOSC.... so from Pd to 192.168.1.199 port 9000.
Local IP Address is filled automatically (it is grabbed from what you set in the ios) .... and also ZeroConf name (I think).
The zeroconf name is the broadcast name for finding devices by name rather than IP..... like DNS on the web..... but it can be ignored and it is better to fix your IP addresses inside your private network as you will not be relying on any "lookup" service that might not be running or could have a corrupted cache..
Then just make a patch like this and you will see the messages arriving in Pd terminal....

David.

@Joseph-Mikkelson No, changing the samplerate will not help, except that matching it to the soundcard reduces the load on the cpu......but there are more important issues...... see below.....

I should have expanded on latency.
Using a live input [adc~] and doing some Pd processing effects and then sending that to speakers [dac~] latency is not so much of a problem. Often it involves delays anyway (echo, reverb, etc.) and our ears are used to that.
Latency for playback of an audio track, or generated audio, is no problem...... it is heard when it arrives at the speakers and that is all.
Problems arise when the input goes straight to the output....... as with a monitor mixer built in Pd for example..... with live acoustic instruments...... where the musician hears their own instrument acoustically and the same sound delayed in the monitor. Essentially a chorus effect is produced, caused by the latency, and that will make it harder for a violinist for example to pitch correctly.
Chorus in a reverb effect really upsets violinists..... anything much over 5ms.
Of course a massive latency...... 100ms+..... will cause timing problems even for a guitarist, and even if they are the rare musician that didn't have such issues in the first place.
I have met classical and jazz musicians that have learnt to dissociate what they play from what they hear...... for example playing through a delay, but in sync with everyone else...... so playing say 1 second before everyone else....... but......

SAMPLE RATE
You should match your samplerate to your soundcard, or you will have re-sampling artefacts....... usually a low level high pitched whine when your patch is not producing any sound.
It is slightly more complicated than that.
If you play an audio file that was recorded at 44.1KHz while the Pd samplerate is set to 48KHz it will play back at the wrong speed....... Pd will not resample it and so the pitch will be wrong.
It's a PITA.
So the Pd samplerate must be set to match all the audio files that you use in Pd.
To avoid the artefacts you then need to set your soundcard to match Pd.
Other programs will adjust..... so that is not a problem.
External cards can make that change through their control panel, and internal cards should have the option somewhere.
In windows it is here in the speaker control panel..... https://forum.pdpatchrepo.info/topic/12094/newbie-clipping-on-pure-data-portable-with-mmio/4
and I am pretty sure that windows always sets the on-board soundcard to 48KHz "out of the box".
David.