nOb controller apparently available this instant (this is not a drill)

Heads up, everybody; I happened to check the nOb control site and it looks like the current batch is available (as of right now), but the email hasn’t gone out yet. I’ve missed out on six batches (they seem to sell out very quickly after the email) and just placed an order. No idea if it will work well with Rack or not but I’m sure eager to try.

Sound on Sound review here.

Looks like there are two left.

Surprised at the price $238, for one knob, blooming hummer! Might stick with internal VCV Rack for a while!

2 Likes

I was suprised, too. But after watching the viedeo and reading the review i think it is quite reasonable.

1 Like

Having thought about special controls, supporting electronics, and software for VCV, even given the video, I’m far less impressed. It looks like a Hall rotary encoder mapped to mouse events, some capacitive sensing, and a couple of mode switches. The only extras are a microcontroller and a few passives, and you’re golden. This isn’t terribly difficult stuff and not really above high school maker level. I feel this is pointed at the more-money-than-brains crowd.

Well, I don’t have a lot of money, so I must have a very small amount of brains for ordering it! But I will report back.

FWIW, what you’re paying for is (1) the onboard software which (coupled with the design) gets a knob to appropriately work as a mouse pointer using native drivers; (2) the Assignment Center software, which significantly expands those possibilities. Those are both pretty non-trivial development and design efforts. Nobody’s buying this for the bill of materials. If this were just outputting 14-bit MIDI CC or something I’d consider it overpriced at $75 no matter how nice it feels.

Anyway, they sell instantly on the used market so if it doesn’t work well I can buy some of my brains back! :smiley_cat:

2 Likes

The software effort is really not that impressive. Look. I’ve been doing this stuff for decades now, most recently drone telemetry and control. The real functionality of the nob software really is nothing to write home about. I think we both have different notions of non-trivial.

Behringer Xtouch mini aroudn 40 or 30 bucks and forget about it :wink: Looks nice but $$$

3 Likes

For me, I really want multiple high res controllers for controlling a synth while I’m playing it. The need for staring at a screen to see what the knob is doing is a distraction from playing. Unhappily, the best chip I’ve found for my recent ideas (AMS AS5601) seems VERY thin on the ground. That gives 12 bit rotary and push button. Cap sense is bundled with some of the ARM m0 micros. There are a few mech issues to resolve, but I think this should be trivially doable. I may brain pick an mech engineer who cold called me recently for ideas.

Hi @caowasteland! I’m also a software engineer, along with half the people on this forum.

Happy to disagree with your assessment of what it takes to do effective cross-platform low level interface design and implementation!

But, to speak frankly, I’m a little nonplussed at how hot you’re coming in against, first, me, and second, a small company from Greece which was able to actually productize something that many people really like and which continues to sell well almost five years after release even at an objectively high price point.

When will I be able to buy your better, cheaper solution? Would you like me to beta test it or evaluate it against the nOb (assuming that I like the nOb and keep it)?

Korg nanoKontrol is also a good buy around that pricepoint; I have an older model that works well to this day!

1 Like

To me it looks as if you’re aggressively defending an expensive thing you bought. I get a sense of ego defense going on here rather than rational discussion. I am not attacking you. It’s your money; spend it as you choose. I just don’t think this offering is all that and a bag of chips.

The main issue with MIDI specific things is that MIDI 1.0 is very poor for 14 bit controls. I’ve not read anything about MIDI 2.0, and I don’t know how is does the larger CCs. If someone can point me at a public (even prelimenary) doc, I’d be very happy to learn.

Nope! I was just excited to try this and wanted to share it with other Rackers in case they had also been looking for one for a long time. Per my first post, I have no idea whatsoever if it will suit my needs.

If you are able to bring a new controller concept to market (or even the DIY space) I would sincerely love to try it. Rack’s underlying technology is advancing fast enough that by V2 or V3 I think that control will be the limiting feature, not the engine or the module ecosystem.

Have a good one!

Agree that the (CC+32) implementation is clunky but once it’s set up and that’s abstracted away by the receiving software, I’ve actually had pretty good luck with 14-bit CCs in MIDI 1 (with Faderfox HW–I don’t think I have anything else that supports 14-bit output). What are you finding most frictionful about them in your own work? It does double the message bandwidth if you’re sending out a bunch at once.

I am far from a MIDI 2 expert but I my impression is that it’s pretty straightforward–controllers just get 32 bits in the message, not 7 bits, and then the limiting factor (as it sounds as though you’re already well on top of) is the hardware resolution.

edit: yep, here’s the spec for 2.0-protocol controller messages (see §1.5.5).

