#165

Its just the way it behaves. Ive been seeing this as a nice thing as it kind of gives it its own character. I think the reason why you may be hearing it on the extreme end of the spectrum is that the length of the loop is possibly a big division away from what mlr has the tempo set to. If you load a 4 bar loop thats recorded 75bpm and set mlr to 75bpm and set the length of the track thats playing the loop to 4 bars you won’t be hearing the change in audio that you’re experiencing.

#166

I’m not sure it’s something wanted, because the effect is really really not nice… i’ll do a video to be sure we speake about the same thing :wink:
actually at 127BPM , “normal speed” (i mean speed toggle at the center) the bitcrusher effect is horrible, and in the all spectre of the sound.

1 Like
#167

Hey, let’s talk clocks!

I threw together a “beatclock” object that wraps up switching between an internal bpm clock and an externally triggered clock, and put it into playfair so it can sync to external MIDI input. About ready to PR it. Here’s the general idea: https://github.com/monome/dust/compare/master...Dewb:beatclock?expand=1

I see that @audionerd added MIDI clock output to playfair and awake – awesome!

Anyone else doing any clock work that we ought to coordinate? I was thinking I’d roll both input and output into a separate “midi clock management” class that handled clock input/output source selection in parameters, and hooked events to the beatclock class.

5 Likes
#168

@Dewb very cool!
i added a basic midi clock to mlr as well. it’s in a github pr.
awake and playfair were easy because they are very similar. they trigger from a single metro, which i could speed up to 24 ppqn to send a consistent clock signal.
some of the other scripts (i’m thinking of flin) have more complicated timing routines and will take a little more work to be clock-able.

1 Like
#169

Really amazing what you’ve done with norns in such a short time. Would love to have a mess around with these

#170

yes! @artfwo has also been talking about a generalized clock system. perhaps best we design on the git issue

https://github.com/monome/norns/issues/129

@mDang i’ll write up a concise tempo map tutorial later when i have a norns nearby (on the move right now with phone)

5 Likes
Norns: development
#171

Thanks. My ultimate goal is to bring a next generation keytar to the masses, by hammering a norns and grid to a plank of wood. . :stuck_out_tongue_winking_eye:

Untitled%202
Untitled 2.png1236×466 328 KB

19 Likes
#172

i thought about this too. could be cool for busking. i was thinking i could use norns, mlr and samplr to play pretty ambient music in public. just load up mlr and samplr with a bunch of chimes and bird sounds. you could attach an extra battery and portable speaker too. anyway, thinking out loud here.

3 Likes
#173

3 posts were merged into an existing topic: Norns: Development

[mod: i moved the tangent discussion of C/matron internals, UDP timing, &c. continuing from:]

#174

Yeah, on the one hand accurate clocking seems like a job for the C/SC layers, not Lua. On the other hand, the obvious things to sync to right now are MIDI, OSC, and Ableton Link, and the first two of those are currently managed from the Lua side.

My immediate motivation is that next week for a performance I want to use the Norns in conjunction with DIN midi out from my partner’s rig, and send midi clock to a uMidi in my euro lunchbox. So far the Lua side seems more than up to this task, I sync’d playfair to an Analog Rytm and it was rock solid from 30-400bpm.

Whatever we build in Lua now can help guide requirements for a more carefully considered native code implementation. I’m not super familiar with Supercollider but its clock abstractions look great and I think that’s a good model to follow for now with a path to various futures.

I somehow missed the Github issue about clocking when I looked earlier, I will put more thoughts over there later!

1 Like
Norns: development
#176

it’s surely the aliasing from low-quality playback resampling.

we’ll get it fixed. freeing up CPU headroom by using multiple cores is a blocking issue, so that’s happening first (now).

5 Likes
#177

I love the aliasing effect from mlr on recorded material. especially pitching it right down it has a kind of cocoquantus vibe. maybe we can have audio quality setting in parameters?

4 Likes
#178

this actually crossed my mind too. the keytar style enclosure with a grid interface would look super interesting on stage. :slight_smile:

1 Like
#179

I was thinking of using a small pedal board for something like this with a few other effects… less brute force than a plank of wood though :slight_smile:

1 Like
#180

Yes, the aliasing sounds amazing on really pitched down material. I’d be sorry to see it totally disappear too. I’m hiding a copy of the code locally so I dont lose it.

3 Likes
#181

that’s a good idea… looks like a lot of folks are building custom versions of apps already.

#182

update coming this friday.

if you have a script you’d like to include send it in!

17 Likes
#183

I have never made a pull request, so I want to make sure that I have this right. My understanding is that I clone the norns/dust repo, then I would add my user folder and script. Then a pull request against norns/dust?

not sure if this belongs hear or in the github basics thread.

1 Like
#184

that’s how it would work yes :slight_smile:

#185

I think you may also have to fork norns/dust before you clone it? My very basic understanding is that forking is making your own copy (on GitHub) to work from and cloning is downloading something to your machine from someplace else.

3 Likes