as announce on this topic,
Ive now released LOOP (early access) , a 4 track looper module for the SSP.
I know this is a keen topic for some, so Id like to share some information about its development, and also where it may go from here.
so the basics of where I am at today are covered in the ssp wiki document
EDIT:
today, Ive release GRA4 for early access, a 4 layer granular module…
again, SSP wiki has the details
anyway hope you enjoy, Ive certainly been having some wacky fun with it.
its a fully working 4 track looper - that I think is fun to use.
however, the functionality of loopers varies tremendously, from simple recorders to hugely complex almost daw like applications.
really except for multiple layers and the ability to play and record, there are no rules to ‘what is a looper’, or what has to exist.
LOOP as is today, is relatively straightforward, and this is quite intentional…
as Ive stated previously, when we develop modules, they should not be ‘all singing all dancing’ rather they need a part of an ecosystem that sits with other modules.
(at least this is my philosophy, you are welcome to disagree… but it does’t make it invalid 
)
also, I’ve developed LOOP using a new approach…
It started off as a kind of proof of concept for my RNBO Template, and to test it could be used for ‘proper modules’.
So, really, RNBO inspired this module, when I saw the groove~ object within RNBO.
Using my template, I was able to get something up n’ running, testing the waters very quickly.
From there, over about a week , I was able to integrate and evolve… slowly removing almost all the template code, so that rather than having a generic UI, we have something that looks/feels like any other module I might create.
the functionality LOOP has now, is very much bound to that is possible with groove~ and record~, as these look after the DSP, so these definitely influence the functionality.
however, I’ve been very careful, to ensure that I could replace the DSP code with my own code, with relative ease… as frankly, the UI is a large amount of the code of this module!
so this brings us to where we are today.
as I said at the start, loopers can be simple or complex.
so today, LOOP is feature complete, in that works well as a simple looper within a modular environment.
however, its been developed interactively, and frankly, Im still iterating (even in the last 2 days its changed substantially!)
so yeah, Im sure some will have a ton of ideas for how things should be improved, or ‘must have features’, but honestly its far too early for that…
I already know of huge number of things Id like to , or could do… with my own ideas alone.
I could already spend many more months on LOOP… and the more I implement, the more ideas I have!
so at the moment, its kind of a reflective phase… deciding where I want it to be.
at this time, as I’ve not decided what the ‘release feature set’ will be, and things may change substantially.
it therefore felt naturally to release as EAP, not only a nice way to thank supporters, but also to let a limited group provide early feedback.
probably the most obvious question 
really its about some differences today, and possibly future direction!
for sure, there are some similarities, they both are granular … with the basic controls you expect.
both allow live recording and loading/saving of files,
but fundamentally they are quite different!
GRA is a much more complicated module that GRA4, offering many unique features.
it also has more comprehensive UI, possible because its is implemented ‘natively’.
whilst GRA4 is (imho) ‘lighter’… its based around 4 mono layers, and has quite simple controls.
it also needs to have an external trigger, and really expects to be modulated ‘externally’ via cv.
and, that is really the main point - GRA4 is designed around my ethos, of being part of the ecosystem, not having every function in it, or being ‘self contained’.
this gives it a different flavour.
so, if anything, Id see GRA4 and GRA diverge more over time!
(though, Im not going to deliberately make it different, just to be different… it is its own thing!)
ok, this is a very important aspect of GRA4…
(its also creates some limitation e.g. no playback position display!)
it means that underlying DSP code is VERY flexible… I can easily change the code to do different things, or have new features.
hmm, we’ll see… its based around granulator~ which does have a few more tricks up its sleeve.
particularly, setting number of grains and changing the windowing… so we will see !
much of the UI is shared with LOOP, and in many ways this is helping me to develop some new UI concepts.
LOOP introduced a new waveform display for me… and GRA4 was the motivation behind the new file handling (browser/rename displays)
This will continue…
currently the waveform display is pretty simple, but I do hope/plan, to add things like zoom etc
but more on that later, as that may be part of another new module I’ll develop later
These are great, thank you for creating these gems! I really love having different sample playing modules/instruments, each one has their own character and vibe. I find a lot of inspiration in here. I would mention that there seem to be some clicks and pops and stuff like that with these two modules.
Anyway, love this direction, I’ll use any and every sampler/looper.
&e
can you be specific about circumstances you get pops/clicks… (need details!)
I hadn’t noticed any when I was playing with these modules, but it may be I know what will likely cause audio discrepancies and what won’t… so possible I avoid problematic areas, or setup the patch to succeed
as mention in docs, any file io will likely cause audible issue on the spp.
from anywhere in the patch… not just a particular module.
(actually, likely is perhaps over stating, I do take precautions, but its still possible due to the OS)
changing size similarly will be problematic, which is why it cannot be modulated.
also generally looping can cause audio discontinuities in waveforms… which crossfade can only deal with if used correctly. i.e. at boundaries.
other areas, Id see possibilities would be modulating start/end etc, thought I’d need to evidence of this, with some precise details, as Id assume groove~ should handle this.
gra, Id need to check if its using a default window, as this could cause issues… though this very much depends on how its used, and what material you are using.
so yeah… with any kind of sampling (and generally audio clicks/pops) issues we need very precise details on when they occur… as its highly dependent on usage, and material.
Your LOOP module has given me inspiration for a sampler module I want to make. (Although I can’t make it with my skill because there is no way template to load/save the contents now.)
GROOVE~ can be set Begin and End, so if the sounds are equally spaced in a WAV file, I can control the playback position with a slice number like Octatrack’s FLEX machine. It seems fun to be able to control and select the sound that is triggered or randomly select it.
yeah, I thought about making a slice module, even got ideas for the UI
if I do it, it’ll likely be fixed length slices…, so basically time / N slices. ( * )
though of course, means its of pretty limited use with live recording,
since you really need to ‘prep’ slices to get accurate timing.
(though I guess if you sequence, you might be able to hit slice points… even then…)
( * ) rather than allowing user to move slice points, which while not hard, creates a lot of UI work to be useful. (since slice points need to be pretty accurate, so need zoom etc)
and yeah, I have an OT so know how it works…