More tape

I just got my Norns shield two days ago and I have a lot of ideas. They might be shaped by the fact that I’ve barely scratched the surface and haven’t scripted anything beyond GUI tests in Lua.

Tape is actually a feature I didn’t even know about when I got my Norns, but it actually fits perfectly into my normal workflow, which is very much based around adding layers one by one and always moving forwards. I might be the only person in the world who would want all of this, since in a way it’s dragging Norns into a kind of DAW territory which of course has all kinds of connotations. But it would also allow you to a lot more things on Norns itself. I understand a lot of work goes into softcut, but unlimited length is quite important to what I personally want to do.

I have looked through the sources and I think I’m able to (and will attempt to) add most of these. I’m not so confused by the C++ side, more the boilerplate needed to expose everything to Lua.

I wanted to invite feedback from developers and more experienced users first to maybe arrive at solutions that might actually get mainlined/accepted by others. I understand most of these have been suggested in various forms before, but I hope it’s OK to start a new thread to discuss more maximalist visions for tape.

Multiple playback tapes.

I don’t know how much processing power/bandwidth this would use, but I think having more than one playback tape would be useful.

Say you just had two or three in all, you could keep the current interaction of moving between playback tapes and rec with a button, you’d just need two clicks to go to rec. Not too bad I think. There seems to be more than enough screen space for an indicator.

Send tape playback to script input and post-record

I see this has been covered but I think it would add a lot to be able to use tapes as inputs to any script.

Another thing I would like would be to be able to not record the playback of a tape. The use case is obviously using backing tracks and metronomes.

As far as UI goes, what about setting the destination from the tape page using one of the unused encoders? You’d set an output destination for each track, something like main mix, script input, or monitor.

Different playback modes

Right now we only have looped playback. One-shot would be good as well and it seems like it just needs to be exposed in the UI.

Also, in the presence of multiple playback tapes, it’d make sense to let playback be retriggered by a different tape. So I load two tapes, one maybe longer than the other, and I set one of them to loop and the other to be retriggered by it, and they play back in sync.

Again, this could be set using an encoder.

Of course, it’d also be nice to set the start and endpoints, and, in the presence of multiple tapes, delay playback with respect to each other, and maybe set the endpoint (loop point) after then end of the file. But of course I’m way out of encoders now, haha. I suppose you could use a menu system. I have some ideas that are hard to articulate, but big menu systems don’t seem to be where Norns’s excellent interface excels the most.

Synchronized recording and playback

Synchronize recording and playback. Ie., one button press to start both playback of multiple tracks as well as recording.

You could turn this on or off with an encoder when the record deck is selected.


if start and end point can be changed one thing i’d request is ability to mark different loops and leap between sections (like w/ or what’s possible with op1 tape mode)

would be kinda interesting


love your ideas @rvense - I also use tape to layer songs together :slight_smile:

however, I might caution against specifically upgrading the Tape code and instead look towards making your tape machine into a “norns script”. norns itself is a platform that encourages essentially sandboxing your ideas into “scripts” which makes it easier to share them with others. if you decide to edit the mainline Tape code, it might be hard to get it merged since its no longer sandboxed and might affect many other things. however, there is nothing ever stopping you from editing the norns code and drastically modifying anything you want :slight_smile: that’s the beauty of open-source!


that being said…I am pretty sure that your ideas presented can be pretty easily implemented in SuperCollider. this would make it an excellent candidate for a norns script. let me see if I can draw parallels to your plan:

SuperCollider’s DiskOut and DiskIn methods let you continously record/play from the disk. so, (I’m pretty sure) this means that you will only be limited by the amount of disk space and not memory.

yeah this should be no problem in SuperCollider. I haven’t used DiskOut/DiskIn specifically but I have some scripts that have multiple read/write buffers going simultaneously along with a bunch of other stuff. generally it seems (to me) that sample-based things are not very cpu-intensive. @tyleretters recently made a script that plays up to 128 samples simultaneously.

this is also easily done in SuperCollider! you can use buses which effectively can shuttle inputs and outputs between different audio players/recorders that you have running. you’ll have lots and lots of control over the mixing this way.

this I know for sure you can do in SuperCollider - I’ve used SuperCollider to make one-shot things as well as a looped things. having one loop retrigger another loop is a bit more complicated, but I have an idea of how that could be done too!

this is also easy to do in SuperCollider! you can essentially create a bus that has the position information for all your loops, and then pipe that into the audio players/recorded (buses can share control data!)


basically, I just want to say that your idea has a pretty clear path if you want to go the SuperCollider route. don’t want to dissuade you if you already have a plan in mind. but if you are interested, I’d be more than happy to help figure out the SuperCollider equivalency for these things. I have a lot of examples that should get you off the ground running. :running_man:


that all sounds fine to me. if you really are comfortable with the low-level implementation of all these things, then i think there is no obstacle to adding them (the API glue is trivial, and in general there is little objection to extending the APIs as long as defaults do not introduce new unexpected behavior or seriously impact the baseline CPU use. in this case i would want “default off” for tape->engine routing and so on. and all this multitrack stuff needs to be done quite carefully w/r/t disk access and thread safety/efficiency.)

