Hi list,
This is my first post here asking you for help. I built for many years in NI Reaktor (and still do). For this reason I'm used to handle basically 2 signal types: Audio - always sample rate clocked Event - any(!) time, even between samples Now I need to get to know and used to the clock and trigger "secrets" in pd. I want to work efficiently of course but also to be sample accurate if needed. Beside having fun with the great freedom and logic of puredata, my aim is to be able to build hi quality audio stuff sooner or later...
While building an audio scope (for e.g. debugging) I got stuck in searching sample exact message trigger. I wanna ask you for suggestions tips about my approach. Have a look into attached pd I prepared with comments here and there describing my thoughts and problems. There may be different ways to make audio scopes (I know there is one build-in but it only displayed useless coarse vector lines) but some questions I want to get answered anyhow:
my basic questions:
Samplerate accurate?
far to coarse! (see attached pd)
<64 ?
timing? Or what is it for...
manuals, links, mails or commented pd patches - anything is welcome.
regards Dietrich
On Tue, 21 Dec 2010, Dietrich Pank wrote:
Audio - always sample rate clocked Event - any(!) time, even between samples Now I need to get to know and used to the clock and trigger "secrets" in pd. I want to work efficiently of course but also to be sample accurate if needed.
There are three ways to get sample-accurate events :
carry the event as part of a signal at the same rate as the audio. between apps, this could mean, for example, that you'd use an extra channel in jack for those events.
carry the event as a message, then as the last step, convert it to a (sample-rate) signal for objects that can use that (for example, use a [vline~] plugged into [*~]'s right inlet)
with objects (or aspects of objects) that just don't support sample-rate changes, you can use [block~ 1] if you can't find any sample-rate equivalent.
I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~] and [hip~].
- my patch only accepts 64 - why?
If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~] pair is like [*~] by the block size.
- why does the $0-audioscope show extreme high amplitude when block~
size is <64 ?
Does it double amplitude when you halve the block size, or does it double amplitude when you quadruple the block size, or some other pattern ? (which ?)
Does it do the opposite thing when you use bigger block sizes ?
- makes it sense at all changing block~ size in order to get better
message timing? Or what is it for...
It's for several things :
decrease to get more resolution
increase to get more efficiency (of cpu)
change to control the [fft~] window size (which is not controllable by its own parameters, unlike [fiddle~]'s window size)
when converting between different sampling rates, change proportionally to sample rate, to avoid having to split/merge blocks (this rarely matters at all)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
forgot the attachment - here it is. (thank you Mathieu, I'm in hurry - I will answer later)
Hi Mathieu,
There are three ways to get sample-accurate events :
carry the event as part of a signal at the same rate as the audio. between apps, this could mean, for example, that you'd use an extra channel in jack for those events.
carry the event as a message, then as the last step, convert it to a (sample-rate) signal for objects that can use that (for example, use a [vline~] plugged into [*~]'s right inlet)
with objects (or aspects of objects) that just don't support sample-rate changes, you can use [block~ 1] if you can't find any sample-rate equivalent.
about functionality of Jack if it does something I can't do in Win). 3. I tried as I already mentioned but there must be an error in my structure because the log window talks a lot of errors each time I try to change the block~ size...
Could you show me working examples finding and processing sample accurate timed events? How do you use sequencers? What about fast retriggering percussives or delay like effects - isn't the jitter bothering you?
I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~] and [hip~].
Your abstractions doesn't seem to be part of 0.42.5-extended? I couldn't find ithttp://www.google.de/#sclient=psy&hl=de&q=%22lop2~%22%20(pd%20OR%20puredata)&aq=&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=9518358c6ae80f89&pf=p&pdl=3000with google search either... Where can I find it? And what method (1.,2. or 3.) did you use?
- my patch only accepts 64 - why?
If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~] pair is like [*~] by the block size.
no FFT yet
- why does the $0-audioscope show extreme high amplitude when block~ size
is <64 ?
Does it double amplitude when you halve the block size, or does it double amplitude when you quadruple the block size, or some other pattern ? (which ?)
it shots out of screen limit, the scroll bar appears and is very small... so the value must very high. Look at it I attached it (you need to touch some controls of the audioscope in order to update correctly - I have a bug there).
Does it do the opposite thing when you use bigger block sizes ?
I correct myself: it is ok in block~size 64 only, at any other size also higher sizes it shows the same giant burst.
- makes it sense at all changing block~ size in order to get better
message timing? Or what is it for...
It's for several things :
- decrease to get more resolution
- increase to get more efficiency (of cpu)
- change to control the [fft~] window size (which is not controllable by its own parameters, unlike [fiddle~]'s window size
- when converting between different sampling rates, change proportionally to sample rate, to avoid having to split/merge blocks (this rarely matters at all)
i see. (well.. 4. I will understand one day I'm convinced ;)
thank you! cheers Dietrich
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 22 Dec 2010, Dietrich Pank wrote:
- and 2. I don't understand how to approach (I'm on Win btw. but would
like about functionality of Jack if it does something I can't do in Win).
Well, I don't know your setup, and I don't do much between Pd and other apps, as I tend to do Pd-only projects, so I can't help so much.
But the idea #1 is to transmit the triggers as a signal from the beginning and all along : in a Pd-only situation, for example, you could take a microphone, multiply its signal with itself using [*~], use [lop~] to turn this into an envelope, then use [rzero~ 1] to separate the increasing parts from the decreasing ones, then [expr~ $v1>0], [rzero~ 1] again, [expr~ $v1>0] again, and now you have triggers in the form of a signal containing zeroes and occasionally ones. It's probably a bad example (I didn't try it) and would need a lot of tuning in practice, BUT :
The important thing here, is that you're never using anything else than sample-rate, so, there are objects you can't use here, which is why I didn't use [env~] to make the envelope, because it's not smooth like signal-rate, and I didn't use [bonk~] to find the peaks, also because it doesn't have that resolution.
The idea #2, now, is that if you really have to start from control-rate, and you do have precise timings (as numbers) for future events, then you can generate a signal representing those precise timings. That's what [vline~] is for. That allows you to deal with objects whose only way to go high-resolution is to use a signal, because you can't tell them precise timings as messages.
Could you show me working examples finding and processing sample accurate timed events?
I don't have any.
How do you use sequencers?
I use them with control-rate. I use smaller blocksize (as low as 4, at double samplerate) but that's not because of event resolution, it's because my synth is based on feedback, and sometimes it's really high-pitched, so the blocksize has to be decreased to accomodate the high pitches. As a side-effect, I do get higher resolution of triggering, but I don't notice it, because I don't do things that would highlight it.
What about fast retriggering percussives or delay like effects - isn't the jitter bothering you?
The closest I do, is that I use [delwrite~] and [vd~]. That's at sample-rate all along.
Your abstractions doesn't seem to be part of 0.42.5-extended?
No. They aren't part of anything. I posted them on pd-list this year. I attach them to this reply now.
And what method (1.,2. or 3.) did you use?
They use the formula for the equivalence between [rpole~] and [lop~]. Because [rpole~] can be parametrised at sample-rate, this gives you a sample-rate [lop~].
it shots out of screen limit, the scroll bar appears and is very small... so the value must very high.
Insert an [env~] (optionally with [dbtorms]) to find actual numbers.
Look at it I attached it (you need to touch some controls of the audioscope in order to update correctly - I have a bug there).
I won't try it now.
4. when converting between different sampling rates, change proportionally to sample rate, to avoid having to split/merge blocks (this rarely matters at all) i see. (well.. 4. I will understand one day I'm convinced ;)
Well, #4 is really not important to understand.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, Dec 21, 2010 at 10:41:39PM -0500, Mathieu Bouchard wrote:
On Wed, 22 Dec 2010, Dietrich Pank wrote:
Your abstractions doesn't seem to be part of 0.42.5-extended?
No. They aren't part of anything. I posted them on pd-list this year. I
attach them to this reply now.
Your hip2~.pd seems to be missing an inlet~. I attached a version that also replaced expr~ with internal objects and has help-files copied from lop~/hip~ and was renamed to hips~.pd and lops~.pd (the "2" made me think of a "2-pole filter").
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Tue, 28 Dec 2010, Frank Barknecht wrote:
Your hip2~.pd seems to be missing an inlet~.
Ah, thanks.
I attached a version that also replaced expr~ with internal objects
You could also compile expr~ as an internal class. It's very useful.
and has help-files copied from lop~/hip~ and was renamed to hips~.pd and lops~.pd (the "2" made me think of a "2-pole filter").
And what is the "s" supposed to make me think of ? (How did you pick it ?)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, Dec 28, 2010 at 11:30:43AM -0500, Mathieu Bouchard wrote:
On Tue, 28 Dec 2010, Frank Barknecht wrote:
Your hip2~.pd seems to be missing an inlet~.
Ah, thanks.
I attached a version that also replaced expr~ with internal objects
You could also compile expr~ as an internal class. It's very useful.
But it can be a bit slow IIRC. And it's GPL, which has other implications.
and has help-files copied from lop~/hip~ and was renamed to hips~.pd and lops~.pd (the "2" made me think of a "2-pole filter").
And what is the "s" supposed to make me think of ? (How did you pick it ?)
I was thinking of the "s"ignal inlets for CF, but maybe I was also thinking of "hops" (and malt ...).
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Wed, 22 Dec 2010, Dietrich Pank wrote:
I correct myself: it is ok in block~size 64 only, at any other size also higher sizes it shows the same giant burst.
The error messages indicate that [throw~] [catch~] [send~] [receive~] don't work across different block sizes.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, Dec 20, 2010 at 7:21 PM, Dietrich Pank dietrich.pank@googlemail.com wrote:
Hi list, This is my first post here asking you for help. I built for many years in NI Reaktor (and still do). For this reason I'm used to handle basically 2 signal types: Audio - always sample rate clocked Event - any(!) time, even between samples
Excuse my ignorance, I have never seen NI Reactor, but what does "between samples" mean? I imagine the Event rate is higher than the sample rate?
Now I need to get to know and used to the clock and trigger "secrets" in pd. I want to work efficiently of course but also to be sample accurate if needed.
Pd, by default, does not do any computations per sample, it computes blocks of samples.
Beside having fun with the great freedom and logic of puredata, my aim is to be able to build hi quality audio stuff sooner or later... While building an audio scope (for e.g. debugging) I got stuck in searching sample exact message trigger.
The only way, AFAIK, to get sample accurate triggers is to use [bang~] inside a subpatch that has its block size set to 1 [block~ 1 1 1]. You could probably get close to "between" samples by upsampling (i.e. [block~ 1 1 2]) but I never tried it and the triggers will eventually be re-aligned with the current block size...
I wanna ask you for suggestions tips about my approach. Have a look into attached pd I prepared with comments here and there describing my thoughts and problems. There may be different ways to make audio scopes (I know there is one build-in but it only displayed useless coarse vector lines) but some questions I want to get answered anyhow: my basic questions:
in pd-extended you should be able to use [cyclone/Scope~]. Perhaps it is less useless.
- is it possible to get/fire precise timed messages, e.g. Metro (at least)
Samplerate accurate?
[bang~] with [block~ 1 1 1]... except for the global block size?
- is it possible to get sample timed events/messages, e.g. threshold what is
far to coarse! (see attached pd)
[threshold~]'s resolution seems to be timed at millisecond intervals which is 44.1 samples. Perhaps a more accurate timing would be to use [env~] inside [block~ 1 1 1] but then you would need a sample accurate timer (I am not aware of any for Pd)
- regarding changing block~ size:
- my patch only accepts 64 - why?
did you use [block~] inside a subpatch? also, the subpatch using [block~] should not have any [inlet~] or [outlet~] objects because they reblock the signal (see the helpfile for [block~]. Alternatively, try to start pd with -blocksize 1 but I have no idea whether that will actually make everything sample-accurate and suit your needs.
- why does the $0-audioscope show extreme high amplitude when block~ size is
<64 ?
- makes it sense at all changing block~ size in order to get better message
timing? Or what is it for...
As far as I understand [block~], its purpose is to compute signals irrespective of current sampling rate/block size but anything you try to output back into the main patch will be reblocked in accordance with the current block size.
Perhaps someone else will have more insight into the issues you are facing, I have rarely had a need for sample (sub sample) precise timing. ChucK's rationale is sample precision, CSound can do kr=sr (control rate = sampling rate), SuperCollider can certainly do sample-wise computations but Pd's niche is elsewhere. Someone will probably prove me wrong but maybe you are not looking at the right tool for the job...
See audio.examples/G04.control.blocksize.pd. There was also an example of reading a sample into an an array without [soundfiler], a faster than reatime playbackusing [block~] but I cannot locate it ATM.
HTH
./MiS
If Pd's default block size is 64 samples, and "events" are only processed at the beginning of a block cycle.
Therefore, if you're running at 48,000hz sample rate, then your "Event Rate" is 750hz. Likewise a 96,000hz sample rate will give you a 1500hz "Event Rate".
As Mathieu mentioned, if you need anything higher than this, your only options are:
As for "between samples", are you referring to some kind of upsampling? In that case, either increase the sample rate of a sub-patch using [block~] relative to the current sample rate, or use either a [delread~]/[delwrite~] pair or [fexpr~] to hold the last sample value from a given stream for calculation.
~Brandon
On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:
If Pd's default block size is 64 samples, and "events" are only processed at the beginning of a block cycle.
Not true. Events a.k.a messages are 'virtually' [1] processed at any time (literally any time, which includes any time between samples. The only restriction is the resolution of the 32bit floating point number format used by Pd).
This can be easily shown with this little patch:
[metro 3.1415] | [t b b] | | [timer] | [3.1415\ <- number box
You can change the metro to any value and [timer] will report back exactly that value. AFAIK, this exact timing occurs as long we're considering the message-only domain.
However, there are some objectclasses which accept messages at the inlets and produce signals at the outlets, e.g. [sig~]. Many (almost all?) of them only evaluate the messages _at_ block boundaries and thus the resulting signal can only be changed at block boundaries. This effect makes the messages look like they only happen at block boundaries, although they actually happen at any time.
There are other objects that work in both, message and signal domain, which don't suffer from that problem: [vline~] and [vsnapshot~]. Both take the exact timing of the message into account.
[1]: I say 'virtually', because Pd actually really computes one or several events only once per block, though is this done transparently when looking from the outside.
Summary:
[metro] and [del] are as accurate as you can wish them to be.
Always use [vline~] when timing-exact conversion from message to
signal matters
messages
message domain
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial [comport], etc.) usually don't have more exact timing than the block size.
Roman
My fault, you're right. I'm happily wrong about this one.
Cheers, Brandon
On Dec 22, 2010 9:52 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:
If Pd's default block size is 64 samples, a...
Not true. Events a.k.a messages are 'virtually' [1] processed at any time (literally any time, which includes any time between samples. The only restriction is the resolution of the 32bit floating point number format used by Pd).
This can be easily shown with this little patch:
[metro 3.1415] | [t b b] | | [timer] | [3.1415\ <- number box
You can change the metro to any value and [timer] will report back exactly that value. AFAIK, this exact timing occurs as long we're considering the message-only domain.
However, there are some objectclasses which accept messages at the inlets and produce signals at the outlets, e.g. [sig~]. Many (almost all?) of them only evaluate the messages _at_ block boundaries and thus the resulting signal can only be changed at block boundaries. This effect makes the messages look like they only happen at block boundaries, although they actually happen at any time.
There are other objects that work in both, message and signal domain, which don't suffer from that problem: [vline~] and [vsnapshot~]. Both take the exact timing of the message into account.
[1]: I say 'virtually', because Pd actually really computes one or several events only once per block, though is this done transparently when looking from the outside.
Summary:
[metro] and [del] are as accurate as you can wish them to be.
Always use [vline~] when timing-exact conversion from message to
signal matters
messages
message domain
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial [comport], etc.) usually don't have more exact timing than the block size.
Roman
thank you guys for your answers!
I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1 vline~ doesn't work in block~ sizes <64
And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)...
Anyway. I'm too focused I'm afraid. There will be a lot other possibilities.
thank you for clarifications so far!
best Dietrich
2010/12/22 Roman Haefeli reduzent@gmail.com
On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:
If Pd's default block size is 64 samples, and "events" are only processed at the beginning of a block cycle.
Not true. Events a.k.a messages are 'virtually' [1] processed at any time (literally any time, which includes any time between samples. The only restriction is the resolution of the 32bit floating point number format used by Pd).
This can be easily shown with this little patch:
[metro 3.1415] | [t b b] | | [timer] | [3.1415\ <- number box
You can change the metro to any value and [timer] will report back exactly that value. AFAIK, this exact timing occurs as long we're considering the message-only domain.
However, there are some objectclasses which accept messages at the inlets and produce signals at the outlets, e.g. [sig~]. Many (almost all?) of them only evaluate the messages _at_ block boundaries and thus the resulting signal can only be changed at block boundaries. This effect makes the messages look like they only happen at block boundaries, although they actually happen at any time.
There are other objects that work in both, message and signal domain, which don't suffer from that problem: [vline~] and [vsnapshot~]. Both take the exact timing of the message into account.
[1]: I say 'virtually', because Pd actually really computes one or several events only once per block, though is this done transparently when looking from the outside.
Summary:
[metro] and [del] are as accurate as you can wish them to be.
Always use [vline~] when timing-exact conversion from message to
signal matters
- most tilde-classes with message inlets ignore the timing of the
messages
- You don't need lower block sizes for having exact timing in the
message domain
- Messages triggered from external sources (GUIs [bng]/[hslider] etc.,
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial [comport], etc.) usually don't have more exact timing than the block size.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2010-12-23 at 01:28 +0100, Dietrich Pank wrote:
thank you guys for your answers!
I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1
Interesting. How did you test that?
vline~ doesn't work in block~ sizes <64
I'm surprised. Again, how did you test it?
And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)...
Anyway. I'm too focused I'm afraid.
I think when doing Pd it's natural that you want to know these things.
Roman
I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1
Interesting. How did you test that?
vline~ doesn't work in block~ sizes <64
I'm surprised. Again, how did you test it?
good question :) patch attached.
regards Dietrich
On Thu, 2010-12-23 at 13:12 +0100, Dietrich Pank wrote:
> I think I understand the basic theory. > Experience is something else... e.g. > line~ and metro doesn't work sample correct even in block~ size 1 Interesting. How did you test that? > vline~ doesn't work in block~ sizes <64 I'm surprised. Again, how did you test it?
good question :) patch attached.
I'm afraid I didn't fully understand the idea of the patch. I mean, I understood the basic idea. But why are you assuming, that 2 samples and 3 samples are the smallest possible ramps that can be achieved with [vline~] and [line~]? Also I'm not clear, what kind of signal [vline~] and [line~] are supposed to produce. They don't accept the same message format. [vline~] takes up to three arguments (<target value>, <ramp time>, <delay>), while [line~] takes only two (<target values>, <ramp time>). Check the help file for the specifics.
Anyway, your patch makes a few things quite clear.
blocksizes, one might has to wait a long time until it starts the ramp.
Roman
On Thu, 23 Dec 2010, Roman Haefeli wrote:
- The blocksize doesn't affect [vline~] as long as it is >= 64 samples.
Actually, it does, if you put the [vline~] with a [block~ 64] subpatch that is inside a [block~ 128]. The problem is when the blocksize goes down.
But this doesn't explain why I can't get "pd -blocksize 16", or [block~ 16] in the main patch, to fully behave like a blocksize=16 instead of a blocksize=64.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 12/22/10 7:28 PM, Dietrich Pank wrote:
thank you guys for your answers!
I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1 vline~ doesn't work in block~ sizes <64
And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)...
I have found this to be the case as well. It seems most (maybe all, not sure) signal-to-message objects have a minimum hard limit of 64 samples. [bang~], [edge~], and [threshold~] I've noticed for sure are like this. I don't know about [vline~] since I use it to avoid having to change the block size. :-)
[metro~] is sample accurate, but it has a minimum of 1 ms. If you need to go faster than that, make a [metro] by having a [delay] retrigger itself.
.mmb
Anyway. I'm too focused I'm afraid. There will be a lot other possibilities.
thank you for clarifications so far!
best Dietrich
On Thu, 2010-12-23 at 08:10 -0500, Mike Moser-Booth wrote:
On 12/22/10 7:28 PM, Dietrich Pank wrote:
thank you guys for your answers!
I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1 vline~ doesn't work in block~ sizes <64
And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)...
I have found this to be the case as well. It seems most (maybe all, not sure) signal-to-message objects have a minimum hard limit of 64 samples.
Yeah, I don't know of any either.
[bang~], [edge~], and [threshold~] I've noticed for sure are like this. I don't know about [vline~] since I use it to avoid having to change the block size. :-)
I happily repeat myself: There is no need to adjust the block size when using [vline~]. See the attached patch. It's a (aliased) square wave oscillator built with [metro] and [vline~]. See that it works for any blocksize >= 64 samples.
As Dietrich already pointed out, for some reason it stops working as expected when using a blocksize < 64. I don't why this is and I suspect it to be a bug.
Roman
On Thu, 23 Dec 2010, Roman Haefeli wrote:
As Dietrich already pointed out, for some reason it stops working as expected when using a blocksize < 64. I don't why this is and I suspect it to be a bug.
I tried to fix it by introducing a x_yourmom property in [vline~] that holds the value of clock_getlogicaltime to see whether it was the same, and fudge the clock values according to how many times the same time has been used. But it's a little bit off and this isn't the place where the problem ought to be fixed.
And the way it is now, it only works if you send a triplet to [vline~], so, I inserted a messagebox in your test patch, that is «$1 0 10».
--- d_ctl.c (révision 14667) +++ d_ctl.c (copie de travail) @@ -249,6 +249,8 @@ t_float x_inlet1; t_float x_inlet2; t_vseg *x_list;
double x_yourmom; // because blocksize messes up logicaltime
int x_fudge; } t_vline;
static t_int *vline_tilde_perform(t_int *w)
@@ -260,7 +262,10 @@ double inc = x->x_inc; double msecpersamp = x->x_msecpersamp; double samppermsec = x->x_samppermsec;
@@ -395,6 +400,8 @@ x->x_list = 0; x->x_samppermsec = 0; x->x_targettime = 1e20;
x->x_yourmom = -1;
x->x_fudge = 0; return (x); }
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 12/23/10 8:51 AM, Roman Haefeli wrote:
On Thu, 2010-12-23 at 08:10 -0500, Mike Moser-Booth wrote:
[bang~], [edge~], and [threshold~] I've noticed for sure are like this. I don't know about [vline~] since I use it to avoid having to change the block size. :-)
I happily repeat myself: There is no need to adjust the block size when using [vline~].
Yeah, that's what I was trying to say.
As Dietrich already pointed out, for some reason it stops working as expected when using a blocksize< 64. I don't why this is and I suspect it to be a bug.
I don't know, either. I initially just suspected it was because [vline~] still starts outputting its vector at 64 sample boundaries. The attached patch seems to indicate it's a little weirder than that.
I don't understand Pd's code enough to say if it's just reiterating or illustrating Mathieu's point.
.mmb
Roman
On Thu, 2010-12-23 at 16:04 -0500, Mike Moser-Booth wrote:
On 12/23/10 8:51 AM, Roman Haefeli wrote:
On Thu, 2010-12-23 at 08:10 -0500, Mike Moser-Booth wrote:
[bang~], [edge~], and [threshold~] I've noticed for sure are like this. I don't know about [vline~] since I use it to avoid having to change the block size. :-)
I happily repeat myself: There is no need to adjust the block size when using [vline~].
Yeah, that's what I was trying to say.
Sorry for not reading your post carefully. That's indeed what you said.
Roman
so is it correct to state that the workaround setting block~ size down to 1 for sample correct works is not existant for
most (maybe all, not sure) signal-to-message objects
besause they
have a minimum hard limit of 64 samples.
? [?]
2010/12/24 Roman Haefeli reduzent@gmail.com
On Thu, 2010-12-23 at 16:04 -0500, Mike Moser-Booth wrote:
On 12/23/10 8:51 AM, Roman Haefeli wrote:
On Thu, 2010-12-23 at 08:10 -0500, Mike Moser-Booth wrote:
[bang~], [edge~], and [threshold~] I've noticed for sure are like
this.
I don't know about [vline~] since I use it to avoid having to change
the
block size. :-)
I happily repeat myself: There is no need to adjust the block size when using [vline~].
Yeah, that's what I was trying to say.
Sorry for not reading your post carefully. That's indeed what you said.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 24 Dec 2010, Dietrich Pank wrote:
so is it correct to state that the workaround setting block~ size down to 1 for sample correct works is not existant for most (maybe all, not sure) signal-to-message objects besause they have a minimum hard limit of 64 samples. ?
It's the same problem as I explained today. logical time is not correct in those circumstances. I don't know how to fix it, only how to fudge [vline~] so that the test patch appears to work.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 2010-12-24 at 00:52 +0100, Dietrich Pank wrote:
so is it correct to state that the workaround setting block~ size down to 1 for sample correct works is not existant for
most (maybe all, not sure) signal-to-message objects
besause they
have a minimum hard limit of 64 samples.
The good news is that there are still ways to create sample accurate signal-to-message converters that work at any blocksize (incl. 64).
Use [tabsend~] to write every block of the incoming signal to a [table] and perform the analysis in the message domain by iterating through the table. This approach might be a bit more expensive CPU-wise than a using a dedicated objectclass written in C, but for simple analysis like threshold and peak detection you probably won't notice it.
Please note that events created like this are exactly one block late since you can only start the analysis after the whole vector has been written.
Roman
On Fri, 2010-12-24 at 08:51 +0100, Roman Haefeli wrote:
On Fri, 2010-12-24 at 00:52 +0100, Dietrich Pank wrote:
so is it correct to state that the workaround setting block~ size down to 1 for sample correct works is not existant for
most (maybe all, not sure) signal-to-message objects
besause they
have a minimum hard limit of 64 samples.
The good news is that there are still ways to create sample accurate signal-to-message converters that work at any blocksize (incl. 64).
Use [tabsend~] to write every block of the incoming signal to a [table] and perform the analysis in the message domain by iterating through the table. This approach might be a bit more expensive CPU-wise than a using a dedicated objectclass written in C, but for simple analysis like threshold and peak detection you probably won't notice it.
Please note that events created like this are exactly one block late since you can only start the analysis after the whole vector has been written.
This also applies to [vsnapshot~] and I don't even know if that works correctly at blocksizes < 64.
Roman
On Fri, 24 Dec 2010, Roman Haefeli wrote:
This also applies to [vsnapshot~] and I don't even know if that works correctly at blocksizes < 64.
Or even at blocksizes >= 64 whenever a smaller-[block~]ed patch is inside a bigger-[block~]ed patch.
(I think that this needs some repeating so that some people notice it)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 2010-12-24 at 07:23 -0500, Mathieu Bouchard wrote:
On Fri, 24 Dec 2010, Roman Haefeli wrote:
This also applies to [vsnapshot~] and I don't even know if that works correctly at blocksizes < 64.
Or even at blocksizes >= 64 whenever a smaller-[block~]ed patch is inside a bigger-[block~]ed patch.
(I think that this needs some repeating so that some people notice it)
Yeah, thanks for pointing out.
Roman
On Fri, 24 Dec 2010, Roman Haefeli wrote:
The good news is that there are still ways to create sample accurate signal-to-message converters that work at any blocksize (incl. 64). Use [tabsend~] to write every block of the incoming signal to a [table] and perform the analysis in the message domain by iterating through the table. [...] Please note that events created like this are exactly one block late since you can only start the analysis after the whole vector has been written.
If when using [block~ 16], [vline~]'s logicaltime is 4 blocks in advance, then 3, then 2, then 1, then 4 again, etc., I don't see why it wouldn't be the same for [tabsend~]. This means [tabsend~] would write four blocks at the same logicaltime, and if you expect a [metro] to work here, you get always 4 times the same block, which is always the last block of any sequence of blocks that shared the same logicaltime.
Can you verify this property of [tabsend~] ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 23 Dec 2010, Dietrich Pank wrote:
vline~ doesn't work in block~ sizes <64
right. Actually, inside 4 consecutive calls to vline_perform, clock_getlogicaltime() returns 4 times the same value, when using blocksize=16.
With blocksize=32, it's only 2 times the same value. You can suppose that for all blocksizes<=64, it's 64/blocksize times the same value.
It doesn't look like it's a bug in [vline~] : it looks like a bug in Pd's dsp engine.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Just one thought about the "in between samples" thing.
In recent times there has been some discussions about inter-sample peaks. For more discussion there is an article about it with a free software download on the SSL site:
http://www.solid-state-logic.com/music/x-ism/
But I don't know if the author of the original post was talking about that.
Best Jurgen
On Dec 22, 2010, at 10:01 PM, brandon zeeb wrote:
If Pd's default block size is 64 samples, and "events" are only processed at the beginning of a block cycle.
Therefore, if you're running at 48,000hz sample rate, then your "Event Rate" is 750hz. Likewise a 96,000hz sample rate will give you a 1500hz "Event Rate".
As Mathieu mentioned, if you need anything higher than this, your only options are: Decrease your block size Calculate at audio-rate using ~ objects As for "between samples", are you referring to some kind of upsampling? In that case, either increase the sample rate of a sub-patch using [block~] relative to the current sample rate, or use either a [delread~]/[delwrite~] pair or [fexpr~] to hold the last sample value from a given stream for calculation.
~Brandon _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list