the thing I’ve never liked about 14 bit controllers is that you don’t know when you have received both halves. It’s always been ambigous (which I brought up in an MMA meeting in the 80’s). I’ve been assured there is some rule to make this work, but I keep forgetting it.

I propose gc3’s law that all discussion of music software controllers eventually becomes a discussion about 14-bit MIDI :slight_smile:

which is fine by me!

You were right to bring that up at the MMA! The MPE+ spec formally fixes it. What I’ve seen, and used, in practice is a simple departure from the spec that basically aligns with MPE+: you put the receiver into a 14-bit mode where it explicitly does wait for a LSB to update (contra spec), and then the hardware deterministically sends MSB, then LSB, with no risk of reversal since it’s a serial protocol; receiver caches MSB on receipt and updates target with MSB+LSB when it receives LSB. Slightly annoying for the receiver and you have to live with being out of spec, but it works just fine when set up (and really does make a difference on a few things, like filter cutoffs).

yes, that’s exactly what I used to (angrily) tell them. You need to agree what it means to send these things and how you are supposed to interpret them. They just gave me blank looks.

But you are saying this protocol you describe (that sounds to me like it would work) is STILL contrary to the mid spec? How to you know which “spec” your hardware or software uses?

1 Like

Well, I’ll defer to Lippold regarding the spec (from the MPE+ page above):

The Midi spec explicitly states:

  • The LSB value is assumed zero when an MSB arrives.
  • The MSB may or may not be followed by an LSB.

The consequence of this is that a receiving synth immediately uses MSB values as they arrive, and LSB values as they arrive. Since the high 7 bits and the low 7 bits are not updated synchronously, this will always create intermediate glitch values. For example, updating from 14-bit controller value 0x1401 to value 0x137f always creates the intermediate glitch value 0x1300.

As I see it there are four non-orthogonal design dimensions:

  1. Deterministic order?
  2. MSB or LSB first?
  3. Wait to update?
  4. Negotiating 14- vs 7-bit?

#1 is the easiest; I have trouble imagining hardware that wouldn’t pick an order. Harder to make it inconsistent than consistent.

#2 is suggested by the MIDI spec and makes more sense if you pick the wrong option for #3.

MMA (per Lippold) really did pick the wrong option for #3, against your good advice, @Squinky, but in practice I think most receiving synths (at least the ones I’ve used) politely ignore the spec on that point and don’t generate the glitch values.

This comes at the cost of #4, which, if they were thinking, might have been what MMA was thinking (total speculation on my part). If you update on MSB no matter what (as Lippold says the spec says), the receiving hardware can handle a switch from 14-bit mode to 7-bit mode with no issue; the first MSB-only 7-bit update will process correctly. The only cost of this approach is that 14-bit mode is totally broken because of the glitch values. If you wait to update, and switch the transmitter from 14- to 7- without alerting the receiver, you will either:

  • Stop updating indefinitely, if the receiver is really naïve and wants to wait forever for a LSB which 7-bit mode can’t produce (and do really weird stuff if the operator starts sending 7-bit CCs 32 up);
  • Miss an update, if the receiver assumes 7-bit mode on the second MSB, which is better than hanging but does cause the first MSB-without-LSB to be discarded;
  • Delay an update, if the receiver has a timeout on LSB after which it switches into 7-bit mode, which is probably the best solution but does lead to an unexpected result.

Seems like the MMA preferred consistently bad results to any of these options. (In fairness, the first one is pretty bad and the third one does create overhead that might have seemed significant for microcontroller programming in 1985).

As to knowing what works, on the sender side there’s not a ton of MIDI hardware that transmits 14-bit CCs (AFAIK Faderfox is the most common) and my understanding from Mathias is that all of his stuff is deterministic, MSB first. My guess is that most if not all 14-bit transmitters make the same choice.

On the receiver end, I just check that it works. If software expected LSB first, the result would be hash; if it didn’t wait to update, you could hear the glitch values (especially descending, which creates nonmonotonic updates, oof). I haven’t experimented with switching from 14-bit to 7-bit without changing receiver modes, though now I’m curious; I’ll check some softsynths when I get a chance to see how they handle it. Haven’t read any of the 14-bit Rack MIDI code but now I’m curious about that too!

Bravo! The trouble is that the CC pair is not a transaction. I think the only 14 bit value in MIDI 1.0 that’s handles correctly is pitch bend.

Absolutely correct about poor choice with #3. You really can’t do the Right Thing™ without receiving both halves as an atomic action. I think a lot of this reflects the technology of the time.