Spin Semiconductor

O.K. great !

(my math/reasoning's much better than I thought... )

Thanks,

Dedjazzgadgetz
(now, off to the programming-cave... make some more Experimental Noize )

oh, say : what's the "properly pitched" lower-bandwidth down to (ballpark figure) when an internal RMP (@32kHz) is set to -512 ? -1024 ? -2048 ? and finally -4096 ? (I figure they'll be "octaves" of each other, just not real-sure of a real-life value... wild guess here : 64Hz, 3...

I know, I know ! :oops: (But it was fun -in a perverse-kinda way - trying to "reverse-engineer" donstavely's idea -if it worked at all... even if a *wee bit* frustrating. AND it got me to think waaay "deeper" into the architecture/the logic behind the FV-1; and that's not wasted ...

I think Pointer2 would suffer some disruption... jumping instantly from 0.375 (upon JAM-ing) to 0.5 ( unless... we give it a cho rda,x|x|x,-512 offset upon JAM, up until -say mid-mem. is reached... or the other way around : a +512 offset from mid-point 'til JAM ?) DARN ! :shock: Oh, well... I tried....

Someone stop me, please ! Can't help myself... :oops: -Would the Assembler categorically refuse to let me program a pitch transposer algo. with an internal " 4096 " Ramp (so far, so good ), BUT processing a specified 3584 -lenght memory (that's 7/8s) AND resetting (JAM-ing) the ramp upon ...

Thanks Frank !

You've transmorgrified my "say what ?" moment into an : a-HA ! knew it orgasm...

Again, thanks for all the dedication you put into explaining stuff over, & over, & over...

Dedjazzgadgetz
(still, I'll grind over this... maybe I could... ? )

I really can't go into all the hardware that makes the ramp, cross fade coefficient, etc. Lots of details in it, just accept that the system generates the proper ramps and cross fade coefficients. -yeah, sure: from having built discrete counters & stuff ( that's sooo long ago... ), I totally ge...

Dear Frank : I'm having one of those -"uh? say what ?" moments , again... ... quote from donstavely http://www.spinsemi.com/forum/viewtopic.php?p=1506#1506 : -"Here is one quick and easy trick that reduces the pitch shift latency by 25% : If you look closely at the behavior of the cr...

Darn !

'was afraid of that... oh well. Anyways, thanks for the update, gentlemen !

Dedjazzgadgetz

Darn ! Physics... :roll: ...oh well, at least we now have an additional latency workaround at our disposal, if needed (like donstavely's uber- brilliant ramp offset trick from http://www.spinsemi.com/forum/viewtopic.php?p=1506#1506 check EDIT below ! ) Thanks again, Frank : you'z the man ! Dedjazzg...

-Oops, just now thinking about this, Frank... Wouldn't we just be running back into the intrinsic problem of real-time pitch-transposing: -> Shorter delay mem/ faster clock = lower freq. input signal not correctly transposing ? (so, just choose a larger mem size and... -D'oh! more latency... :roll:...

Yes, that's what I was getting at by "halving the latency". O.K. cool... actually : great news !

Thanks sooooo much !

Dedjazzgadgetz

How 'bout PicKit 3... anyone tried ?

Dedjazzgadgetz

Hi Frank & everyone, of course !

Wondering about this: would a faster FV-1 clock -say, doubled (I know: not recommended) half the latency in a pitch shifter ? Guessing probably not, but... here's hoping !

Dedjazzgadgetz
(It's been a long time... family, job, life, the works ! )

Hello Frank ! Are the input/output networks of the SKRM-C8 boards pretty much/exactly what is found on the dev. board schematics ? (well, mmmh... doesn't look like it...) If not, is there a definitive SKRM schematic (I might have missed) available for reference, anywhere ? I guess if I wanted outpu...