dlehrich@gmail.com

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?

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?


sample-accurate-position-in-sfplay-using-hr-objects

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?

- user hr objects to perform desired math operation

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
 - ?

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.
>
>
- 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)

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?

> 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?

using hr objects only makes sense when you need a precision

higher than 24 bit - but you are not calculating anything 

hr starts to become useful when you want to divide your 

sample amunt (44,100*60,000 samples in your example) by

when converting between ms and samples proper rounding

when going from int to float (+ 0.5) should be enough.

> 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?

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

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?

>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?


> 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 

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 

> 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.

>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

>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

> 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 

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.

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.

>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.

>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.

sample accurate position in sfplay~ using hr objects