#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.

#88

its not the most elegant nomenclature, but the stuff you’re looking for is in CroneAudioContext:

one of these is assigned to the context variable of the CroneEngine superclass.

so you use context.out_b for output and context.in_b for input.

note this oddity: context.in_b is an array of two mono busses. context.out_b is a single stereo bus. (this just seemed to match closer to most of the use cases. in_b indices are adjacent so you can treat them as a stereo bus if desired.)

also: context.ig is a Group conteaining input synths, context.og is a Group with output synths, and context.xg is a Group between them for your use.

(ha, i even left a FIXME in there to make the names less stupid. it is probably not quite too late to change them? no, it’s probably too late.)

1 Like
#89

@boboter

so… just a heads up that recording at any speed other than 1.0 is going to cause aliasing. this would be true even if write-head interpolation was correctly implemented. (it’s not right now.) this is a deeper issue than reverting the changes i made to reduce CPU usage prior to release - those affect playback interpolation quality, and reduce speed changes to control rate. these are easier to revert but we also need to make other infrastructure changes to make the CPU headroom available - like running aux fx on a separate core (what i’m currently looking at.)

i’ll comment on the GH issue to clarify the current situation.

3 Likes
#90

@zebra

Thanks for the info.

I’m still ot sure if I fully understand the whole thing, as I generally don’t want to record outside of 1.0 but at another tempo than 120bpm. I would just set the tempo to e.g. 90bpm and also record in 90bpm. But as far as I understand it, the loops need to be quantized to do that.