Hi,

I have been wondering why is PD's MIDI output so jittery and why it has so many problems with note-offs not working properly (hanging notes every few dozens of notes, with fast sequences even more often).

I have recently tested a simple MIDI out patch in Max 7 and its MIDI output is rock solid no matter what. No hanging notes, no noticeable jitter. It is the major thing that is making me considering purchasing Max 7 but I have also found out, during the testing, that it really crashes a lot while doing basic things so I would stay with PD if the mentioned MIDI output problems are fixable.

Can there be anything done in/with PD that would make MIDI out solid as in Max 7?

I really really want to love PD but this is a major bummer. I really need to output MIDI to a DAW.

Thank you.

Hi Mr. Slow,

I would suggest you to contact the developers to ask about this problem in the mailing list to see if they have any tips on how to solve/improve this situation: http://lists.puredata.info/listinfo/pd-list

Cheers,
Gilberto

the output itself is not causing the jitter as far as i know. objects like metro and delay are not producing an exact timing. in pd there is an object to measure the elapsed time between to bangs called [realtime]. i dont know how accurate it is. but if you hook it up to metro or delay you will see ultraLARGE differences in the timing.

on linux you can fight against this problem with an realtime kernel, but it doesn't solve the problem completely.

in the help-patch of the normal [timer] object, which measures elapsed logical time there is the nice hint to this inaccuracy :

The Timer object measures elapsed logical time. Logical time moves forward as if al computation were instantaneous and as if all "delay" and "metro" objects were exact.

so if you want to get a good timing within pd nowadays you will need to sync to an external source, like the "96 step" signal wich is emmited by most daw's. there is an objects wich can receive this signal within pd-extended but i cant find it at the moment.

almost forgot about the -nosleep and -rt startup flag. if you start pd with them you will also get an better overall timing of events

and the object for the clock input is called [midirealtimein]

MIDI Real Time Bytes:
248 = pulse
250 = sequencer start
251 = sequencer continue
252 = sequencer stop

Thank you, Tom, I will check your suggestions.

However, I am afraid syncing PD to an external clock (at least in Windows) will produce even more inaccuracies because the data have to be sent between two applications (and through the OS). Or am I mistaken?

I can give it a try, though.

it can and most likely will. each operating system has an internal frequency at which it can send information from one application to another. so i could also produce different results at different sequencer speeds. but i believe that i could work and is worth a try.

i can't imagine what the people at cycling74 of max could have done to achieve a rock solid timing...but we weill maybe never know until someone break into theyre sources.

and by the way... not only in windows i changed to linux to get finally full control over what my system does, but still got a long list of things that have to be changed to be used as a serious "production tool"

@tomchaossen said:

and by the way... not only in windows i changed to linux to get finally full control over what my system does, but still got a long list of things that have to be changed to be used as a serious "production tool"

Can you name a few for a Windows user? This is quite demotivating to read, though...

on windows i was able to do what i want within ableton / cubase / Reaktor or any program itself...no problems. but i was not really able to build something that works god as an bridge between applications (except rewire). i tried all the midi-stuff to interconnect, but it was not really usable cause i had to setup everything everytime again, and sometimes a midi bridge won't work, or i wasn't able to interface to opensoundcontrol things like touchOSC with some application (especially ableton). but my ultimate goal was to get rid of all the audio cables in my system. laptop to my mastering compressor for example. or other stuff that need a cable. so i needed a solution like jackAudioConnectionKit which can work over network which is great if you put a arm-based oneboard computer in each component of your chain and connect them over network... i hope this wasn't demotivating.

what are you exactly trying to build so that you want to control you DAW externaly vi pd

I simply need to send tight MIDI events and tight control events (FX automations, etc) to a DAW that will record it. I want to jam with algorithms in PD and be assured that it will be recorded exactly as I heard it during a jam. I would also like my DAW to be in sync with PD, but that is a huge problem...

you need to lower your blocksize in the Audio-Settings of PD to the minimum. The Bangs and all control signals in PD are processed with each block of audio.

blocksize = 64
i get ca .+/- 5 ms in the timing on input and output. your ears shoudln't notice this difference in a bad way.

Thank you for the info.

5 ms is quite a lot, in my opinion (as it could create a different feel in music when a lot of tracks is involved, or when transient control is the key).

I still have not tried setting up PD VST but I suppose it should be the tightest way of generating MIDI into a DAW. What you think?

i don't really know. after a few coffes i remembered that the PDvst ist either an instrument or an effect. i don't think its possible as a kind of midi effect.and please believe me, 5ms are really not much. you shouldn't be able to recognize it. the human ear can recognize differences above 25 ms in an not continous signal. i would give it a try.

for example: the minimum attack stage of an envelope in vst plugins ist about 5 ms too, to surpress clicking on unsynced oscillators

and you can always download the trial for maxforlive to check if its better.

ahh...but you can use PDvst as instrument with an similar patch as mine to determine the real timing within your daw.

Unfortunately, I produce a lot and I know for the fact, that 5ms difference is perfectly audible if you deal with sharp transients. If you have two tracks of sounds meant to play together with prominent transients and peaks, 5 ms drifting would create a huge sonic difference.

I will try the PDvst and see how stable and usable it is. I just can't bring myself to install and set it up properly, yet.

in addition to the one time per block processing of messages, incoming and outgoing messages are delayed by on block each time they pass the borders of PD to the world