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
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 jmmmpais@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
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 toa 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 thesine 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 ofyour 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 ofa block, thus giving you higher precision (presumably at a higher CPU
cost).-Jonathan
From: João Pais jmmmpais@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
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 jmmmpais@googlemail.com To: PD-List pd-list@iem.at; Jonathan Wilkes jancsika@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 jmmmpais@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 jmmmpais@googlemail.com | skype: jmmmpjmmmp
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:7usetdchjlqyk...
João
-Jonathan
From: João Pais jmmmpais@googlemail.com To: PD-List pd-list@iem.at; Jonathan Wilkes jancsika@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 toa 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 thesine 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 ofyour 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 ofa block, thus giving you higher precision (presumably at a higher CPU
cost).-Jonathan
From: João Pais jmmmpais@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 jmmmpais@googlemail.com | skype: jmmmpjmmmp
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:7usetdchjlqyk...
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 Barknecht Do You RjDj.me? _ ______footils.org__
and here a link to a thread with iohannes and lyon: http://markmail.org/message/7usetdchjlqyk3eu#query:+page:1+mid:7usetdchjlqyk...
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
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:7usetdchjlqyk...
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 Barknecht Do You RjDj.me? _ ______footils.org__
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.
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:
- 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, 10000 125(,
[10000, 20000 125(, [20000, 30000 125( (these are fictional values to read three fragments on a sequence)
- vline~ goes to tabread4~
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, 10000 125( to [10000 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? Or does it has to be done with some kind of a polyphonic reader + overlapping?
João
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, 10000 125(,
[10000, 20000 125(, [20000, 30000 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, 10000 125( to [10000 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
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 ;)
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
-
Claude Heiland-Allen -
Frank Barknecht -
Jonathan Wilkes -
João Pais -
Roman Haefeli