[Stk] bug in JCRev? (oHop too big)

[Gary Scavone]

Yes, in fact this is a bug in many or all of the Effects classes.  I fixed it a while back in my own version with the hope that a new release would be forthcoming shortly.  Needless to say, things have been delayed more than I expect.  But hopefully, the new release will happen this Spring.

Regarding block-based processing, I considered it but eventually didn't bother because:

- the possible performance improvement is not necessarily great (based on a few basic tests)

- there is the possibility of introducing yet more bugs 

- modern CPUs are so fast now that I'd rather spend my time on other issues

Best,

--gary

On 2011-03-01, at 7:10 PM, Morgan Packard wrote:

> Hello all,
> 
> FYI, I think I've found a bug in the multi-frame version of JCRev :: tick. The method was hopping three samples on every input frame instead of two samples.
> Perhaps I'm using it incorrectly, but it looks to me like no one has ever tested this method. Anyway, after a simple adjustment to oHop, it works fine for me. My fix is here:
> 
> http://tinypaste.com/7b6860
> 
> Also on the subject of JCRev, I noticed that it's calculating frames sample-by-sample rather than in blocks of StkFrames, which is not the most optimized way to do things. Is there a reverb in STK which has been written with more of an eye toward performance? I hesitate to offer to optimize this class since I'm basically a noob with regard to both DSP and C++, but I'd be happy to contribute if I can.
> 
> thanks,
> 
> -Morgan
> 
> -- 
> ================================
> Web:
> http://www.morganpackard.com
> 
> Music/Art:
> Latest album: Moment Again Elsewhere
> iOS app Thicket available on iTunes store.
> ================================
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk