#68

Interesting — I am currently recording audio in 1 to track 2 — but i have noticed sometimes i cant record onto a track and haveswitched to another — not quite figured it out.

Also, with overdub set to 0, there should be no recorded audio (i think) but im getting audio playback for one loop after i record, then its fully gone. But i am pretty certain its not like this at other times.

#69

I have noticed that I can’t record to track 4? This was during a long session yesterday during which I didn’t want to lose the samples I’d cut on tracks 1-3 so I didn’t fool with it too much.

I thought that both inputs (L&R) were being recorded to each track (even if as mono signals) but I could be wrong about this.

#70

synth manager/selector - interesting idea.

i’ve been thinking a lot about code reuse to minimize duplication and also about standardizing commands (SuperCollider has a lot of those: gate, amp, degree, octave, freq to name a few).

with one of the current engines (ack used in step, playfair, and hello_ack scripts) i’ve tried to address code duplication by refactoring common code to a lua lib: https://github.com/monome/dust/blob/master/lib/lua/jah/ack.lua

4 Likes
#71

Right now i can record audio input 1 to all tracks.
I hear audio input 1 only through the left side head phone, then playback is through both. Which is odd sounding for lots of reasons. Not sure if that intended or whats up. :slight_smile:

All tracks are all doing a ‘one loop record’ thing where overdub off = audio recorded for one loop. That doesnt seem right compared to the last time i was using mlr.

#72

Relaunching mlr, now audio input 1 does not record to all tracks.
Now getting some very stange display of grid lights on track 1 though, like a jumping/stutter.
I think i’ll tryi something else and come to mlr later. Fresh start maybe for me and norns! :slight_smile:

#73

oh yes, this is certainly something i’d like to pursue. it’ll require some abstraction, so i’m up for proposals (or generally just seeing how people pursue this).

one thing i considered is having a generic “synth pset editor” for each type of synth, and then a “sequencer/etc” could choose a synth engine then load psets from that synth specifically (basically like a vst/etc).

i’ve just implemented numbered psets (coming in the update, tomorrow at the latest… i want to give the inner team a quick chance to test)

6 Likes
#74

re: mlr

i have seen some tricky bugs that are difficult to reproduce. it is possible certainly to get mlr into a broken state and i’ll be working on it. particularly with the off-reported position LED and the sudden input not-going-to-the-right-place bug.

i’ll try to implement save-buffers-to-disk soon so there’s less hesitation to restart mlr or reboot the machine.

i need to make a tutorial video, as it’s hard for the docs to capture the whole thing. but from the docs:

in REC/SPEED mode use ALT-FOCUS to toggle tempo-mapping.

tempo-mapping means the playback speed of the sample will follow the tempo.

2 Likes
#75

Thanks tehn, i kept trying to adjust the tempo from the parameters area instead. That must be it.
Being new to mlr i think i’m definitly behind in terms of whats been reported etc — i’ll try not to get to ahead of myself. :smiley:

#76

A post was merged into an existing topic: Norns: Development

#77

this isn’t quite right. with zero overdub, you are still recording (if the record flag is set for the voice in question), but fully replacing the previous content. so next time the head loops around, you will hear the thing you recorded last time, but only once.

(other mlr issues… i dunno right at the moment. maybe brian and i will work together on which things are lua-side issues and which might be inconsistencies in the engine behavior. so far in my use of mlr i haven’t really noticed anything outside my expectations, but haven’t used it super extensively or in every possible configuration.)

that’s odd - both inputs should be going to all tracks, and all tracks should be going to both outputs. i’ll assume this is an engine bug and try to reproduce.

yes, tracks are mono.

MLR improvements that are definitely on my plate:

  • improve resampling when recording at speeds besides 1. (it is quite wrong at the moment. i have a correct version that is not quite working on ARM for some reason, and will get it fixed asap.)
  • deal with stereo samples more intelligently i guess.
  • increase the track count if possible (this is dependent on sorting out some systemic issues with audio glitches at relatively modest CPU loads)
4 Likes
#78

Not sure, but the left channel in the first sample (which is read by glut) is recorded with a significant DC offset already, see pic. I’d guess that the offset could build up even more after being processed by GrainBuf, if the grains fall onto the peaks of the original sound. This can be fixed by adding a LeakDC ugen somewhere in the voice synthdef, or processing the buffer after loading. For now I suggest pre-processing the samples to make sure the level and the DC offset are okay.

image

3 Likes
#79

Ahh yes, thank you for clarifying. :slight_smile: — is there a know issues list anywhere at the moment?

#80

Thanks again! Appreciate your time. glut is great fun btw, thanks for all your work on it.

3 Likes
#81

Regarding mlr, is there a way for quantization to also affect pattern recording? Ideally, if quantization is on (Q pad in top row lit), I would expect the second press of the pattern record pad to be quantized to the division/tempo setting. If quantiztion is off, I would expect the current behavior (pattern recording starts with next row press after activating pattern record, ends and loops whenever pressed again). Perhaps this is the case and my timing is off?

1 Like
#82

there’s a chance that some pattern operations are missing the quantize filter— i’ll check it out

3 Likes
#83

Sorry, as this has been asked before, but could someone please explain MLR tempo settings a little more detailed? I can’t get it to work right (or maybe it’s a bug).

The overall tempo setting in ‘parameters’ seems to only have an effect when quantization is activated on the individual tracks in the rec/speed mode. Is that correct? Otherwise the tempo seems to be stuck at 120bpm.

But when I have the track quantization acivated, the monitoring of the inputs and the actual recordings glitch out quite drastically. It sounds like the are downsampled live. But I would expect that if I record live into a track with e.g. 90bpm that it would sound exactly as if track was not quantized at all.

2 Likes
#84

I was wondering about that live downsampling myself. I find the lower rates a little too noisy for what I’m trying to use them for (Usually piano or guitar or something).

1 Like
#85

at the last minute we reduced the playback quality to address some CPU issues: https://github.com/monome/norns/issues/407

but we’ve made some headway and should have an update soon to bump it back up. i apologize for the ugly aliasing in the meantime :grimacing:

5 Likes
#86

That‘s great news! Thanks a lot.

1 Like
#87

Could you explain how to reference the norns inputs and outputs correctly within a CroneEngine? I’m trying to implement some sampling and playback but I don’t understand how to make sure the CroneEngine gets the audio input from the AudioContext and outputs it correctly.