[sdiy] Sampler mode...

[Seb Francis]

ASSI wrote:
>
>> In actual fact it would
>> be better to search for the 'next' rather than 'nearest'
>> zero-crossing otherwise it doubles the number of SRAM reads
>> necessary.
>>     
>
> I can't see this happening in your setup, you would probably need less 
> read bandwidth and CPU cycles just reading two streams at the splice 
> point and crossfade them.
>
>   

I don't see why it wouldn't be possible.  The dsPIC in question runs at 
40MIPS, and it's 10ns SRAM so no need to wait between setting the 
address and reading the data .. and it's only necessary to read the 
MSbyte of each sample to detect zero-crossings, rather than the whole 16 
bit word.  The critical stuff will continue to be handled in the ISR and 
the zero-crossing detection will just tick along until it finds one.

So it might take a few ms between changing the sample point and finding 
the zero-crossing, but this isn't going to matter.  Until the 
zero-crossing is found the sample point can stay where it is, and then 
it will switch.  For a sample being triggered repeatedly at e.g. 1/16 @ 
120bpm, there's 125ms between triggers.  And for a continuously looping 
sample, the loop period is likely to be longer than that.

It's probably true that it would be more efficient to just crossfade the 
loop points, but this doesn't always sound as smooth.

An alternative is to analyse the sample as it's being recorded, and 
store a table of zero-crossing points.  If one uses a control resolution 
of 1024 points with 3 bytes needed to store each address, then that's 
3KB of RAM needed and the dsPIC in question has 16KB.

When the hardware is built I shall have a play around and see what 
works.  I'm sure there's a way to do it though.


>> It's doable, but some hysteresis of the CV inputs would be
>> important otherwise any ADC noise will burn lots of CPU time in
>> looking for nearest zero-crossings when the CV didn't really
>> change.
>>     
>
> Then there's the insignificant problem of what should happen when you 
> change the loop point while you are actually doing the splice...
>
>   

Well you would just keep the old loop point until it's not 'in use' any 
more.  But I really think the x-fade splice is not going to be the best 
way to do it anyway.

Seb