Hi all,
I posted this at pd-everywhere - then realized (was reminded!) that that's really a libpd list...
Here’s my setup: I’m using a phasor~ to read data out of an array using tabread4~. And I’m using snapshot and metro to let me know current position in that file. Basically, metro pings the snapshot object on an interval and gives me a reading of where we are. I’m trying to fire a bang exactly when the sample is looped.
I’d love it if an event would fire when we’ve reached the end of the array. But as far as I can tell, there’s no such event.
And, because metro runs on an interval, I don’t have sample accuracy. Snapshot will not reliably give me the zero position – it’ll just give me something close to zero, as it’s dependent on the metro interval, which has no relation to when the sample actually loops. (Hope that makes sense!)
I’ve been able to make this work decently using expr, but again, it’s not sample accurate.
So, is there a way to send a bang precisely when a sample is looped using tabread4~?
Thanks…
On Sun, Jul 15, 2012 at 10:25 PM, Jim Kremens kremens@gmail.com wrote:
And, because metro runs on an interval, I don’t have sample accuracy. Snapshot will not reliably give me the zero position – it’ll just give me something close to zero, as it’s dependent on the metro interval, which has no relation to when the sample actually loops. (Hope that makes sense!)
You don't need information from [tabread4~ ], but from [phasor~] to do that. The value of phasor~ increases except for one moment, the moment your new loop starts. So check while comparing each current sample [n] to the one before [n-1] for the moment [n] < [n-1]. You can do that with [expr~ if($v1<$v2, 1, 0)] and do for example the following:
[expr~ if($v1<$v2, 1, 0)] | [env~] | [== 0] | [change] | [sel 0] | [bng]
Connect [phasor~] to the left inlet of [expr~]. Connect [phasor~] also to [biquad~ 0 0 0 1 0] or if you have zexy to [z~] and connect its outlet to the right inlet of [expr~].
There might be other possibilities but this should work.
On 07/15/2012 07:43 PM, Funs Seelen wrote:
You don't need information from [tabread4~ ], but from [phasor~] to do that. The value of phasor~ increases except for one moment, the moment your new loop starts. So check while comparing each current sample [n] to the one before [n-1] for the moment [n] < [n-1]. You can do that with [expr~ if($v1<$v2, 1, 0)] and do for example the following:
[expr~ if($v1<$v2, 1, 0)] | [env~] | [== 0] | [change] | [sel 0] | [bng]
Connect [phasor~] to the left inlet of [expr~]. Connect [phasor~] also to [biquad~ 0 0 0 1 0] or if you have zexy to [z~] and connect its outlet to the right inlet of [expr~].
There might be other possibilities but this should work.
This is still limited to the signal vector size inside pd even at the smallest env~ buffer (which is also incredibly CPU intensive). In other words, pd by default does everything in 64-byte chunks (unless one manually alters this behaviour which with lower buffers results in a rapid increase in CPU overhead). Furthermore, if you do this with a high-freq phasor that completes its period within 64 bytes, you will begin to miss leaps that expr~ is searching for.
As an alternative, you could use disis_phasor~ external which has a second outlet and outputs a bang when it completes a period. This, while definitely as accurate as it gets within the constraints of the sig_vs, suffers from same limitations unless the signal vector is lowered. In other words, the bang will come guarranteed within the 64-byte window. But there is no guarantee that it will happen right on the 0th sample or that it will not periods that are smaller than 64-byte chunks.
If per-sample control is what you crave, you can either mess with sig_vs message to pd (or whatever it is, can't remember it off top my head) and deal with the cpu overhead, design your control entirely in signal land, or go with something like chuck programming language (which also has a considerably higher cpu footprint for the same reasons).
HTH
On Mon, 2012-07-16 at 01:29 -0400, Ivica Ico Bukvic wrote:
If per-sample control is what you crave, you can either mess with sig_vs message to pd (or whatever it is, can't remember it off top my head) and deal with the cpu overhead, design your control entirely in signal land, or go with something like chuck programming language (which also has a considerably higher cpu footprint for the same reasons).
Pd does indeed provide an infrastructure for sub-sample accurate control message timing. You don't have to adjust the block size to 1 (which would still be only sample accurate, besides being utterly expensive).
Roman
From: Ivica Ico Bukvic ico@vt.edu To: Funs Seelen funsseelen@gmail.com Cc: pd-list@iem.at Sent: Monday, July 16, 2012 1:29 AM Subject: Re: [PD] is there a way to send a bang precisely when a sample is looped using tabread4~?
On 07/15/2012 07:43 PM, Funs Seelen wrote:
You don't need information from [tabread4~ ], but from [phasor~] to do that. The value of phasor~ increases except for one moment, the moment your new loop starts. So check while comparing each current sample [n] to the one before [n-1] for the moment [n] < [n-1]. You can do that with [expr~ if($v1<$v2, 1, 0)] and do for example the following:
[expr~ if($v1<$v2, 1, 0)] | [env~] | [== 0] | [change] | [sel 0] | [bng]
Connect [phasor~] to the left inlet of [expr~]. Connect [phasor~] also to [biquad~ 0 0 0 1 0] or if you have zexy to [z~] and connect its outlet to the right inlet of [expr~].
There might be other possibilities but this should work.
This is still limited to the signal vector size inside pd even at the smallest env~ buffer (which is also incredibly CPU intensive). In other words, pd by default does everything in 64-byte chunks (unless one manually alters this behaviour which with lower buffers results in a rapid increase in CPU overhead).
You mean like [block~ 1]?
-Jonathan
Hi Jim
On Sun, 2012-07-15 at 16:25 -0400, Jim Kremens wrote:
Here’s my setup: I’m using a phasor~ to read data out of an array using tabread4~. And I’m using snapshot and metro to let me know current position in that file. Basically, metro pings the snapshot object on an interval and gives me a reading of where we are. I’m trying to fire a bang exactly when the sample is looped.
Don't measure something when that something can be known beforehand. Instead of a [phasor~] I'd use a [vline~] to control the play head. Then you only need to tell [vline~] in what time it should play your table. You can use the exact same value to control a [metro]. Example:
[metro 2000] <- 2s interval | [0, 88200 2000( <- play the 88200 samples of your table in 2s | [vline~] | [tabread4~ yourtable]
(You really want [vline~] here and not [line~] as only the former is able to start ramps in the middle of blocks)
I’d love it if an event would fire when we’ve reached the end of the array. But as far as I can tell, there’s no such event.
No.
And, because metro runs on an interval, I don’t have sample accuracy.
[metro] is indeed sample accurate, it's even sub-sample accurate. So is [delay]. However, only some tilde-classes make effective use of it, namely [vline~] and [vsnapshot~].
There are lots of threads about this topic in the archive. If you're interested, please check: http://www.google.com/?q=site:lists.puredata.info+vline~
Roman
On Mon, Jul 16, 2012 at 2:26 AM, Roman Haefeli reduzent@gmail.com wrote:
Hi Jim
On Sun, 2012-07-15 at 16:25 -0400, Jim Kremens wrote:
Here’s my setup: I’m using a phasor~ to read data out of an array using tabread4~. And I’m using snapshot and metro to let me know current position in that file. Basically, metro pings the snapshot object on an interval and gives me a reading of where we are. I’m trying to fire a bang exactly when the sample is looped.
Don't measure something when that something can be known beforehand. Instead of a [phasor~] I'd use a [vline~] to control the play head. Then you only need to tell [vline~] in what time it should play your table. You can use the exact same value to control a [metro]. Example:
[metro 2000] <- 2s interval | [0, 88200 2000( <- play the 88200 samples of your table in 2s | [vline~] | [tabread4~ yourtable]
I agree with you Roman--the solution is to use metro+vline or delay+vline. In either case, you get the bangs exactly when the new loop starts.
Where it's different: when changing the delay value, your loop will no longer reach the end of the table when it starts over. This could introduce clicks. That's where phasor~ has the advantage.
I think you could compensate for that with a line object that counts down the interval. When you provide it another message telling it to change the rate, you'd know exactly how much time is left in the current loop and provide another message to vline~ to make sure it speeds up to compensate.
On 15/07/12 22:25, Jim Kremens wrote:
[...]
HereÂ’s my setup: IÂ’m using a phasor~ to read data out of an array using tabread4~. And IÂ’m using snapshot and metro to let me know current position in that file. Basically, metro pings the snapshot object on an interval and gives me a reading of where we are. IÂ’m trying to fire a bang exactly when the sample is looped.
IÂ’d love it if an event would fire when weÂ’ve reached the end of the array. But as far as I can tell, thereÂ’s no such event.
And, because metro runs on an interval, I don’t have sample accuracy. Snapshot will not reliably give me the zero position – it’ll just give me something close to zero, as it’s dependent on the metro interval, which has no relation to when the sample actually loops. (Hope that makes sense!)
IÂ’ve been able to make this work decently using expr, but again, itÂ’s not sample accurate.
In my humble opinion it would *really* help to know what you're trying to achieve overall and why you want sample accuracy, unless this is a purely theoretical question :)
Lorenzo.
Hi all,
Thank you for the answers!
"In my humble opinion it would *really* help to know what you're trying to achieve overall and why you want sample accuracy, unless this is a purely theoretical question :)"
I shouldn't have used the phrase 'sample-accurate.' I really just need it to be pretty accurate. My current hack solution is accurate to within 50 milliseconds, which is the rate at which my metro object pings phasor. Every time metro fires I use expr to evaluate the position of phasor.
This link (thanks!) has a lot of options that should help: http://puredata.hurleur.com/sujet-6194-sample-played-automated-varying-speed...
Thanks again! I'll report back...
On Mon, Jul 16, 2012 at 12:11 PM, Lorenzo Sutton lorenzofsutton@gmail.comwrote:
In my humble opinion it would *really* help to know what you're trying to achieve overall and why you want sample accuracy, unless this is a purely theoretical question :)
-
Charles Henry -
Funs Seelen -
i go bananas -
Ivica Ico Bukvic -
Jim Kremens -
Jonathan Wilkes -
Lorenzo Sutton -
Roman Haefeli