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

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

messages in anykind within and outof PD are emitted max. one time per DSP block. this causes slighty noticeable jitter if the blocksize is too big. maybe [block~] with lower value in subpatch can resolve it a bit more, but i havent tested it yet.

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

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.

i'm not familliar with the streamin/out object, but you could try to use the [udpsend~] and [udpreceive~] from the mrpeach externals. i use them to stream audio to my beaglebones inside my audio hardware to avoid cables that immobilize my laptop. never hd any problems with them.

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.

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.

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

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"

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 the object for the clock input is called [midirealtimein]

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

youre welcome, I hope you will achieve your goals

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

awesome why didn't i find them before ......(not a real question)

jips, it only use more cpu time to process the 4x interpolation

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.

tabplay~ ist for the one-shot play of a soundfile or table

tabread~ and tabread4~ is for samplespecific readout of a soundfile to perform all you can imagine with the contents of a table

tabplay~ will be faster ause its reads out of a buffer which is already filled with data within pd
readsf~ have to locate the file, wait for your hardrives to be ready to read it, the read it into pd and from this point on its much like tabplay~

for your drummaschine it would make no real sense to use tabplay4~ if you only play at the original speed, but if you want to change the speed just a litle tabread4~ would be wise to use

it appears so that there is the possibility to embedd metadata within some audio-file-formats
https://en.wikipedia.org/wiki/Audio_file_format#Format_types
but the [soundfiler] object doesn't read them.

i would be delighted if i'm wrong and hope to hear about an solution.

on which system are you working? if you are on linux you can use the shell object in pd and use the "free" command to get the systemwide memory usage