hi-fi ish looper

[multi_s]

i think for parallel ram you just have an address bus, a data bus and a control bus. all you have to do is put the address (in binary) of the cell you want to acces on teh address bus and then select read or write with the control bus. Then if your writing, whatever your putting on the data bus gets written to the coresponding address, or if your reading whatever is in that cell appears on the data bus and you can read it into the MCU.

it is sort of a pain in the ass to do with pic32 even because the PMP only has a 16 bit address port which is say for 8 bit/address ram only a 32kb piece of ram. but maybe useful to get the idea from the ref manual at least on how it could work.

http://ww1.microchip.com/downloads/en/D ... 61128G.pdf

you could just set GPIOs manually though accross many PORTx's to form a larger address. its more coding but it should work? im pretty sure the ram only reads the data/address buses when you tell it to via the control bus so if the bits dont all show up simultaneously its not that big a deal.

if you look at ARM typs mcus yousee they have special DDR ram ports that do the same thing as the PMP but have much wider address busess and noice peripherals for standard types of ram.. having a wider address bus -> using larger rams -> ultimate victory. good luck (:

also i moved so maybe see yo uless but im just on esplanade now,

[cloudscapes]

I'm gonna stick with PIC32s for now I'm not smart enough to hop between architectures that quickly

well I already understood the theory between parallel ram. occasionally reading datasheets of it for a year withotu actually doing anything. I just have to try and and test which method works best.

setting up PMP and stuff, eh, no hurry. I think I'll just start by bit-swapping between the various address pins and a long int address. I've got a MB so I think that's 20 address pins. yeah I'll waste a hundred or so MCU cycles. but its simple. then later when I have the basics of a program running and have gotten a feel for the ram, maybe I can worry about more elegant stuff I think. I'll read that PDF this week, still.

how the new place?

[multi_s]

ya i was able to do it witha dsPIC33 actually and i forget the exact ram model, but it was a2 MBit piece. and i agree with you even if it is many cycles, its still going to be more than fast enough even 44 kHz or more. it doesnt quite take 100 but maybe the result was ~35 cycles a read.

i am sticking with PICs as well because i am also slow to learn things and i dont have much time lately. maybe eventually try something arm based or who knows. I am doing some stuff at a job with something arm based but the hardware was already designed and the I/O is pretty minimal so its not quite the same. ie i dont really feel i know much about arm.

also i might get a small cnc soon so maybe i can cut those square holes for you. i just want to make shit with sliders.

[cloudscapes]

another reason why I think I'm gonna just manually "remap" pins that way is for ease of pcb layout. on the pic, pins are all "out of order" so it would be much easier to have 30 pins all march into the ram neatly and without 500 vias and shit.

cnc! that's dope! is that part of the community project that bunch of us talked about 6 months back?

[cloudscapes]

microchip need to get off their asses and offer us an upgraded 23k256

say, 2mb? as long as its SPI

[multi_s]

ya i do not understand why no one making serial ram beyond 256 kbit. many other companies seem to make somethign similar to the one microchip does but they all are only 256 kbit max.

for a while i was thinking about switching to another platform just because with microchip i always feel liek the stuff it *almost* exactly what you always wanted. but ya i havent really been doing much of anythign with pedals other than i got I2S codecs working with PIC32MX1/2 series after that other thread a while back. You were right it works different then with dspic33 for sure but its actually easier to setup the pic32 at least. The PIC32 reference manual on the SPI port covers it pretty well actually.

as for the cnc no its not part of that lab Nichole Roberge was/is running. I have still never been there actually but it sounds pretty interesting. I have space in the place Seripop prints in now so i will probably put it there. ill keep you posted. its jsut asmall guy, nothing too crazy. i really want to start using screens and so on so if this works out it will hopefully allow that.

[cloudscapes]

I might try a codec ic again. I found a codec board with some code examples for my compiler, mx3/4/5/6/7.
http://www.mikroe.com/products/view/484 ... ard-proto/
it's still a little alien though. with frame modes and shit. I'll figure it out eventually.

there are FRAM chips with more memory than the microchip ones, spi and 8pin package, but really really expensive. MRAM too.

[multi_s]

ya im sure you could handle it. (:

in the end it is just 3 clocks and 2 data streams. all the clock speeds are determined by your sampling rate and resolution basically. and well you have a data in and data out which i think we can all figure out what to do with.

[tuffteef]

I WISH I UNDERSTOOD!

[cloudscapes]

ya im sure you could handle it. (:

in the end it is just 3 clocks and 2 data streams. all the clock speeds are determined by your sampling rate and resolution basically. and well you have a data in and data out which i think we can all figure out what to do with.

I just hope I can smoothly change the samplerate at will. from the little I understand about codecs, it might be a bit complicated, since (I think) the spi/data clock needs to scale with the samplerate.

I've been thinking on how to speed up/slow down a loop without changing a dac's/codec's samplerate in code, too. I'm sure it can be done, though I haven't figured out yet. tempted to rip apart the couple pedals I have that use codecs and probe their clocks/data, see if they scale the clock or do it some other way.

I WISH I UNDERSTOOD!

we're talking about gardening dude

[multi_s]

ya it is easy. you can jsut interpolate between 'real' samples basically. if you want to be perfect, lpf then interpolate. i guess you would have to up sample to send back too though which is also doable. i did this actaully on the nasa attribute but not with a I2S/hifi codec. the sampling and playback rates are always fixerd but i interpolate between playback values to get a pitch shift. Like having less samples but actually you make new samples from the stored values. maybe that makes sense. (;

[cloudscapes]

where my brain sorta folds in on itself is when I'm interpolating, or "creating" in-between samples at a number that isn't an integer multiple of the true samplerate. it's easy enough to interpolate so that I get x2, x3, x6, x75, etc, or if slowing down, then drop every 2nd or 3rd sample. but x1.3 speed, or x0.97 speed, or x3.1415, etc.

or maybe I could set up two timers. one that is set at the fixed "true" hardware samplerate, and another set at the samplerate I want it to sound like (or speed up/slow down if looping). at each 2nd timer interrupt, have it see at what percentage it's between the last and the next sample, then blend accordingly. I'm sure there's a more intelligent way of doing it. and it kind of falls apart if the true samplerate is greater than 2x and then it has to blend between 3 or 4 samples.... argh

[cloudscapes]

I'm so happy to finally be working on pic32's though. they're so much faster than AVRs

[multi_s]

well, a simple example, without filtering to avoid further aliasing... Say you want to play something back 3.1415 times faster . Ok but as you said we only have integer number samples, i ea sample at 0, 1*Ts, 2*Ts etc (Ts is the sampling period, 1/fs). So what can you do... hrmm.

If i have my sample say in an array or buffer take the first sample from index 0 as the first sample. Next go to index 3.1415 (what?). Look, just interpolate between sample at index 3 and 4. How far in between 3 and 4 is 3.1415? Well its .1415 away from 3 and (1-.1415) away from 4. You can linearly interpolate to the sample at index 3.1415 by the following

psuedo_sample@3.1415 = (1-.1415)*real_sample[3] + .1415*real_sample[4]



thats it, a weighted average based on your position between 2 real samples. Ok so how to get the next sample? well 3.1415+3.1415 is 6.283 so you interpolate between sample 6 and 7 with weights .283(for sample 7) and (1-.283)(for sample 6). Next its 9.566 so weights are .566 (for 10) and (1-.566) (for 9). Just keep an accumulator that adds 3.1415 to itself at each sample and grab that psuedo sample.

you see your basically resampling the signal. so to be really really correct you should low pass filter (to avoid aliasing 'lol' ) the buffer at a frequency somehow proportional to 3.1415, im guessing its ~1/3.1415 (normalised) but i would have to think more about if that is true. If you search for resampling techniques im sure the info is out there.

if you want to play slower (say instead of 3.1415 we choose a value less than 1) you i dont think you have to do any filtering, its basically up sampling and can be done the exact same way.

and of course you do this at your normal sampling/playback rate. no need for extra timers, no need for averaging more than 2 samples ever, no matter what the rates are. You are only ever inbetween 2 samples.

edit: sorry there are no /2's anywhere. (deleted the now).

[BrentMpls]

Excellent write up, great thread!