some of the things were on my radar in an attempted rewrite of TAPE module which, like many things in past 2 years, i did not actually have the bandwidth to finish. (extant condition of the module reflects basically a single weekend of focused work.)

its true that at some point with many multi-trak/sync features, its (1) hard to imagine them being incorportad into the base system without affecting efficiency, (2) if nothing else, they are not trivial to inplement correctly, (3) they can be rather easily implemented in SC at the engine level, and maybe this is more approprite if the envisioned use cases are a little more specific (“norns as DAW”).


Uh I should say. Although SC gives you building blocks of DiskIn and so forth, in general I would foresee difficulties with building a DAW environment around this on norns, where all control requests originate from matron.

Consider’ we do not timestamp OSC from matron, in general prioritizing low latency over synchrony. it is possible for “simultaneous” OSC commands to take effect on different audio blocks. Ultimately it may be difficult to achieve arbitrary multitrack playback/record from separate files on disk.

Such issues are most easily addressed at a lower level. But it course this does not mean that the solutions are simple, you must go a little ways down the rabbit hole of DAW engineering…


Dumb question: If I do do this with SuperCollider, doesn’t that preclude running tapes through scripts that use different SuperCollider engines?

As far as I can tell, if playback sync is set as an option that Crone knows about, then we should be able to do sample accurate starts, right? If I’m not relying on multiple start messages to come in for each tape when they’re synchronized.


yes of course it can be achieved with some engineering. if a single OSC command kicks things off then there is no chance of its effects being split between consecutive audio blocks.

but if you just made multiple instances of Tape and started them playing at the same block, they would not guaranteed to be in sync, and in fact that would be unexpected.

streaming buffers must be primed, which happens from the call to open() (non-audio thread):

when reading on the audio thread, zeros will be emitted until the buffer is primed:

and we don’t attempt any control over the timing of this - there is a small but indetermine period of silence between handling the tape/play/start command and the actual start of playback sound.

(actually, after refreshing my memory, the situation is weirder than i’ve let on: there is no explicit handling of playback start from the audio thread. (1) the OSC handler thread receives the command and immediately kicks off a disk worker. (2) the worker atomically sets the running state of the tape reader before starting work. (3) the audio thread comes along and reads that state to decide to start actually copying samples from streaming buffer to audio bus. (4) until the buffer is primed those samples are zeros. (5) once enough disk samples have been acquired, playback can actually begin. the timing of (3) and (5) are both indeterminate. of course one could move things around so that audio thread is signaled after priming, but that doesn’t change the basic situation.)

hopefully it is clear that if you wanted to syncronously stream multiple files from disk, while “overdubbing” a new file to disk, making sure that the new file is in sync with the others and the wall clock… then some additional marshalling of the disk R/W threads would be necessary, by some software layer that is fully informed about which audio files need to be synchronized and so on. it would not need to be very complex, and in fact could be done in SC as well, but it’s not a trivial requirement. (maybe a marshalling class would dovetail with your other feature desires, like adding specific arbitrary delays between “tracks” and so on.)

of course all of your other proposed features also require engineering, i assume we don’t need to walk through all the details…

at some point you may decide it’s more sensible to just script an instance of something like ecasound instead of reinventing all the wheels.


Norns shield user here.
I’ve had dreams about the future of norns tape. I use it in its current state to layer mix full songs like an OP1. Although norns tape is minimalist, I have been able to accomplish more than I expected with it. Sending tape to a script and recording the post result to tape is pretty well fleshed out.

I really like the idea of having more than one tape playback and being able to choose whether or not the playing tapes will be recorded. I also like the idea of being able to sync tape playback and recording to the current bpm.
This would be a really powerful tool to have while a script is running. You could use one tape as a metronome, and choose not to record it. You could create sections of a song and play the sections while still performing on grid or in a script and record all of it. As a shields user I’m particularly hungery for a metronome from the main output, but doesn’t end up on tape.

Afterthought: I find that timber pairs with tape particularly well for stringing/gluing together song sections and mixing layers of tape. Solves the problem of needing pieces of tape synced when you’re triggering them yourself. When I want the above functionality I look to timber.


not a dumb question! yes, well this is a snag for portability. making a tape-machine type thing in SuperCollider that is available to all scripts would mean that to import it into other scripts you would need to “merge” the engines together of those scripts. I do this pretty frequently and its not too bad to do as long as your variables have unique names (literally just need to copy and paste sections of code together) and the routing is not too complicated. but it does make it harder to share, as then you would need a special “tape” engine which gives the tape functionality to the previous engine.

if that’s the goal, then now I think modifying the Tape route is a good way to go if you want such a thing available to every single norns script. but if you are interested in just a single norns script with a tape-like functionality then I think SC is a good way still. but actually norns can run ecasound, and the jack points are well established and easily connected, so maybe that is worth a shot as a path of least resistance / proof of concept (I have no experience with ecasound but it seems cool).

1 Like

@zebra Thank you very much for your thorough answers.

Ecasound might be worth a try. I’m aware of it, but I’ve not used it in earnest. And there’s still the issue of putting a nice face on it.

1 Like