Are you using an Elektron device for this midi track? I haven’t messed with the NDLR’s chord sequencer or midi implementation very much. Your comment makes me want to dig back into it a little more.
1 Like
MIDI CC’s 26 and 27 (Chord degree and Chord type) are your friends. I use a DT MIDI Track to sequence the Chords progression. P-Locking Conditional Trigs to do Variations is very useful.
2 Likes
the NDLR doesnt really do much until you start automating those chord progression buttons.
this is where its magic happens. until then its a bit humdrum.
4 Likes
For me the magic is in the LFOs/Modulations.
2 Likes
yeah, i hadn’t looked into ndlr’s midi implementation either. i would just do my best to come up with interesting manual presses mixed with automating the chord progressions via the LFOs available each of which wasn’t the best way to have a “skeleton” to begin with. it was definitely a haphazard workflow.
this really opens ndlr’s utility for me as i’m able to create a fundamental chord progression to then automate on top of via the modulators (or whatever other means). i just wish there was a way to “arm” the ndlr for receiving notes as i’m using the same channel across a few sequencers all of which have an arm functionality, so i’m not sure how i’ll get around that…maybe some sorta USB toggle to turn the ndlr off when i wanna record notes on another sequencer ? 
as for what elektron device i’m using, either the monomachine or octatrack. the onboard chord sequencer is kinda moot with this functionality as far as i can tell.
@Tchu
that too, but the chords help make a cohesive loop/pattern for me.
@zfigz
if youre looking at other generative stuff, i (and proly a few other here) would recomend u look at the torso if you dont already have one. the device has been stellar, the dev team has been stellar, etc.
personally i’ve been eyeing up the Midicake Arp to add to the pile.
2 Likes
It’s standing in line with the Osmose and the Terra.
yup, i have a torso.
i have the mm and ot as sorta mainstay brains and then route the output of the following sequencers to them:
- t1
- carbon
- ndlr
- noodlebox
and yeah, i was eyeing a midicake arp or ngen to replace the ndlr, but not anymore 
I’d love to see a NDLR MK2 - I hope they get a renewed interest in the project as they clearly shifted heavily onto the MRCC.
I’m not 100% sure what I’d want from an update - bigger screen and a better UI would be helpful, its a bit inconsistent in places.
I ended up selling mine as I hit limitations with it. I wanted to be able to do stuff other than Arps and found it a bit of a pain to programme more interesting melodies - that’s the main enhancement I’d want I think - a new track type. I did record a lot of tracks with it though so it’s reasonable I’d get in a bit of a rut - I think all of my released albums use it. I do miss it though, nothing else I’ve tried hits the same spot. I hoped the Oxi One could fill it’s shoes and add a lot of extra juice but it’s just a different beast, you can harmonise tracks but it’s not the same and you can make more mistakes than were possible with the NDLR.
On balance I probably wish I kept it.
1 Like
Have you read this post?
1 Like
Yep! Although I know that they’ve already hit a hard limit on memory in the NDLR so my expectations would be modest for what they can do with it in its current state tbh
1 Like
hitting a memory limit is the hot new thing it seems
2 Likes
i guess i’m confused in that there are a number of screens that say “under construction.” why would those exist if they hit their memory limit? and these words point to something that’s more than a modest update:
"It should be pretty exciting.”
Good question, here’s some info from a thread asking about these limitations:
I have seen many feature requests being answered with the device being almost out of flash memory, meaning the feature might not be possible to add due to hardware limitations.
As it stands currently, four encoders shift-pages are unused, and two of them even have printed labes (settings 4 and 5). How will they be expanded given the memory constraints?
To give a little insight into save slot data, for every feature that is an on off choice it takes 1 bit, plus 1 bit for each save slot (x8) for each feature that has multiple choices you need enough bits to accommodate those (if pad range has 32 possible settings for instance you would need 5 bits) and 8 times that number for the saves (40 bits total for our pad range demo) The NDLR saves basically every setting for the save slots, so as you can see it adds up. While the idea sounds enticing, it would require a major redesign of the software architecture which isn’t something I can see likely at this point. Not to say it won’t ever happen, just that I wouldn’t plan around it. I’ll log it as a feature request though and run it past Steve next time we get together.
https://conductivelabs.com/forum/showthread.php?tid=1269&pid=3301
Perhaps they’ve decided to do some major under the hood work, or perhaps these are exciting even if modest changes, or things that bypass save requirements etc.
1 Like
now i’m even more confused 
thanks for the forum post though, hopefully something interesting comes down the road.
out of all my sequencers, the ndlr is the one that i’m often most frustrated by. hopefully sequencing the chord buttons alleviates that frustration and inspires more confident music making. 
1 Like
My takeaway from spending a lot of time with both the NDLR and the MRCC is that both devices suffer from several design and UI choices that apparently make sense to the developers and a few other people, but are counterintuitive to others, including me. That constantly creates friction, and that’s where my frustration with them comes from, maybe that resonates with you. And after I realized that, it was a rather simple decision to let go of my NDLR. Kept the MRCC, though, because there’s currently nothing else to replace it with.
2 Likes
other than having to manually press the chord buttons, which is now resolved by sequencing their respective note #, not having a way to disarm/ignore incoming midi notes is rather annoying.
but yeah, i would much prefer holding onto it than having to replace it with something else that i will have to learn and possibly not jive with.
i’m really curious what they have in store with this next update.
edit: @Lizard-of-Oz what are some of the design and UI choices that you don’t particularly like?
It’s been a while that I have used the NDLR, here’s what I can remember from the top of my head and a brief glance at the manual:
- the clickable encoders are used as an encoder with a related button in the main mode, but the button is entirely independent of the encoder in the menu mode editors and mod matrix, where you use the encoder to jump to another page. In my opinion, an encoder you use for selecting something or changing a value should not lead you somewhere else entirely when you click it. This gets in the way of discoverability and makes the UI harder to learn. I found this especially annoying with the rhythm editor and the chord sequencer, because jumping out of those got in the way of my creative flow. IMHO the same features are possible with a more consistent user experience, and with the same number of encoders and buttons, even with the existing front plate layout and labeling.
- I also don’t like the paradigm for loading and saving, where you have two boxes, one for loading, and one for saving. The way that is implemented you can’t reliably see which sequence, global preset etc. is active: you can change values in a box without loading, and that value is retained even when you exit and re-enter that page.
- the pattern editor only allows for chromatic notes or notes that are in the current chord. Other intervals are not possible, I found that limiting.
- you can’t set custom destinations for cutoff and resonance for the controller pages, but I haven’t seen (or owned) any device that actually uses the fixed controller numbers, so that feature is useless. BTW, I couldn’t use the MRCC to remedy that, because it has not enough slots for remapping controllers.
- there was something simple missing in the implementation of the drone that made it difficult to use it for either playing or transposing external arpeggiators, I don’t remember what it was
- no backup. You can’t dump patterns, motifs, sequences, setups via sysex or USB. When my unit froze in a way I had to totally erase it, everything I had created on it was gone.
On the MRCC: first and foremost, navigation is a mess: Instead of a common and straightforward point-and-click approach, where one would simply turn the clickable encoder to point to an element on screen, and then click the encoder to interact with that element, you use the up- and down-buttons to select an element, and then you use the encoder to change a value. Unless it’s a button, then the encoder does nothing, you have to press the enter key to toggle it. But if you happen to click the encoder, you trigger a short cut, and it jumps to the routing page (another place in the menu), which is extremely annoying, because I have that in my muscle memory from countless other devices that do it right. Lots of other stuff with the UI, too. And since a midi router is not something you interact with on a daily basis, that friction will never go away, I’m afraid.
Now with the latest firmware they even remove the small security check before overwriting a setup, so it’s dead simple now to accidentally overwrite your settings. A major issue because there is no way to dump your setups via USB or sysex, you have to unscrew a side panel, remove the SD card, and put that into your computer. Good luck with that if your MRCC is in a rack.
Again, IMHO the same features are possible with a more consistent user experience with the same number of buttons (or even less).
3 Likes
I think we all owe you a thank you for reviving this zombie thread, and making us all give our NDLRs some attention again.
(mine is dustyAF)
3 Likes
5 Likes