Hello guys,
I just started using PD and really struggle in understanding basic stuff.
I come from Reaktor and damn,PD is like Chinese to me for now.
I am just trying to send midi into [vstplugin~] from my keyboard [notein] and from another [vstplugin~] outputting midi and nothing works. I can send a note on\off with the [midi_note( and [midi_noteoff( messages , that works but what am i supposed to do to make the midi works from [notein] or another [vstplugin~] outputting midi? Am i supposed to convert the midi data into something else before it connects to the inlet?

Ok i managed to find some info,needed to use the [pack] object "i need to read on this!" with [notein] for the keyboard and played around with the [midi_note( message t0 convert the midi output of one [vstplugin~] into the other [vstplugin~]
All works but the midi has a big latency...not sure of this is normal or something in my setup.

@KoaN I have never experienced any midi latency of note with pd, I would expect it has something to do with your setup. Giving some idea of how long of a latency you are talking about, your midi setup and what OS you are on would be very useful if you want assistance in troubleshooting this latency.

@KoaN Well done getting it to work... and welcome to the forum.
Pd will introduce a small delay. The "control" messages... the non-audio messages like midi... are processed in between the audio blocks. The standard block in Pd is 64 samples.
That gives a latency of about 1.45 milliseconds. If you move one and a half feet away from another musician you hear what they play one and a half milliseconds later..... so that latency is not really noticeable.
It could be that you have a large audio buffer set for your sound card. On a computer one thing has to finish before another can be processed and audio has priority. Try to keep buffers as small as possible. If you make them too small you will start to get clicks as the computer fails to process audio in time... so it's a compromise.
With a pro soundcard with good drivers you should be able to reduce the buffer to 128 samples or maybe even less. Using the computer on-board sound card you will need a much bigger buffer to avoid clicks and so some noticeable latency.

You are unlikely to get help here with those exact plugins..... as someone would have to have purchased them. But other forums dedicated to plugins might well give you some pointers.
David.

@whale-av Thanks.

I tried a few things,different Vst,tried the [osc~] and same latency.Tried different Asio drivers,i am on windows 10 but anyway i don't have this much latency when i do the same thing in a different DAW.For example Plogue Bidule,exact same driver,same midi keyboard,same setup and the latency is the normal one i have with 512 samples where as in PD it is like 3-4 times more,well hard to measure by ears when i hit the key but it's not really playable.
I didn't intend to play live keyboard with PD but would be nice if i could get this to the normal latency with 512 samples.

That is the proper way to send midi to a synth right?

• Just to add, i used the first output of [notein] to control the frequency of an [osc~] and had the same latency.

Hmm i may have exaggerated with 3-4 times more latency...maybe more like 2 times.
I tried with plugdata and have the normal latency,i see there's no Asio in plugdata possible?
So i switched to wasapi in PD and it seems to be ok now?
After repetitive testing of hiting my keyboard and trying to evaluate the latency by ears i am getting a bit confused...hehe,i will continue testing this a bit later!

Ok did some more precise testing.
Used an external sequencer sending midi to PD triggering a click sample and did the same to Bidule triggering the same click sample....and PD is like lagging 4096 samples behind.
PD and Bidule using the same audio driver,same midi going in,same setup so i have no idea about this difference.

@KoaN In the File->Preferences->Edit Preferences... pop up, on the Audio tab, what have you selected for Delay (msec) and Block size?

@KoaN Thank you for posting what you have discovered. It will surely help someone in the future.

In windows you can start 2 instances of Pd.... one for audio and one for midi.... which can help as although the audio settings do affect the midi lag you can set one of the instances to run with a tiny buffer that would cause audio dropouts..... but use that instance purely for midi.
This can be done in other os's too.

The 2 instances can then communicate control rate messages using [netsend] and [netreceive].
A steep learning curve but you seem to be advancing rapidly.

The instances can be opened with a pre determined setup using command line flags.... http://msp.ucsd.edu/Pd_documentation/resources/chapter3.htm#s3.4.1

Here is an example of a batch file that should achieve this.....

start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -noaudio -midiindevice 2 -midioutdevice 2" start midi_patch.pd
start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -r 44100 -asio -nomidi -audioindev 9 -audiooutdev 9 -inchannels 18 -outchannels 22 -audiobuf 2 -blocksize 64 -callback -nosleep" start audio_patch.pd
exit

The paths will be wrong for your computer, so will need to be changed, and the command line flags will be wrong for your sound card, and probably for the midi devices too. For the sound card and midi devices you should first open your patch and open the Media AudioSettings and Media MidiSettings and write down the device numbers and settings for those found on your system as Ps starts up.
Then create an audio patch (-nomidi) and a midi patch (-noaudio) and change the command flags to match your setup for each.

BUT I cannot (so far) get the flags to work in a batch file opening 2 instances (works fine for one instance so it is my batch programming problem).
So copy the code above into a simple text editor like notepad, save it as e.g. "pd_twice.bat" and then edit it to match your Pd binary location and the Pd files you want to load to each instance. Once the 2 instances are open set the audio and the midi for the instances to something like this and do not turn on DSP for the midi instance.......
Keep the batch file with the Pd files you are loading in the same folder.

Of course your settings for the audio and the midi instances will be different..... different devices, different delay for audio.... but the midi instance can have the delay set to 1 (or maybe even 0) as it will not be running any audio.
As @jameslo says above...... in Pd the "Delay" setting is the buffer for communication with the sound card.
David.

@whale-av I'm guessing that when @KoaN writes about MIDI latency, what they are measuring is interval between when a MIDI note message is sent and the onset of sound from the plugin. That's why I'm curious about those audio settings, which I didn't see mentioned among their replies.

@jameslo Delay is 80ms and block size 64.
I tried lowering the delay but didn't seem to help much.

@whale-av Ouf,that sounds a bit complex yes...hehe. I will see a bit later about that.
I kind of feel it is not a midi issue though and maybe it's the whole PD engine having a bigger audio buffer? Is there a way for PD to show the latency processing?

The thing that led me to Pure Data is i wanted to try something similar to Bidule and see if it handled audio better,i had some crackling with Falcon Vst in some context with Bidule and in Pure data the crackling was gone...but it might be because the audio buffer is much larger,like changing the buffer on my audio card would make the crackles go away too but i didn't want to go above 512.
I read PD adds a bit of latency but +4096 samples latency doesn't seem normal?. I am testing this on a very old computer though and i need to test on my actual music laptop to see if it behaves the same way.
If PD doesn't end up being better for me that is ok too...i was just curious and wanted to try if it handled well my setup.