Hi,
I have tried to make a 64-Step-Sequencer-Patch with Tables (I tried it with wave/play-objects but later i would like to play wav/raw from memory or sdcard). When I try to upload it, the Axoloti runs out of Memory ^^ ..
Has somebody made something equal? maybe some example for me?
are you using the sdram version of the tables? you will need to use these for larger tables.
Maybe I don't understand tables well enough, but wouldn't you only need 64 tables if you were making a 64 track sequencer. I think this is why you're running out of memory.
This could be a thing 
I also don't understand tables, yet. I'm just trying around and try to understand whats going on.
Is there a example how that would look like for one track?
A table is like an array of values, so you'd want to step through it with an index from a counter.
aaaaaaaaahhh .. I think I understand it a litle bit more now. I made a table for each step, but I would only need one table (64) and count me through the steps, right?
I believe so. It's an approach to a sequencer that I've not tried yet, but it seems like it should work.
I think this partly depends upon how many values you want to store per step....
a sequence might have, gate, velocity, pitch, per step....
now there are many ways to store this
lets consider a 16 step sequencer...
you could then have 3 tables each of 16 length (i.e. a value represent a step) is the most obvious,
but the way Ive done it, as i found a bit more flexible is to store in one table
e.g. in this case a table of 16 elements, and 3 'attributes', is a table of 48 length
what you do then is store as gate, pitch, velocity
GPVGPVGPV etc.
so the index is
i = STEP * (number of attributes) + attribute
e.g.
so for this example where we have 3 'attributes' (gate (0) ,pitch (1),velocity (2)) ,
if we want to access step 5 pitch it is
i = STEP * (3) + 1
the reason I use this approach is it expands easily to many attributes, and you can also add extra dimensions, e.g. you can store multiple voices...
(this is what I did in the challenge a few months back , sequencing multiple attributes for multiple voices)
this works well if you want the same resolution for the attributes... multiple tables work better where the size of the attributes differ. (e.g. some 8b, some 16b some 32b)
oh, and use the appropriate table type (8,16,32b) depending upon the resolution you need, as each is double the size of the next.
Note: those will a C background, will be familiar with this approach... as you can switch better allocating/allocating multidimensional arrays, and pointers using a linear syntax.
Clever! I hadn't thought of interlacing it. Can you use multiple table read objects on the same table? Otherwise I would think there might be synchronisation issues.
of course... its single threaded, and the read doesn't change any index etc.
@AdmiralCrunch Id also recommend the help file associated with tables, its a little heavy going to understand at first, but its a hold mine of information
@johannes whilst looking at the help file for tables, I think we should change the init of table 1 and 2
rather than (t1 example)
int i;
for(i=0;i<LENGTH;i++)
array[i]= 2*i;I think they should read
int i;
for(i=0;i<LENGTH;i++)
array[i]=i << (21 - GAIN);I think generally we should really try to avoid (and replace where we see them) these combined bit shifting operations or use of magic numbers... with constants the compiler will evaluate them, so its a good idea to code explicitly so others can understand whats going on.
(it took me a few minutes to understand why t1 was being multiplied by 2, until i remembered the 'automatic' gain on table values)
guys, this is awsome .. thank you so much!!
I have made a general noob mistake, but now i think i got it
will post my patch as soon as it is ready
How is it going with the sequencer? I want to build the same thing and I thought it might be useful to share our WIP 