Re: [PD] precision of vline~ and/or pd messaging
On Sun, 2012-01-29 at 18:30 +0100, João Pais wrote: Hi, another chapter in this: I just tried out the same patch, using now [metro] instead of Lyon's objects. The problem is that the results are still quite simliar, i.e. I still get clicks (almost) every 125ms (the beat duration), resulting from non-aligned phases. You can look at the attached file, get a big zoom, and look at the multiples of 125ms. If you zoom not _that_ deep into it, you notice, that only a small segment of 48 samples (?) has the completely odd phase. The continuing part seems to align fine again. I haven't checked all the clicks, but this applies to the few I checked. Was it supposed that with metro-vline the messages would go out in time, as I understood? The patch is too complicated for me to put it online, so I'll explain what it happens: It's even more complicated to interpret the ongoings without having a look at the patch. - a sound in an array is played in segments of (currently) 125ms - a metro (before Lyon's objects) sends the bangs out - several calculations are made to know which excerpts are played back in the array - the segments get to vline~ in the normal message form: [0, 1 125(, [1, 2 125(, [2, 3 125( (these are fictional values to read three fragments on a sequence) - vline~ goes to tabread4~ Those messages look fine to me, if the expected outcome is that 3 segments of 125ms length at different positions of the table should be played (I think that is what you want). As I understood before, would the metro bangs arrive to vline~ on time, so that vline's reading index doesn't get rebuffered? that doesn't seem to be the case of what's happening now, I think. I also tried changing the message from [0, 1 125( to [1 125(, but there were no differences. Or may I make the final question: is it possible to read table segments sequentially, whose size is different from the block size? Yes. Or does it has to be done with some kind of a polyphonic reader + overlapping? Nope. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
Hi, On Wed, Jan 25, 2012 at 10:38:06AM +0100, João Pais wrote: and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk3eu+state:results Actually it's Frank and Eric. :) The thread still sums up what's important here: It's not necessary to use Eric's objects in Pd. They may be useful in Max/MSP and they provide some nice functionality besides accuracy, but the accuracy you get with vline~ and Pd's clock objects (metro, delay, etc.) already is subsample-exact, so it's fine for many cases and as good as what you get with [samm~] and relatives. Just use [metro]. oops. so, your wording in the final sentence should be something like so it's fine for many cases and MORE PRECISE as what you get with [samm~] and relatives. Just use [metro]? I don't think, it's more precise, I think, Eric's objects are just an alternative approach to get the same precision as you get with vline~. IIRC Eric wasn't aware of vline~ when he wrote his objects. just to ask beforehand: between the bang starting the event and vline~ there are a couple of patches: getting the counter nr, segment references, quantisation etc, all in message level (with vanilla and extra objects). But if the initial bang is block-precise (wherever in the audio block it should be), all message objects should behave fine? which are Pd's clock objects you described above, all objects in the time section of pd-van? Yes, but of course people can write externals that use Pd's internal clock just as metro, delay or pipe do. Contrasting these you may have a non-clock message, for example if you click a [bang( message. This will actually not be activated at the exact time that you click it, but always on a block boundary. will also pd-ext objects behave in the same way, provided that it's not their function to include more delays? I'll rephrase the question, if between bang and vline~ I put an external doing a multiplication or something, will it delay the message? (I guess the answer is no, but want to be sure) The usual message transformation objects don't change the timing of the original message. Pd is deterministic, so you can assume that all the message calculations etc. that you do happen at the same time. Timing problems occur only when you leave or enter this message realm, for example when converting messages to (and from) audio signals, because audio signals in Pd are block based. The gory details are in Miller's TTEM-book: http://crca.ucsd.edu/~msp/techniques/latest/book-html/node40.html Especially note the subchapters: Control streams http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html and Converting controls to signals http://crca.ucsd.edu/~msp/techniques/latest/book-html/node52.html and help patch: C04.control.to.signal.pd Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
Ah, and I see in addition to your message you wrote vline~ in the title! Oops. I don't know what click2bang~ does-- is it aligning its bangs to block boundaries? That's just a guess. better to leave it to the author to describe it (http://www.somasa.qub.ac.uk/~elyon/LyonSoftware/Pd/): samm~ sample accurate multiple metronomes, with click signal articulation click2bang~ Convert click trigger to a bang according to the author, putting these 2 objects in a row gives a very precise metro. and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk3eu+state:results João -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at; Jonathan Wilkes jancs...@yahoo.com Sent: Tuesday, January 24, 2012 6:53 PM Subject: Re: [PD] precision of vline~ and/or pd messaging Hmm, I have to correct your message to get a more interesting answer from you :) the SR is 48K, and I'm using vline~ already. Theoretically with E Lyon's objects I should also get more messaging precision, or maybe not at all? João I'm not sure if this is correct, so someone with a deeper knowledge of Pd can confirm/deny... :) 125ms at a samplerate of (I'm guessing) 44100 would mean you're sending a message to [line~] every 5512.5 samples. Pd's default blocksize is 64, and when you convert from a control value to a signal value using the [line~] method then you are forced to start/end the ramp on block boundaries. Since 64 does not divide into 5512.5 evenly then there is no way you can perfectly recreate the sine tone using this method. (I haven't looked at your example but I would imagine that [line~] forces the remainder to occur over the course of an entire blockthus stretching out that part of your sine wave to be longer than you want.) You could recreate it using [vline~] however, because it will let you start/end a ramp in the middle of a block, thus giving you higher precision (presumably at a higher CPU cost). -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at Sent: Tuesday, January 24, 2012 4:50 PM Subject: [PD] precision of vline~ and/or pd messaging Hi, please look at the attached audio file. It's a recording of a sinus tone stored in an array, played back with consecutive segments of 125ms. If you look at each multiple of 125ms, you'll see there's a glitch in the waveform. That means, the pd patch isn't fully precise aliging the several fragments together. Or maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ to send the messages, theoretically to have greater precision - and then some counters and table readers make several calculations to get the indexes of the segments. After these message-level calculations, the data goes to vline~ reading from a tabread4~. My question is then: is it possible to get messaging and audio in Pd ligned up, so that the resulting audio file is as precise as an original osc~? If so, which objects or parameters should be used instead? Thanks, Joao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
On Wed, Jan 25, 2012 at 09:56:11AM +0100, João Pais wrote: Ah, and I see in addition to your message you wrote vline~ in the title! Oops. I don't know what click2bang~ does-- is it aligning its bangs to block boundaries? That's just a guess. better to leave it to the author to describe it (http://www.somasa.qub.ac.uk/~elyon/LyonSoftware/Pd/): samm~ sample accurate multiple metronomes, with click signal articulation click2bang~ Convert click trigger to a bang according to the author, putting these 2 objects in a row gives a very precise metro. and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk3eu+state:results Actually it's Frank and Eric. :) The thread still sums up what's important here: It's not necessary to use Eric's objects in Pd. They may be useful in Max/MSP and they provide some nice functionality besides accuracy, but the accuracy you get with vline~ and Pd's clock objects (metro, delay, etc.) already is subsample-exact, so it's fine for many cases and as good as what you get with [samm~] and relatives. Just use [metro]. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
Hi Claude, so you're saying that vline~ or other clock-aware objects [which, btw?] is precise in itself, so the problem should come from E Lyon's objects, which aren't, because of sig-mess conversion? (which is funny, because apparently they were made to correct this, at least in max/msp) It seems then that the best solution would be to avoid the fancy stuff and use a plain simple metro? (In case you have nothing better to do, could you check if Lyon's code is really as block-precise as it says?) Thanks, João On 24/01/12 21:50, João Pais wrote: maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ I'm not familiar with those externals, nor in inspecting the output of a patch (which is on the large size) instead of the patch. But some general points: Timing of message-signal is 100% accurate with vline~ or other clock-aware objects, because all the message processing for a given dsp block happens before the dsp block is calculated. vline~ and other objects can use the timestamp of the messages (which is in the future compared to the dsp processing) and schedule their dsp computations appropriately. If you use metro, delay, vline~ all your timing will be in sync. Timing of signal-message is problematic, for the same reason: the earliest a message can be sent is after the whole dsp block is calculated, so if you need to send a message mid-way through a dsp block you'd need a time machine to go back in time(*) before the dsp block was started to be computed and then trigger a message with a future (during the dsp block) timestamp. The best you can do is a 1-block delay for signal-message, so perhaps click2bang~ should be modified to tell you where in the block the click(s) occurred so you can compensate, assuming any delay/latency is acceptable. Or you could implement an abstraction to do something like this using [tabsend~] and [bang~]. Or you could run your patch at 192kHz where 125ms is a multiple of the default block size, or you could use a block size of 1. Claude (*) If affordable time travel will be invented I'd have not sent this email ;) ___ 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] precision of vline~ and/or pd messaging
and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk3eu+state:results Actually it's Frank and Eric. :) The thread still sums up what's important here: It's not necessary to use Eric's objects in Pd. They may be useful in Max/MSP and they provide some nice functionality besides accuracy, but the accuracy you get with vline~ and Pd's clock objects (metro, delay, etc.) already is subsample-exact, so it's fine for many cases and as good as what you get with [samm~] and relatives. Just use [metro]. oops. so, your wording in the final sentence should be something like so it's fine for many cases and MORE PRECISE as what you get with [samm~] and relatives. Just use [metro]? just to ask beforehand: between the bang starting the event and vline~ there are a couple of patches: getting the counter nr, segment references, quantisation etc, all in message level (with vanilla and extra objects). But if the initial bang is block-precise (wherever in the audio block it should be), all message objects should behave fine? which are Pd's clock objects you described above, all objects in the time section of pd-van? will also pd-ext objects behave in the same way, provided that it's not their function to include more delays? I'll rephrase the question, if between bang and vline~ I put an external doing a multiplication or something, will it delay the message? (I guess the answer is no, but want to be sure) thanks, João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
I'm not sure if this is correct, so someone with a deeper knowledge of Pd can confirm/deny... :) 125ms at a samplerate of (I'm guessing) 44100 would mean you're sending a message to [line~] every 5512.5 samples. Pd's default blocksize is 64, and when you convert from a control value to a signal value using the [line~] method then you are forced to start/end the ramp on block boundaries. Since 64 does not divide into 5512.5 evenly then there is no way you can perfectly recreate the sine tone using this method. (I haven't looked at your example but I would imagine that [line~] forces the remainder to occur over the course of an entire blockthus stretching out that part of your sine wave to be longer than you want.) You could recreate it using [vline~] however, because it will let you start/end a ramp in the middle of a block, thus giving you higher precision (presumably at a higher CPU cost). -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at Sent: Tuesday, January 24, 2012 4:50 PM Subject: [PD] precision of vline~ and/or pd messaging Hi, please look at the attached audio file. It's a recording of a sinus tone stored in an array, played back with consecutive segments of 125ms. If you look at each multiple of 125ms, you'll see there's a glitch in the waveform. That means, the pd patch isn't fully precise aliging the several fragments together. Or maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ to send the messages, theoretically to have greater precision - and then some counters and table readers make several calculations to get the indexes of the segments. After these message-level calculations, the data goes to vline~ reading from a tabread4~. My question is then: is it possible to get messaging and audio in Pd ligned up, so that the resulting audio file is as precise as an original osc~? If so, which objects or parameters should be used instead? Thanks, Joao ___ 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] precision of vline~ and/or pd messaging
Hmm, I have to correct your message to get a more interesting answer from you :) the SR is 48K, and I'm using vline~ already. Theoretically with E Lyon's objects I should also get more messaging precision, or maybe not at all? João I'm not sure if this is correct, so someone with a deeper knowledge of Pd can confirm/deny... :) 125ms at a samplerate of (I'm guessing) 44100 would mean you're sending a message to [line~] every 5512.5 samples. Pd's default blocksize is 64, and when you convert from a control value to a signal value using the [line~] method then you are forced to start/end the ramp on block boundaries. Since 64 does not divide into 5512.5 evenly then there is no way you can perfectly recreate the sine tone using this method. (I haven't looked at your example but I would imagine that [line~] forces the remainder to occur over the course of an entire blockthus stretching out that part of your sine wave to be longer than you want.) You could recreate it using [vline~] however, because it will let you start/end a ramp in the middle of a block, thus giving you higher precision (presumably at a higher CPU cost). -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at Sent: Tuesday, January 24, 2012 4:50 PM Subject: [PD] precision of vline~ and/or pd messaging Hi, please look at the attached audio file. It's a recording of a sinus tone stored in an array, played back with consecutive segments of 125ms. If you look at each multiple of 125ms, you'll see there's a glitch in the waveform. That means, the pd patch isn't fully precise aliging the several fragments together. Or maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ to send the messages, theoretically to have greater precision - and then some counters and table readers make several calculations to get the indexes of the segments. After these message-level calculations, the data goes to vline~ reading from a tabread4~. My question is then: is it possible to get messaging and audio in Pd ligned up, so that the resulting audio file is as precise as an original osc~? If so, which objects or parameters should be used instead? Thanks, Joao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
On 24/01/12 21:50, João Pais wrote: maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ I'm not familiar with those externals, nor in inspecting the output of a patch (which is on the large size) instead of the patch. But some general points: Timing of message-signal is 100% accurate with vline~ or other clock-aware objects, because all the message processing for a given dsp block happens before the dsp block is calculated. vline~ and other objects can use the timestamp of the messages (which is in the future compared to the dsp processing) and schedule their dsp computations appropriately. If you use metro, delay, vline~ all your timing will be in sync. Timing of signal-message is problematic, for the same reason: the earliest a message can be sent is after the whole dsp block is calculated, so if you need to send a message mid-way through a dsp block you'd need a time machine to go back in time(*) before the dsp block was started to be computed and then trigger a message with a future (during the dsp block) timestamp. The best you can do is a 1-block delay for signal-message, so perhaps click2bang~ should be modified to tell you where in the block the click(s) occurred so you can compensate, assuming any delay/latency is acceptable. Or you could implement an abstraction to do something like this using [tabsend~] and [bang~]. Or you could run your patch at 192kHz where 125ms is a multiple of the default block size, or you could use a block size of 1. Claude (*) If affordable time travel will be invented I'd have not sent this email ;) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
Ah, and I see in addition to your message you wrote vline~ in the title! Oops. I don't know what click2bang~ does-- is it aligning its bangs to block boundaries? That's just a guess. -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at; Jonathan Wilkes jancs...@yahoo.com Sent: Tuesday, January 24, 2012 6:53 PM Subject: Re: [PD] precision of vline~ and/or pd messaging Hmm, I have to correct your message to get a more interesting answer from you :) the SR is 48K, and I'm using vline~ already. Theoretically with E Lyon's objects I should also get more messaging precision, or maybe not at all? João I'm not sure if this is correct, so someone with a deeper knowledge of Pd can confirm/deny... :) 125ms at a samplerate of (I'm guessing) 44100 would mean you're sending a message to [line~] every 5512.5 samples. Pd's default blocksize is 64, and when you convert from a control value to a signal value using the [line~] method then you are forced to start/end the ramp on block boundaries. Since 64 does not divide into 5512.5 evenly then there is no way you can perfectly recreate the sine tone using this method. (I haven't looked at your example but I would imagine that [line~] forces the remainder to occur over the course of an entire blockthus stretching out that part of your sine wave to be longer than you want.) You could recreate it using [vline~] however, because it will let you start/end a ramp in the middle of a block, thus giving you higher precision (presumably at a higher CPU cost). -Jonathan From: João Pais jmmmp...@googlemail.com To: PD-List pd-list@iem.at Sent: Tuesday, January 24, 2012 4:50 PM Subject: [PD] precision of vline~ and/or pd messaging Hi, please look at the attached audio file. It's a recording of a sinus tone stored in an array, played back with consecutive segments of 125ms. If you look at each multiple of 125ms, you'll see there's a glitch in the waveform. That means, the pd patch isn't fully precise aliging the several fragments together. Or maybe the messaging isn't precisely aligned with the audio. For this patch I'm using E Lyon's samm~ and click2bang~ to send the messages, theoretically to have greater precision - and then some counters and table readers make several calculations to get the indexes of the segments. After these message-level calculations, the data goes to vline~ reading from a tabread4~. My question is then: is it possible to get messaging and audio in Pd ligned up, so that the resulting audio file is as precise as an original osc~? If so, which objects or parameters should be used instead? Thanks, Joao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
