Waveform~ "display start" inlet acting oddly

    Jimmy
    Mar 27 2013 | 10:30 pm
    Hi all,
    I've run into a problem which seems to be caused by the Waveform~ object. The attached images sums it up really; any value that I enter for the "display start" inlet is outputted slightly differently. The object uses a different number, which causes some problems for my overall patch.
    I was wondering if this is meant to happen and if there is a way around this. Thought it may be related to the sample rate, or the overall size of the buffer in samples as the object may snap to the closest sample? I can't see any clear relation though and the help files haven't helped me. I'm not sure how it works and was hoping somebody could shed some light on it. Thanks!
    • clement-montreal
      Mar 28 2013 | 2:01 pm
      are you in 44.1Khz ?
    • clement-montreal
      Mar 28 2013 | 2:16 pm
      There must be someting wrong yes, but at least here is where this value comes from : each sample in 44.1Khz should lasts 1/44100= 0.022675 ms
      1000- 0.022675 = 999.977325 ms
      this is very close to the value you are seeing onthe output of time start .
      at 1000ms , waveform should display the 44101th sample , but , because it is thinking in term of sample number ( i.e 1000ms should be the 44100th) it is displaying the sample before that , which is 1000-0.022675= 999.977325ms.
      It is not completly accurate, but that how I would explain it .
    • clement-montreal
      Mar 28 2013 | 2:17 pm
      Sorry,
      I meant : ( i.e 1000ms should be the 44101th)
    • Jimmy
      Mar 29 2013 | 9:06 pm
      Thanks for your reply! I'm working at 44.1KHz and, like you said, there seems to cause an offset of one sample (-1/44100). Simple solution was to add a [+ 0.022676] just before the Waveform~ inlet.
      Though that still hasn't completely fixed it. It seems to work for multiples of 10, but any other number is still outputted a little differently to what you'd expect. So 1010 would be outputted as 1010, but 1011 turns into 1011.020447 (that includes the + 0.022676). It seems that the discrepancy isn't a fixed number, which is what was causing me trouble in the first place... Going to have another play around with it and see if I can come up with a solution. Will post it here if I do!
    • Jimmy
      Mar 29 2013 | 9:11 pm
      I guess it could be due to the fact that numbers like 1011ms are not bang on the sample, wheras multiples of 10 are. I'll see if I can work out some kind of formula to find the difference.
    • Jimmy
      Mar 29 2013 | 10:40 pm
      Alright, this will be my last post on the subject. I think what I said in my last post is pretty much it. I'll never be able to get the output to match the input for anything that doesn't divide up nicely with the sample rate.
      The problem I was having is that I was using the output of Waveform~ as part of a data loop. The output of Waveform~ was being used to set the values of another object in my patch, and changing the values of that object altered the Waveform~ object. Basically I had two ways of controlling the same thing, and they didn't match up.
      All I have to do is quantize all values so that they always fall on the sample and both the Waveform~ and the other object match exactly. The differences here are tiny - fractions of a millisecond so I doubt it will make a difference really. I was just curious when I couldn't get the results I expected and now I know why!