Re: [PD] accuracy of signal/message-objects
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: This interval also is independent from the blocksize! You can check this with attached patch Now you can... Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ blocksize-messages.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, marius schebella hat gesagt: // marius schebella wrote: does this all make sense? smaller blocksizes give you the possibility to handle messages in even shorter time intervals, bigger blocksizes may help to declick for example when you write to arrays. [for some objects blocksize is even more important (fft~, tabsend~).] I think, it may be easier to explain this from a practical point of view. I'll give it a shot: * First axiom: Pd's messages are deterministic, also in time. What does this mean? All messages *inside* of Pd are handled with (almost) complete accuracy. If you have a bang going through a [del 0.3] and going through [del 0.299] then you can be sure that Pd triggers the 0.299-bang 0.001 msec before the 0.3-bang, regardless of what your blocksize or so is. It would be terrible and lead to lots of nasty errors if you couldn't rely on Pd to schedule events in that fashion. * Second axiom: The GUI is updated or polled less often. It would be a complete waste of ressources to update the GUI or poll GUI elements for changes every sample or every 1/44100 seconds. So currently events coming from the GUI are only read once every 64 samples. This interval also is independent from the blocksize! You can check this with attached patch by setting the blocksize to some really big value like 23 seconds and bang the [random 8]: You don't have to wait 23 seconds to get the result. Also with the [timer] object in that patch you can see the quantization of GUI messages to 64 samples. * Third axiom: Converting between messages and signals is tricky. As you've explained so well, DSP signals in Pd are calculated in blocks of several samples in one go. Normally 64 samples are one such block, but even with a blocksize of only 1 sample it would be tricky to convert messages to signals correctly, because even one sample takes a certain time (1/SR seconds) to compute. Generally DSP objects calculate a complete block and cannot react to messages in between that time. The messages themselves are scheduled correctly (Axiom 1) it's just that most DSP objects don't listen for messages during their computation time. Some DSP objects however actually can react quicker than a block: [vline~] and [vsnapshot~] are the prime examples. They use a little trick to do so: While they still calculate a full block in advance like everyone~ else, they know beforehand when messages are scheduled to reach them possibly in the middle of such a block and they calculate their sample block with these future messages in mind. This is possible for messages, that are scheduled to be send at some future point in time. For example a [metro] generates this kind of message: When a [metro 500] bangs, it also instructs Pd to bang again after 500ms. [vline~] then can ask Pd: Are there any messages scheduled for me during the next block? and because Pd knows about that scheduled [metro]-bang, it can tell [vline~]: Yes, there is one bang waiting for you 0.526 msec into the next block. Please take this into account! The normal [line~] object doesn't ask Pd about such scheduled messages and as such is faster to compute. If you just need to declick some value from a slider, then you can just use [line~] instead of [vline~] because slider events don't happen faster than 64 samples anyway. But if you build a drum machine that is driven by [metro] , you should really use [vline~] to get a drumset, that is not only good enough for acousmatic music, but also good enough for Jazz, as Eric Lyon once put it. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
First of all thanks for all the elaborate explanations. They are all greatly appreciated! On 08/05/2007, at 20.06, Roman Haefeli wrote: On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote: I understand that decreasing the block size will possible requirer more computation/logical time then there is real time enough to complete. what do you mean by computational time? logical time and the time, the cpu needs to compute something are not the same. Sorry. I meant the time it takes to compute the DSP. And therefore that the information in a block is available to the program to process. Which also means that after that block has been processes the information is not longer available. Is that true? i am afraid, i couldn't fully follow. What i was thinking about is the information in each block, ie the samples in each block are forgotten about when the computation/DSP of that block is done. I'm guessing this, since some object, i guess again, depends on the block size, that is the samples in the block. For example if one wants to compute some mean value. - Does the block size then become the 'window' size, where window is used as the theoretical term in DSP? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, Steffen hat gesagt: // Steffen wrote: And therefore that the information in a block is available to the program to process. Which also means that after that block has been processes the information is not longer available. Is that true? i am afraid, i couldn't fully follow. What i was thinking about is the information in each block, ie the samples in each block are forgotten about when the computation/DSP of that block is done. Yes, it's gone then. But so are messages. Btw.: the [tabsend~] and [tabreceive~] objects directly operate on the sample blocks we're talking about here, as does the [print~] object, so if you want to see or influence what's happening in a block, use these. I'm guessing this, since some object, i guess again, depends on the block size, that is the samples in the block. For example if one wants to compute some mean value. - Does the block size then become the 'window' size, where window is used as the theoretical term in DSP? You mean window as in for example a FFT? Yes, that is equivalent to the block in Pd. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Frank Barknecht wrote: Hallo, Objects like [delay] or [metro] produce these clock-delayed messages. They register their clocks with Pd's main scheduler using clock_new(...) and then order the scheduler to generate the clock-delayed messages like the metro-bangs using clock_delay(). The actual output of [delay], [metro] etc. then is initiated by the scheduler which calls the registered clock methods: delay_tick(), metro_tick(),... However I must admit, I'm not sure how this relates to comport and if comport should also register its port-writing-method with a clock and let the scheduler tick the clock and initiate the writing and if that could get rid of the jitter you mentioned. no, this won't work. [metro] is arbitrarily accurate within pd-land: here we deal with logical time, where the execution of a message (and everything it triggers directly) is happening in zero-time by definition. in the world outside, there is no logical time, there is only the real time, where the execution of messages takes some cpu-cycles and thus real time. messages are dealt with during dsp-cycles (in fact, dsp-cycles are dealt with in between msg-cycles; this is why a message-overload can lead to click, when one dsp-cycle has to be dropped). in real time messages are executed in bursts, but for each message in the burst the logical time will be correctly set. this is all fine as long as you don't have to deal with the world outside: the only place where this is handled somehow correctly is with audio: pd writes the samples (who live in logical time land) into a buffer; the soundcard reads this buffer in sync with the real time. as long as the 2 time references are roughly in synch everything goes well; when they get badly out of synch (driftbuffersize), you will get audio-dropouts. when dealing with other world outside interfaces (e.g. parallel/serial port), there might be no such mechanism: whenever some data is sent to the port (regardless of the logical time) it is visible on the other side in real time; this might appear in bursts and have a jitter. the only way to overcome this is to create a buffer that synchs the two time references. a simple way to do this is to just overdrive the port a little bit, so that your operating system's port buffer is always filled. At least normal objects like [float] don't do any funky clock-stuff and still don't disturb the correct timing of clock-delayed messages. because they do not interface with the world outside. mf.asr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote: because they do not interface with the world outside. I feel that i don't interface with the world inside. I would greatly appreciate if someone would translate the scope of this discussion into noobish. I sense that it's not that hard to grasp the scope once getting the 'aahh' experience. Like when you look at a map (of the world, you thought) but can't find out what part you are looking at and think this is a fictive map until some kind soul points and says that bit is water, the other is land. (I've tried that, it very embarrassing but then thats ruled out...) Or just ignore this email. Best, Steffen ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Steffen wrote: On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote: because they do not interface with the world outside. I feel that i don't interface with the world inside. I would greatly appreciate if someone would translate the scope of this discussion into noobish. sorry if i confused anybody. unfortunately i am not very good at explaining things in simple words; anyone else wants togive it a try? mfga.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: unfortunately i am not very good at explaining things in simple words; anyone else wants togive it a try? Pd is nirvana, comport is the harsh reality. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Tue, 2007-05-08 at 13:12 +0200, Steffen wrote: On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote: because they do not interface with the world outside. I feel that i don't interface with the world inside. I would greatly appreciate if someone would translate the scope of this discussion into noobish. I sense that it's not that hard to grasp the scope once getting the 'aahh' experience. Like when you look at a map (of the world, you thought) but can't find out what part you are looking at and think this is a fictive map until some kind soul points and says that bit is water, the other is land. (I've tried that, it very embarrassing but then thats ruled out...) Or just ignore this email. i think, i understood, what IOhannes explained, though i am not a coder. but this is more an issue of concepts than of code itself, i think. before i give it another try to explain, i would like to know, what exactly you did not understand. could you elaborate that a bit more (if that's possible for you, of course)? i mean, is it the difference between logical time and real time ? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Steffen wrote: On 08/05/2007, at 9.19, IOhannes m zmoelnig wrote: because they do not interface with the world outside. I feel that i don't interface with the world inside. I would greatly appreciate if someone would translate the scope of this discussion into noobish. hi, think of it as Pd being a tool also used for non realtime renderings. in fact it is possible that Pd renders everything to a soundfile and not to the sound card. so if you have very complicated computation which cannot be done in real time because the cpu is not fast enough, that data would still be written to the soundfile without clicks. and that is because pd has its internal predictable time. if you want to trigger a message with 1000 milliseconds delay then you want to use the internal time measurement. for example if you load a 2 hours soundfile into a buffer in the first millisecond and start playing it that usually would cause Pd to clip and that is because it takes a while until the sound file is written to the buffer. Pd cannot continue with its internal measurement until all messages are finished executing. that is an example where internal time and world time would drift. the internal time is cut into pieces of 64 samples (at 44.1 khz sampling rate that is 1.6 ms). then the samples are sent to the soundcard (clocked by the soundcard) and then the next rendercycle of 64 samples starts. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On 08/05/2007, at 14.36, Roman Haefeli wrote: i think, i understood, what IOhannes explained, I'm sorry i wasn't cleat about what i didn't understand. By this discussion i mean to refer not only to IOhannes mail but the whole thread. Confusion Is Sex, they say. So i guess it's not necessarily a bad thing. but this is more an issue of concepts than of code itself, i think. I think so too. Hence my map example. is it the difference between logical time and real time ? No not really. And Marius gave a good shot explaining that. Marius also ends out with some explanation of the 'block' concept. I think that what i don't really get. I understand that decreasing the block size will possible requirer more computation/logical time then there is real time enough to complete. And therefore that the information in a block is available to the program to process. Which also means that after that block has been processes the information is not longer available. Is that true? What is a block, what's in it, what properties does it have. Is a block a sample or is a block made out of a number (being the block size) of samples? And also Jamie's question: what does the 'v' stand for? I suspect there is some digital music fundamentals that I'm lacking. Thanks for your patients, all of you. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
what happens in a block cycle? first all dsp computation is done, then all new messaging is handled: usually 64 samples of digital (audio) signal are blocked together. so lets say you have a line~ object that received a message [0, 1 10( before the new block started. so that is executed beginning with the first sample of the block cycle. lets say the line~ is directly connected to an [dac~] object. so there is a buffer of 64 samples and the first of these samples is filled with 0. then (still dsp computations...) the next value of line is calculated, which will be dependend on the sample rate settings (let's say 44.1k) so 1 sample is 1/44.1 ms, which will give the next rampvalue of 0.00227 (you will reach 1 after 441 samples). in this way 64 samples are written to the buffer. 0, 0.00454, 0.00680... during all these calculations no new messages are handled. [v messages have a slightly different behaviour here] finally (that is varying depending on the sound card driver and operating system you are using) this buffer goes to the soundcard. THEN: after all that dsp stuff is done, the messaging process is turned on. interface events (even if they are received and saved during dsp computation) will only have effect for the beginning of the next block. the whole messaging process will set a lot of new values that will interact with the next dsp computations. for example our line object might receive new values... does this all make sense? smaller blocksizes give you the possibility to handle messages in even shorter time intervals, bigger blocksizes may help to declick for example when you write to arrays. [for some objects blocksize is even more important (fft~, tabsend~).] marius. Steffen wrote: I understand that decreasing the block size will possible requirer more computation/logical time then there is real time enough to complete. And therefore that the information in a block is available to the program to process. Which also means that after that block has been processes the information is not longer available. Is that true? What is a block, what's in it, what properties does it have. Is a block a sample or is a block made out of a number (being the block size) of samples? And also Jamie's question: what does the 'v' stand for? I suspect there is some digital music fundamentals that I'm lacking. Thanks for your patients, all of you. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Tue, 2007-05-08 at 18:37 +0200, Steffen wrote: Marius also ends out with some explanation of the 'block' concept. I think that what i don't really get. I understand that decreasing the block size will possible requirer more computation/logical time then there is real time enough to complete. what do you mean by computational time? logical time and the time, the cpu needs to compute something are not the same. And therefore that the information in a block is available to the program to process. Which also means that after that block has been processes the information is not longer available. Is that true? i am afraid, i couldn't fully follow. i'll try to explain it in my own words and hope that i don't tell too much rubbish, cause this is only what i assume, how things are: a block is a number of numbers, in pd these numbers are 32bit floats. the usual blocksize is 64samples(=floats). audio signals are passed blockwise between tilde-objects, that means a tilde-object receives 64 floats on its inlet, then processes all 64 samples and then sends them to its outlet. this happens each tick for the whole dsp tree. each tick, a whole block is processed by the first object, then passed to the next object, processed by this object, passed to the next and so on. i assume, the cpu overhead, when decreasing the blocksize, comes from the communication between the tilde objects. if the packagesize is smaller, more packages need to be passed to process the same amount of data in the same time, so more exchanges between tilde objects are needed. every tick, the 'message tree' is processed as well. so, in logical time, messages always 'happen' at block boundaries. for example, when a number is sent to the left inlet of an [osc~], the [osc~] changes its frequency exactly on the blocksize boundaries. so, in logical time, messages take effect only every 1.45ms (when running pd at 44100Hz). in real time, you can't tell when exactly something is processed, it can vary between immediately and the maximum of your soundcard buffer setting. the sound card reads the samples from the buffer at a fixed rate (the samplingrate), whereas pd does fill it at a speed, that depends on the cpuload. although pd does compute things at nondefined times, the output (of your soundcard) seems well timed, because pd puts the samples in the right order into the buffer. What is a block, what's in it, what properties does it have. Is a block a sample or is a block made out of a number (being the block size) of samples? And also Jamie's question: what does the 'v' stand for? i think, in [vd~], it stands for 'variable' (delay). i don't know, what it means in [vline~] and [vsnapshot~], vector maybe, because the messages, they receive can have an effect within the vector (read:block), not only on block boundaries. these two objects are special, because when they receive a message, that was initally triggered by a [del] or a [metro], it has an effect within the block, because the messages generated by [del][metro] are tagged with some timestamp (is that correct?), so that [vsnapshot~]/[vline~] know, for which exact time they are meant to be executed. if i understood IOhannes correctly, he said, that other 'translations' from pd to the 'real' world beside sending data to an audiocard cannot be timed accurately, since they lack a fixed rate, like an audiocard has it. for example, if you are talking to an arduino board, it will process the data as soon as it gets it. so if the cpu load is currently a bit higher, it will get the data probably a bit later, than when cpu load is small (is that right, IOhannes?). let's say i am running pd with a buffer of 100ms and the patch switches often between high and low cpu-load (for example it does load some audiofiles into arrays from time to time). would that mean, the maximum jitter of the arduino outputs is 100ms, although i don't have any dropouts in the audio? is that correct? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. wow, great news again how did you find out about this? it is not mentioned in the release notes. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... oh, hm... indeed, strange. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value. roman On Mon, 2007-05-07 at 09:40 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao #N canvas 546 0 366 477 10; #X floatatom 12 131 0 0 0 0 - - -; #X obj 12 109 vsnapshot~; #X msg 13 53 10; #X obj 69 79 metro 100; #X msg 69 56 1; #X obj 13 76 phasor~; #X obj 13 20 loadbang; #X floatatom 12 319 0 0 0 0 - - -; #X obj 12 297 vsnapshot~; #X obj 13 264 phasor~; #X obj 13 208 loadbang; #X msg 13 241 50; #X obj 69 267 metro 20; #X msg 69 244 1; #X obj 12 348 t f f; #X text 7 178 is this the rounding error of floats?; #X obj 11 373 -; #X floatatom 11 397 0 0 0 0 - - -; #X text 10 424 why this discontuinities?; #X text 9 158 phasor (10Hz) and metro (100ms) do drift apart.; #X connect 1 0 0 0; #X connect 2 0 5 0; #X connect 3 0 1 0; #X connect 4 0 3 0; #X connect 5 0 1 0; #X connect 6 0 2 0; #X connect 6 0 4 0; #X connect 7 0 14 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 11 0; #X connect 10 0 13 0; #X connect 11 0 9 0; #X connect 12 0 8 0; #X connect 13 0 12 0; #X connect 14 0 16 1; #X connect 14 1 16 0; #X connect 16 0 17 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects (was: Switch and ramp and accurate timing)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: wow, great news again how did you find out about this? it is not mentioned in the release notes. Use the source, Luke: I was considereing to code my own vsnapshot~ and looked into d_ctl.c where I found, that Miller already did it. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Roman Haefeli wrote: i made a little vsnapshot~ test patch. it seems that [vsnapshot~] is not working as expected, though it definitely gives other results than [snapshot~]. i think it is working as expected but there are 2 things to bear in mind: one issue might be introduced by the rounding error of floats. the other i cannot explain. vsnapshot~ seems to pick sometimes the wrong value. [vline~] and [vsnapshot~] do not work exactly alike, because of this vexed causality when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples. the only way to overcome this, is by delaying the sampling bang by one dsp-block. the other thing with the irregularities is simpler: even when messages have sub-sample accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is in sync with your samplerate. see also: shannon's sampling theorem attached is a modified patch fm.asdr IOhannes #N canvas 195 55 722 477 10; #X floatatom 12 296 0 0 0 0 - - -; #X obj 12 279 vsnapshot~; #X msg 72 206 1; #X obj 74 236 vmetro 100; #X msg 42 205 0; #X msg 13 127 bang; #X obj 13 103 loadbang; #X obj 74 255 del; #X obj 192 226 /; #X msg 192 207 64 44.1; #X floatatom 192 247 5 0 0 0 - - -; #X obj 13 226 phasor~; #X msg 70 90 44100 64; #X obj 70 113 /; #X floatatom 70 131 5 0 0 0 - - -; #X obj 13 204 f 10; #X obj 13 185 t a b; #X obj 73 184 t b a; #X msg 119 195 1000 \$1; #X obj 119 212 /; #X obj 119 176 f 10; #X obj 13 156 t a a; #X obj 192 186 loadbang; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 7 0; #X connect 4 0 11 1; #X connect 5 0 21 0; #X connect 6 0 5 0; #X connect 7 0 1 0; #X connect 8 0 10 0; #X connect 9 0 8 0; #X connect 10 0 7 1; #X connect 11 0 1 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 21 0; #X connect 15 0 11 0; #X connect 16 0 15 0; #X connect 16 1 4 0; #X connect 17 0 2 0; #X connect 17 1 20 0; #X connect 18 0 19 0; #X connect 19 0 3 1; #X connect 20 0 18 0; #X connect 21 0 16 0; #X connect 21 1 17 0; #X connect 22 0 9 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 12:58 +0200, IOhannes m zmoelnig wrote: when you send a message to [vline~] it is scheduled to the next dsp-block (sample accurateley); the last one is already done when you send a message to [vsnapshot~] it operates on the last dsp-block; the next one does not yet exist this is somehow logical: when you query [vsnapshot~] you do want the result immediately (because that's the way how messages are handled in pd); the only result it can give you, is that of already known samples. thanks, it seems logical for me now... the only way to overcome this, is by delaying the sampling bang by one dsp-block. the other thing with the irregularities is simpler: even when messages have sub-sample accuracy, the signal-vectors are only sample-accurate. so when you read the sample-values of a sawtooth immediately after the jump, you will always get different values unless the frequency of your ugen is in sync with your samplerate. see also: shannon's sampling theorem ah, i see. from what i expected from [vsnapshot~] before, it should have used some kind of interpolation, that it obviously does not have. now it is also clear for me, why the discontinuousities grew with higher frequencies/smaller periods. attached is a modified patch what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
two side questions: 1) since computers are much faster now than in 1998, would it be possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard? 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. marius. Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: it would be very cool, if [snapshot~] and [threshold~] (and maybe others) would provide sample accuracy as well (when triggered by [metro] Now I discovered something: Pd (at leat 0.40 up) has a [vsnapshot~] object!! It should do what the name hints at: Provide clock-accurate sample measurements. Unfortunatly simply replacing the lower-right snapshot~ with vsnapshot~ didn't get rid of the clicks. Strange ... Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Roman Haefeli wrote: what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (1ms); you can safely replace it with [metro]. mfgaösdr IOhanens ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, marius schebella hat gesagt: // marius schebella wrote: two side questions: 1) since computers are much faster now than in 1998, would it be possible to change the 64 sample block timing of messages to a block~ 1 and use block~ 64 only for talking to the soundcard? Messages already are faster than [block~ 1]. It's only the conversion from messages to signals (and the other way around) that's tricky. However doing all signal processing at [block~ 1] even today is quite a burden - and even an unnecessary one in many cases. Just try it. 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. metro handles float periods just fine. Try: [metro 200.5] | [t b b] || [timer] | [200.5\ Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 16:57 +0200, IOhannes m zmoelnig wrote: Roman Haefeli wrote: what/where is that [vmetro] object from? it is not included in my version of pd 0.40.2. anyway, if i am not mistaken, your patch works also with [metro]. oh yes, i forgot. [vmetro] is just a [metro] replacement based on [delay] so i can use small cycles (1ms); you can safely replace it with [metro]. I've always wondered this: what does the 'v' stand for in [vline~] [vsnapshot~] etc. ..? Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
marius schebella wrote: 2) Is it possible to get microsecond accuracy in metro? the difference between metro 200 and 200.5 would be one beat per minute. for synchronizing a big difference. marius. [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks, but if you measure over say one hour the timing is very accurate. I can run a hydrogen drum pattern with a pd midi patch both running at the same tempo and they stay in sync all day long, (or until hydrogen crashes because of its outrageously photorealist gui...I generally run with all windows minimized.) Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks What do you mean by this bangs have to happen in between sample blocks? The bangs from metro AFAIK happen independent from the sample blocks. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
On Mon, 2007-05-07 at 20:59 +0200, Frank Barknecht wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: [metro] is very accurate over time, it just has a jitter as the bangs have to happen in between sample blocks What do you mean by this bangs have to happen in between sample blocks? The bangs from metro AFAIK happen independent from the sample blocks. in order to make this discussion more confusing, i say: afaik, it depends which object receives the bang from the [metro]. when it is [vline~] or [vsnapshot~], then it is independent from sample blocks, but when the receiver is the phase inlet of an oscillator or [tabwrite~], then the bang happens on the boundaries. personally, i find that a bit confusing and i would like all these objects to behave the same, namely independent from sample blocks. the same two cents again roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: I think the bangs are independent but they don't get processed until any pending samples have been dealt with. That was the impression I got when testing [comport] by setting the DTR pin using [metro]: there is always a jitter of a few milliseconds. Maybe it's the OS that causes the jitter, but it was about the same on WinXP and linux. I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. Also looking at the pd code, as far as I could follow it, the control signals seem to be processed in between signal blocks, so that, for instance, a metro bang that happens in the middle of a signal block will not be processed until after that block, so yes, the metro can tick whenever it wants but the bang won't occur until after the current sample block has been processed. If it happens to tick in between sample blocks then the bang will happen at the correct time. I think, basically that is correct, that's why evaluating the time-stamps of clock-delayed message is important, if you want to avoid jitter. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Frank Barknecht wrote: I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. Well that's interesting! How does one access these timestamps? I thought a bang has no associated info. Or are you referring to a [metro~]? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] accuracy of signal/message-objects
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: Frank Barknecht wrote: I think, it's comport's fault: [metro] generates clock-delayed messages. These are like messages tagged with a time-stamp referring to Pd's internal clock. However an object needs to actually use the time-stamps and look at the clock to see what time it is. Objects like [vline~] or [delay] do this, but comport doesn't. (Actually I may be wrong here: Maybe comport doesn't need to do anything about this, as it's not a dsp-object. But read on.) Well that's interesting! How does one access these timestamps? I thought a bang has no associated info. Well, there are no real timestamps attached to a bang-message. But Pd has a clock running (actually many, sync'd to the main scheduler clock), and objects that want to know the current time a message arrives, need to look at the clock. vsnapshot~ for example (d_ctl.c) seems to do it like this: In its dsp-perform routine, which is called every sample block, it stores the current time with x-x_time = clock_getlogicaltime(); Then in the bang-routine, vsnapshot~ uses int indx = clock_gettimesince(x-x_time) * x-x_sampspermsec; to calculate the correct index into the incoming sample block from the difference between the time stored previously and the current time. This is what I meant with looking at the clock. Objects like [delay] or [metro] produce these clock-delayed messages. They register their clocks with Pd's main scheduler using clock_new(...) and then order the scheduler to generate the clock-delayed messages like the metro-bangs using clock_delay(). The actual output of [delay], [metro] etc. then is initiated by the scheduler which calls the registered clock methods: delay_tick(), metro_tick(),... However I must admit, I'm not sure how this relates to comport and if comport should also register its port-writing-method with a clock and let the scheduler tick the clock and initiate the writing and if that could get rid of the jitter you mentioned. At least normal objects like [float] don't do any funky clock-stuff and still don't disturb the correct timing of clock-delayed messages. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
