Hey
Have been trying to record a LFO output signal to a table and then play it back. But I havent been succesful in making the table play it back right. I just dont know what I should use to "drive" the table play object. I tried with square lfo, constants, other lfos, etc. but it doesnt play the movement back in the way it is before it is recorded to table.
Any ideas? Thanks 
Patch: .Table record live Test.axp (4.5 KB)
I've done it like this
(The actual frequency of the osc doesn't matter)
The resolution is then 3000/sec ,
which is a bit too much , so I use this instead:
This works, but actually, I think it would be better to use something that is in sync with the tempo (so when the tempo slows down, the playback slows down too).
I have also tried with the patch @timvets made for random patterns, but with no succes just yet.
I was also thinking about how to sync to tempo. Or atleast turning on and off record must be synced so it always starts recording on a 1/4 and also stop recording on a 1/4. Or whatever subdivision you would like. That was next step after getting the table record right. Taking one issue at a time 
Anyway going to test this later tonight
@alex Can you explain the resolution 3000/sec? I don't get that part. And how you change it?
control rate is 3khz , so your write will be recording every 0.3 milliseconds.
if you are doing something with user input, depending upon resolution of your controller, then you will get away with anything from 1ms to 10ms without feeling lag. doing this will dramatically reduce the table size you need for the 'time' you want to record.
however, this is not the approach id take .. for user input
what I would do is store the 'time' and event data, such that you only record changes, especially if you are using midi (which only has 7 bit resolution, so most of the time its not changing)
ie.. you store time + value ,then a table can store N events.
the easiest way to do this is to use 2 tables,
one for time, one for value. (you could also squash into 1 potentially using a 32b table, and use top bits for time, lower for value).
time is then a loop counter 0 to N, value is value,
so with each change in value, you store the time and value in the table(s)
for 'playback' you use the loop counter, and check to see if its the same as the time table, if it is you read the value.
(you need separate counters for current position in table)
hmm, its easier to do than describe!
note: with tables (rather than a more complex data structure) you can only do overwriting overdub, you can't do any inserting, as there are (currently) no functions on the tables to insert data, and so move existing events
EDIT: I've noticed your talking about recording an LFO, I assume this is because a user is changing it... as recording anything that is constant has no purpose... in which case Id still record 'the events' not the output... i.e. the pitch changes a user is making.
for me, its all about using limited resources (like memory/cpu) carefully... if you do at the small / subpatch level, then when you start reusing in bigger patches, you will have a better chance to do what you want
nice idea, but what if your table is 'full'?
the size needs to be defined up front, so it would not really make any difference. unless you want to record a few events over a longer time period, then your approach is very handy.
I'm looping/recording knobs for just 8 or 16 beats (somewhat like Korg Volca) , so being able to add/overwrite to the loop is important.
the number events will always be smaller than the if your recording the audio/control events.
sure you have have limited size (as we don't do dynamic allocation) BUT it means you can use much less memory for the same number of events....
this is important when resources are scarce imho
no, because you'll have to allocate the table anyway, so it doesnt matter if something is recorded into it or not.The only difference is that the same number of recorded values can be divided over a longer time, but as I said, for a loop recording (overdub) it is not useful.
Anyway. using the 24ppq clock seems to work just fine and allows a long recording in a table of size 512 . Use a k-rate filter (after) the table to smooth the signal to avoid audible 'steps'. (having a 384ppq or 768ppq clock would be nice though.)
Sounds like an awesome idea recording time and value. The goal is to be able to use a midi controller and then record knob modulation into a table and play it back. I could use a lfo and just turn it on and off, but the ability to record knob modulations makes it a bit more fun and more hands on approach
I thik I need to read this a few times before it makes 100% sense to me.
@thetechnobear Could you post an example? WOuld be really helpful.
To me it is ok just to be able to record it and if it is not good enough I can just record a new version. No need to make overdubs.
As I described in the beginning of this post I am aiming for recording modulation send from my midicontroller. I used the lfo as an example mimicking knob modulations. You know for example using a midi controller to control a filter in Axoloti and the record the control movement into a table. On Kaos pad 3 it is called "Pad motion". It is almost the same. You turn on a switch and you can touch the pad and record any movement into the KP3 and play it back. But in kp3 it is not in sync.
Sync:
I am trying to figure out how to make a relay/switch system that when you turn record on, it waits with actually recording until next bar starts... and then turns of again after 2 bars(or whatever length you set). So the recording is in sync all the time..... Still thinking about how to make this. I have tried to make one version but didnt succed yet. Need to try a few times I think. But then next step would be how to play those 2 bars back again, ALSO in sync.... Maybe technobears approach will work for this. Would really like to see an example, cause I am not 100% sure how to make it.
wrong, since you usually will record less values for any time T, you can use a smaller table.
also, your approach of dividing the time, essentially quantises events... fine if thats what you want, but is not usually what you want for automation.
anyway, it was an alternative, for consideration... some cases its useful, others not.
(I thought by describing the implementation, its reasonably clear where the boundaries of conditions are of usefulness are)
@jaffasplaffa - I'll see if i can get some time to sketch something out.
ok, heres what I knocked up....
autoseq.axo (5.2 KB) (v0.1)
autotest.axp (2.6 KB)
ok, i 'cheated' a bit... I created an axo object to do the work, basically because when things are a little more complicated, its easier for me to write it in C, and frankly its more efficient to do it like this
(I'm pretty sure you could do it with existing objects if you wished)
to use:
size is the max number of events to record.
it is also limited to running for 16.5 days, to extend this we would have to introduce quantising... or extend the counter.
on the positive side, event play/record should be accurate to 1/3000 sec.
you have a play or record mode, and a gate (like a transport in a daw i.e active = running) . then just send it values when recording. (I've put logging in so you can see what its doing , this would come out for 'real' use)
outputs v is the value (it echoes during record, which make it easy to connect) and end indicates when the last event is reached.
the idea is to loop you could use 'end' to trigger reset... but of course that might not be immediate but at the start of a bar etc.
evt is event number (not really useful) , and clk is clock... the later would be useful when using multiple automate objects, which could then share a common clock ... basically id add clock input, and internal/external clock flag.
(they will sync already, as its based on k-rate,but using a common/external clock would mean we could do fun things like shift time forwards and backwards)
if you look in the axo, and ignore the logic around starting/stopping etc, you will see it does as i said, uses 2 arrays one to store time the other the value. its really very simple
I didnt have much time, but as far as i could tell its working correctly.
when I get some more time, I'll finish it off,
in particular, id probably make it so switch between play/record, automatically reset ... i.e. so you can keep the clock running. add the int/ext clock and clk input. (and remove logging ) ... I might also add some kind of quantising function, as its quite fun as a note recorder.
let me know if it kind of does what you expected.
EDIT: oops forgot to update uuid/sha... new version added.
Wow really awesome Going to read it all and check it out after kids are put to bed tonight....
Thanks, mate
Finally had time to test it. It works very well. Huge thanks, @thetechnobear. Didnt expect custom object Cool. yeah, it probably cosumes less DSP than making it from many objects.
I connected a square LFO to the gate input AND connected end from automate object to the square LFO reset. Then you have a continuos recorder. If I dont connect the end to square LFO reset in, it only records and plays back when the square is up(or down, sorry dont remeber right now, but it is either up or down that records). And also set buffer of automate object to 128.
The record should be only dependent on 'mode'
And it will only play or record of the gate is up, and only till it reaches the end.
Note: for record mode- end is set, when it gets to the buffer end OR you take the gate low. For play - end is set when it reached end of recording (not buffer!) or you take gate low.
Reset, just starts from beginning... I don't think I tested for record, but I'd probably say it should start from beginning
Note: you need to reset after both record or play, their is no implicit reset, the idea being you could 'pause' play or record and then continue.
That's what I'd expect at least....
The only undefined state ( ok it's not undefined, more perhaps not intuitive) , is switching modes - I only really tested switching modes then doing stop, mode switch , reset then start.
I'd have to think what the correct behavior is for this, depending if running or not. I think probably it should do an implicit reset, and keep running mode as is.
As i mentioned the looping/running is intentionally under user control, as often this will want to be sync'd to a master clock etc.
Sounds especially with a clock this would really usefull.
I tried to load the patch, but i get
hmm
Obviously, I don't get this error ( otherwise I wouldn't have posted it :))
I assume this is with the example patch ,any other errors?
To me it looks like your probably not running the latest version of the firmware etc, as I think the poly index stuff was changed to fix tables which had a similar issue.
@jaffasplaffa as you have it working, are you running the dev version or 1.03 ?
( it's possible it only works on dev version, no worries there will hopefully be a new release soon )
actually I mean the version number shown in the GUI. (Help / About) , latest is 1.03
but I always run a dev build (and its moved on a reasonable amount since 1.03) , so it could be Ive got changes not released yet... which is why I was interested if Jaffa (who had it running) was running the release build or not.
as I said, I really suspect its relying on a fix thats was added a while ago for tables... as its doing a very similar thing.
unfortunately there are no 'pre-releases' for windows, so you may have to wait for the next release, which I hope wont be too long now.
Yes, I have the same errors, with the same firmware. I tried to update to the lastest build (using what I found on Git and JDK,), but I got stuck when it said I had a Firmware CRC mismatch, and couldn't update the firmware :
Firmware version: 1.0.0.1, crc=0xFB45859B, entrypoint=0x20011000
Firmware CRC mismatch! Please flash the firmware first! Hardware firmware CRC = FB45859B <> Software CRC = Please compile the firmware first finished loading objects
Link to firmware CRC Please compile the firmware first
can't read flasher, please compile firmware! (file: H:\axoloti-master\axoloti-master\firmware/flasher/flasher_build/flasher.bin )
I have no folders in the axoloti-master\firmware/flasher/ folder.
So I gave up, hoping someone else would come up with the problem
My working version (but not for this object) is 1.0.3-0-gc248736
