sample accurate position in sfplay~ using hr objects
The "new features" section of the sfplay~ help file shows how to output the current position and roundoff errors from an sfplay~ object. It also makes reference to adding the signals using "hr" objects to get sample accurate position values.
I have downloaded the hr objects from the cycling 74 user pages, but i'm not sure how to properly implement them into my patch. Ideally, I would like to the final output to be a single float value that gives me the most accurate position possible.
I've searched around, but can't find any more info on this. Does anyone have any advice or sample code for the best way to implement this?
Quote: doctor op wrote on Mon, 04 December 2006 11:31
----------------------------------------------------
> The "new features" section of the sfplay~ help file shows how to output the current position and roundoff errors from an sfplay~ object. It also makes reference to adding the signals using "hr" objects to get sample accurate position values.
>
> I have downloaded the hr objects from the cycling 74 user pages, but i'm not sure how to properly implement them into my patch. Ideally, I would like to the final output to be a single float value that gives me the most accurate position possible.
>
> I've searched around, but can't find any more info on this. Does anyone have any advice or sample code for the best way to implement this?
----------------------------------------------------
- convert number values to steady signal
- user hr objects to perform desired math operation
- round down to 32 bit
- convert back to number
- ?
-110
> The "new features" section of the sfplay~ help file shows how to output the current position and roundoff errors from an sfplay~ object. It also makes reference to adding the signals using "hr" objects to get sample accurate position values.
>
>
- convert number values to steady signal
- user hr objects to perform desired math operation
- round down to 32 bit
- convert back to number
- ?
>
I understand the theory behind it (that I'm supposed to add the values using hr)... but I'm confused about the actual conversions between 32 and 64 bit. I guess if I add the current position and roudoff errors (which come out of sfplay in 64-bit, right?) then I get the most accurate position possible. But how do I convert back down to 32 bit for use in my patch? And if I do that... aren't I losing any percision I might have gained from doing this operation in the first place?
> The "new features" section of the sfplay~ help file shows how to output the current position and roundoff errors from an sfplay~ object. It also makes reference to adding the signals using "hr" objects to get sample accurate position values.Does anyone have any advice or sample code for the best way to implement this?
Still pretty confused here. (I'm also unable to open the help patches for the hr objects, which makes things difficult).
The patch below is copied directly from the sfplay~ help file. I'm attempting to use the hr.+~ object to add the signals, but I'm not getting any output. I know I must be doing something wrong, but I can't figure it out. Does anyone have any ideas?
(note: you need the hr objects, available from Joshua Kit Clayton's user page at Cycling 74, to run this)
Thanks,
Dan
> The patch below is copied directly from the sfplay~ help file. > I'm attempting to use the hr.+~ object to add the signals, but > I'm not getting any output. I know I must be doing something > wrong, but I can't figure it out. Does anyone have any ideas?
what are you trying to do in this patch?
using hr objects only makes sense when you need a precision
higher than 24 bit - but you are not calculating anything
here but one addition.
hr starts to become useful when you want to divide your
sample amunt (44,100*60,000 samples in your example) by
4001,9671993034
when converting between ms and samples proper rounding
when going from int to float (+ 0.5) should be enough.
>what are you trying to do in this patch?
>using hr objects only makes sense when you need a precision
>higher than 24 bit - but you are not calculating anything
>here but one addition.
The help file says simply "add these two signals using 'hr' objects to get sample accurate position for long files".
That's all I'm trying to do... I have a long file playing in sfplay~ and I need the most accurate possible position as an output. Maybe I am misunderstanding the help patch?
On Dec 5, 2006, at 1:31 PM, Dan wrote:
> The help file says simply "add these two signals using 'hr' objects
> to get sample accurate position for long files".
>
> That's all I'm trying to do... I have a long file playing in
> sfplay~ and I need the most accurate possible position as an
> output. Maybe I am misunderstanding the help patch?
One 32bit signal will be sample accurate up to 6 minutes or something
like that. If you need sample accurate count for longer files, you
can use the hr objects. However, keep in mind that you can't just
convert back to single precision as in your patch. I would recommend
you spend some time re-reading the hr.readme.pat. It should be clear
after reading this why--i.e. you only have near double precision
*within* the hr objects themelves (by using two signals for what
would be one with ordinary MSP objects...internally these two signals
are added to make one for use inside each hr object).
One way to approach a conversion to multiple single resolution
signals from the hr style signals would be to use something like the
following patch to break it down into second and millisecond signals.
The millisecond signal would then always be sample accurate within a
second (for sampling rates below several gigahertz), and the second
signal should be second accurate to something like a few billion
seconds.
Keep in mind however, you can't just add these signals again with
single precision objects, or else you're suffering the same
limitations as you're trying to avoid in the first place. Kind of
tricky, but these are the limitations of our 32bit world, and some
ways to work around them.
-Joshua
>One 32bit signal will be sample accurate up to 6 minutes or something
>like that. If you need sample accurate count for longer files, you
>can use the hr objects. However, keep in mind that you can't just
>convert back to single precision as in your patch. I would recommend
>you spend some time re-reading the hr.readme.pat. It should be clear
>after reading this why--i.e. you only have near double precision
>*within* the hr objects themelves (by using two signals for what
>would be one with ordinary MSP objects...internally these two signals
>are added to make one for use inside each hr object).
Joshua - thanks for your concise reply. I did read the help file hr.readme a few times... I understand the basic idea that 64-bit is more precise than 32-bit and why, but I guess some of the concepts went over my head (that's what I get for being a musician masquerading as a "programmer", I guess).
As it turns out... I only need precision for about 5 minutes at a time, so I ended up just using the single position output from sfplay~ and everything seems to be working fine. But it's nice to know in the future that I can count on accuracy for billions of seconds. :-)
One question about the hr objects... I put hr.help into my max-help folder, but if I try to open the help file for an individual object (e.g. "hr.+~") I get a message saying "no help file found". Are there supposed to be help files for the individual objects, or is the hr.readme the only help
Thanks
Dan
On Dec 6, 2006, at 11:50 AM, Dan wrote:
> One question about the hr objects... I put hr.help into my max-help
> folder, but if I try to open the help file for an individual object
> (e.g. "hr.+~") I get a message saying "no help file found". Are
> there supposed to be help files for the individual objects, or is
> the hr.readme the only help
As mentioned in the hr.readme.pat, there's only help for the few
objects which (at the time of original writing) didn't have standard
object counterparts. For all other objects, they operate the same as
their standard counterparts, but with two signal inlets/outlets for
every one in the standard object version.
-Joshua
>As mentioned in the hr.readme.pat, there's only help for the few
>objects which (at the time of original writing) didn't have standard
>object counterparts. For all other objects, they operate the same as
>their standard counterparts, but with two signal inlets/outlets for
>every one in the standard object version.
Ah yes... indeed it does say that. Must have missed it the first time around.
Thanks
Dan