speed/memory balance, bankstick transfer question

[th0mas]

Hi all,

  First off.. thank you everyone involved in creating this project (obviously especially TK).  It appears to be quite nice and easy to work with.

I'm writing a x0x style sequencer (yes I've seen the other threads, but I want to do it myself :) ) from the clockbox example and have a couple questions, as I have not ever written PIC code before.

I've been mostly programming for efficiency with regards to size: for example, in a "pattern" struct, I need 4 bits to store which midi channel each part plays on, so I've been storing 2 midi channels in each byte and using only 4 bytes instead of 8 (for each of the 8 parts), then I just extract them as needed using '>>4' or '& 0x0f'.  Is this overkill?

Also, my pattern struct is 320 bytes (5 pages).  Can I read 320 bytes from the bankstick on the fly without jittering timing?  If so, how?  (I haven't tried just plainly 'doing' it, as I haven't received my modules yet and am just coding without testing :) ).

Cheers,

Tom

[TK.]

Hi Tom,

reading 320 bytes at once will cause a delay of ca. 8-10 mS, this is not acceptable.

But if you would read the data on-the-fly (with each step) the delay would be ignoreable.

Small calculation example: let's say you are storing the whole MIDI event in the BankStick memory, reading three bytes takes ca. 75 uS, and sending them via MIDI takes 960 uS. Since the MIDI IO is buffered and works interrupt driven, you wouldn't notice any delay caused by the BankStick, only the delay caused by MIDI transfers (which cannot be avoided...)

However, this method would mean, that data has to be stored in the BankStick immediately if realtime changes should be made possible. But even this could be implemented in a way where you don't notice delays.

Here again a calculation example: let's say the pattern is played with a speed of 140 BPM. The clock process is triggered each 24 mS. Saving one byte into EEPROM takes ca. 2 mS (if I remind correctly).

So, if you save an edited note after a step has been played, you won't notice a delay.

A data cell can be overwritten more than 1M times, so I guess that for a DIY project this method is acceptable. Advanced solution: buffered saving (store changes in a buffer, and save them after one second if no button/encoder has been moved during this time, store it immediately if a new step is selected). Thats the way how the integrated wavetable editor of MBSID is working

Best Regards, Thorsten.

[th0mas]

I'm planning on having any changes made on the fly not be saved to the patch, like the way the korg electribes work.  To save you have to be stopped and press "save".  Saves writing issues on the fly.

Thanks for the reply, I'll kick some ideas around in my head.

Cheers,

Tom

[TK.]

No problem, just duplicate the EEPROM content in RAM, and load it into memory while the sequence is played (with each step just the new data). And load it immediately from EEPROM if a step is modified while it hasn't been preloaded yet. The same "step-by-step" method can be used for EEPROM writes.

Best Regards, Thorsten.