Retrospective Record

Post Reply
caseyjamesbasichis
Posts: 54
Joined: Sun Apr 18, 2010 9:05 pm

Retrospective Record

Post by caseyjamesbasichis »

I'm greatly looking forward to the next update of thumbjam so I'm a little trepidatious about adding to the heap... but these ugg boots are so damn comfortable that I just cant resist.

It would be very cool to have a constant retrospective record going into ram so that, say, one of the last three loops can be selected to be saved without having to specifically record anything.

My use of thumb jam consists of playing around discovering something and then trying to recreate it and remember what it was. A retrospective record would take out the anxiety of recording and recreating a part and I think make the whole experience a lot more enjoyable and exploratory. Trekking around the peaks and troughs of casual tapping in my big fluffy ugg boots.

I'm thinking by constantly recording into ram only that there wouldn't be a significant battery hit but I'm not so up and up on how all that works.

mat
Posts: 158
Joined: Sun Feb 21, 2010 11:46 am

I strongly +1 this one. How

Post by mat »

I strongly +1 this one. How many time couldn't I do again, or worse, didn't I remember what I just did when exploring and not recording! Additionally when I press record I feel this pressure and come up with inferior things a lot of the times. Secret hidden recording you could summon up, even if just as a reference, would be great!

Wish I had Ugg boots too...

User avatar
Jesse
Posts: 1053
Joined: Tue Dec 15, 2009 3:25 am

It is a very cool idea, but

Post by Jesse »

It is a very cool idea, but there would need to be compromises. I could choose to keep the most recent primary loop length's worth of audio around, but in some cases that would be too long to keep in RAM so I would to have some factor of that length instead. Then, lets say you only want to keep a subset of that length when you hit the retro-record, how would that be presented? If you guys want to keep discussing it here, we might be able to come up with a satisfying interface for it.

Sorry about the Uggs!

caseyjamesbasichis
Posts: 54
Joined: Sun Apr 18, 2010 9:05 pm

Hmm I'm not sure how much RAM

Post by caseyjamesbasichis »

Hmm I'm not sure how much RAM we're talking about. I guess the iPad has 256 total at the moment and the phone 512.

I use some large custom instruments. These days I record much shorter loops though; 5-20 seconds. I wouldn't think that much audio would be so consumptive.

Here is a thorough idea of how I think it could be done. If implementing some of this is difficult it could be stripped down.

I envision it as a button like 'cancel' or 'record' in one of the lower corners, as the need to pause the recording to save as much history as possible is so urgent.

A window would pop up.

For short loops where there are multiple loops in the history they would display in a list with a check mark, play buttons and solo buttons next to them to allow them to play in context with the rest of the loopset or solo. One or more loops could be checked and chosen for retention and if the beginning or end loop is incomplete, it would pad out the missing portion with empty space so that the loop follows smoothly with the rest of the set.

For long loops where only a portion can fit into ram it would be nice to have the option to either pad out the missing parts with empty space or choose a power of two crop area based on the total length of the loopset or the tempo/time-signature if one exists (in case its 3 bars where half doesn't make as much sense as thirds.)

If you were able to wrangle in the midi file business with the retention, that would be top notch as well. To me thats more essential than the subdivisions as I would be satisfied with padded out material across the board.

EDIT: one other bit would be to have a checkbox option, with the list of multiple loops, to either treat all the selected loops as one long loop or as separate takes of a single loop length.

mat
Posts: 158
Joined: Sun Feb 21, 2010 11:46 am

Caseyjamesbasichis, I know I

Post by mat »

Caseyjamesbasichis, I know I don't like when other people propose solutions not in line with my original post, so, sorry if I have the same effect here... I truly like your idea and think this would be a real plus for all of us.

My view on it is that there is no real need for this auto-record/save for ideas on the go to be linked with loops. That would impose too many troubles in terms of available length, start and stop, etc... And would end up either not saving that brilliant performance or idea or automatically chop it the wrong way most of the time. Also, why should it use ram? That's a strong limitation.

What I would see is a save to disc function just as session record is, but only for the current instrument. It would stop whenever record is hit. And be replaced as soon as the dedicated disk space is full (the start of the save file being gradually replaced and so forth...). When you want to have access to it you would go to a specific menu (accessing menus would pause the auto record anyway) and choose what you want to do with it: listen, save (to session for example), even transform to loop from a chosen point, there with the loop length options Jesse or Casey proposed...

As usual, hope I was clear...

caseyjamesbasichis
Posts: 54
Joined: Sun Apr 18, 2010 9:05 pm

Hmm. Well maybe were

Post by caseyjamesbasichis »

Hmm. Well maybe were thinking of different things. Though just because you wouldn't use it that way hardly means there is no use. Personally I never use session record in anyway, that doesn't mean it has no use.

For my uses, building song/arrangement prototypes, having the retroactive loops linked to the loopset in time, as described, is absolutely essential. Those loops are just one step in the process, what you are suggesting would prohibit further construction of the song in the moment, it would need to be transfered to a computer and edited or otherwise totally disrupt the workflow. Sometimes I will mute all but one take and store the rest as variation or make six new loopsets from each of the muted variations to be embelished.

I think I addressed most of the issues of cropping. But you are loopking for a retrospective session record for instruments, where there isn't even a session record for individual instrumentscurrently. Parhaps both are possible and either could be selected as a preference.

The reason for writing to RAM is that if thumb jam was constantly writing and overwriting to the flash memory at all times I think it would wear heavy on the limited read write cycles that is inherent to flash memory and not RAM. Also I think it has a greater drain on battery.


caseyjamesbasichis
Posts: 54
Joined: Sun Apr 18, 2010 9:05 pm

Just to be clear this isn't a

Post by caseyjamesbasichis »

Just to be clear this isn't a function I would use just once in a while, this would replace hitting the record button most of the time. To me the greatest advantage of TJ is the speed and streamlined workflow. If every time I wanted a recoding I had to go and manually trim the part I wanted and work to reinsert it into the loopset it would completely wreck the workflow. It is especially unnecessary if I am working with a fixed time signature tempo and loop size as the area that I am interested in is already implicit.

mat
Posts: 158
Joined: Sun Feb 21, 2010 11:46 am

Fair enough, I may not be

Post by mat »

Fair enough, I may not be fully in line with what you have in mind. I'll start my own thread not to interfere with your own original request! Thanks for temporarily hosting me!

Cheers

User avatar
Jesse
Posts: 1053
Joined: Tue Dec 15, 2009 3:25 am

Sorry for the huge delay in

Post by Jesse »

Sorry for the huge delay in feedback about this feature.

I think Casey's take on it is the most likely approach. I have a concept in mind for the interface you get when you hit the RetroRecord button which lets you pick the part(s) out of the retro-active record buffer you want to save.

It brings up a display kind of like:

*[------|------|------]------*------|

Letting you pick/drag the start and stop time in bars you want to record in history, with special marks at master loop boundaries (*), for instance. Buttons below would let you save off and name as many as you want before you close the window. Also lets you audition the range selected immediately.

I think keeping this limited to in-RAM recording only is important, because constant recording to a flash disk is a bad idea for the reasons Casey mentioned. There would be an option to enable this behavior and choose how much memory to reserve for it.

dswo
Posts: 22
Joined: Sat Feb 12, 2011 10:05 am

One way to limit RAM usage

Post by dswo »

One way to limit RAM usage for the "autosave recorder" would be to have it record MIDI events instead of waveforms. It would be like saving a score instead of a performance. Another benefit: saved MIDI scripts could be imported into NanoStudio and revoiced with other instruments.

Post Reply