Ah, that would explain why I never experienced this issue with the recorder - (forward) looping is my default option.
D’oh!! Thanks for clearing that up, dBlue. I also hope this will help esaruoho?
dblue, esaruoho, danoise: thanks
I’ve incorporated some of the findings from this round of testing and it has made it much more responsive (less calculations). However, there is still a limit of 512 rows (64 beats) as that is the maximum beat sync value!
So, that limit will remain for now, but it was not in vain, as Cells! is much better for the experimentation.
it actually makes it much harder! because:
renoise.song().instruments.samples.autoseek, _observable
but no
renoise.song().instruments.samples.autofade, _observable
and since we’re in 2.7.2-town, autofade as a scriptable function will only come after an update/api update. I wonder if they already remembered to put in autofade. Anyone wanna hazard a guess?
Thanks for the autofade suggestion anyway, I’ll definitely enable it for “Record_To_Current_Track” the 2.7.x/2.x version 
So both autofade and loop=forward? I could try that, sure.
Would be niftier tho to have a 32 row pattern with a 512 row length sample (sync-mode at 512) and be able to “unwrap” it into the required amounts of patterns that the whole 512 row length sample will play itself till the end
Autofade will come with the next version (that is also what the [fixed] tag supposes to mean), don’t worry.
>>> oprint(renoise.song().instruments[1].samples[1])
class: Sample
properties:
autofade
autofade_observable
autoseek
autoseek_observable
Boohoo 
Man I wish the updated API would be “seeded to 3rd party developers” before official release 
The Beta period is soon enough before “official” release.
Okay. But that could happen whenever! (2013 May)
It’s 4:20 somewhere!
i do not get the context. are you telling me to smoke weed and wait till a new version comes out? cos you could just say it.
Aaaaanyway,
To get back on topic, I’ve been working on Cells! a bit more this afternoon:
Changes include:
- It now runs a lot faster due to using some alternative algorithms for some of the operations
- Automatically selects current track when you modify a control on one of the playback tracks
- Current track identification / selection button (‘Curr’ turns green)
- Filter control modified to a single rotary encoder (combined cutoff & resonance) - makes room for more effects
- Window shade button (hides all but the top status line (so the user can see more screen for loading precreated instruments of loops) into the instrument list
- Crossfader cut buttons (non latching buttons which mute either A or B while held (for ‘DJ style’ cuts and drops)
- Loop position indicators per track (a minislider which moves from left to right to indicate current position within the currently played sample i.e. easy visual feedback to see you are halfway through that 64 beat breakdown) (just below ‘Stop’ cell)
- Number of cells per track is now a parameter that can be changed
- Number of playback tracks is now a parameter than can be changed (although < 8 gives ‘gaps’ in the GUI with the current layout)
- Various bug fixes
- Various GUI tweaks to make it more consistent and easier to use
Are these cutoff/resonance things done in such a way that when you initialize the GUI that the script creates filter native fx for each channel?
are there plans to make this sample?
Will it be possible to map that tool with multiple controllers ? With classic mapping and/or Duplex ?
Thank you !
I like the A<>B, really performance friendly stuff. This feature will only work when you have ASIO (or similar drivers) installed?
Will you also add midi-assignable knobs to control the loop Sync? cos mapping a midiknob to loop sync amount is real fun. (i could only really make it happen for 0-127 sync lengths, but you already know how to get the 0-512 beatsync mode range to be midicontrollable…)
Now we just need warp in renoise
Why not skam?
Wow, haven’t seen this until now, it looks amazing!
can’t wait to try this. Any time aspect on an alpha/beta test run? 
There are three functions:
- remove_stale_tracks() - Removes any existing Cells! tracks
- prepare() - Creates the Cells! tracks, devices, routings etc.
- start() - Starts Cells!
Currently they are just called in order on each startup, however, I understand that users may want to modify them, so they will be split out into separate menu options eventually.
This tool is not built upon Duplex. However, I’m planning extensive midi maps, so multiple styles of controllers may be used. However, this does mean that there is no controller feedback at this time. Maybe dedicated versions (like the Launchpad edition of Lauflicht Step Sequencer) would be a way forward? Anyone want to supply some controllers? 
Interesting idea about loop lengths. I’ll look into incorporating it.
I want to make it as stable and responsive as possible first. Then there will be a public beta.
Only a small update today:
Todays new feature: One-shot cells that fire once only.