#1

Another Christmas break means time for a small point release of the 16n firmware.

Details and .hex files are over at Github:

This is a minor upgrade to version 2.0.1, and everything new added in 2.x.x (as described in that thread) is still relevant.

This small release adds two new features:

  • soft MIDI Thru option. Once you’ve upgraded your firmware, you’ll be able to toggle this on from the online editor. When enabled, any MIDI data (including clock data) sent to the 16n will be echoed out of the TRS MIDI jack; useful for sending data or clock to other instruments, using your 16n a little like a MIDI interface. Thanks to @AtoV and the Berlin Modular 16n port for their work on this feature!
  • factory initialisation sysex message. Sending an 0x1a to the 16n will force it to reset its EEPROM to factory settings. This will erase any config you have on the device. This is mainly to fix an issue of people re-using old Teensys for 16ns that may already have EEPROM data that would confuse the editor. Now, if the editor can detect a 16n remotely, but can’t read its config, it will offer you the option to force a factory reset remotely. This may be of use if it looks like your new 16n - made using a left-over Teensy 3.2 - isn’t working.

I’ve made .hex files for both regular Teensy 3.2s and Teensy LCs, for 1.3x hardware, and they’re linked in the release. For most people, using the .hex file with Teensy Loader, as detailed in the 16n wiki, is the recommended upgrade path.

Enjoy.

20 Likes
16n is a bank of faders [release thread]
#2

Apologies if this is not in the correct location but the other thread seemed to include Feature Requests so I assumed this was an alright place for one.

It’d be really useful for me to have MIN/MAX CC values per-channel. The use-case is for something like the Octatrack - where the Volume of the Amplifier VCA goes from -64 to +63, with “no gain” being 0). I just tested this with the 2.0.1 firmware and 0-127 comes out to the full-swing of the the parameter, while I would bet that a 0-63 range would go from -64 to 0.

Currently I’m using the 16n for the the Track Levels - which works but my understanding of the signal path is that means it’s post-FX slots - where as controlling the VCA would be pre-FX, which may be ideal.

1 Like
#3

I have a Berlin Modular 16n edition. I updated using the 16n_v210.hex.

I do get invalid midi data out with the type B trs connector from the Beatstep Pro. When I switch to the Type A trs connector that came with the 0-coast there is no midi data being put out. Do I need to buy a different Type A dongle? (I did toggle the switch between type A and B on the back of the 16n)

#4

iinteresting. so, heads up: I didn’t write the MIDI-Thru code; that was all coded by @AtoV and the Berlin Modular crew. However, that means it should work. There should definitely be no difference between the type-A/B connectors output (in the sense that it’s a straight hardware switcheroo: the right connector + the right mode should just work).

So: could somebody else with a Berlin Modular board, possibly @AtoV themselves, confirm the official 2.1.0 hex works correctly with the MIDI thru setting? I did the barest alteration to their code (namely, sticking it behind an EEPROM-powered feature flag, rather than a bool), but there may have been a mistake in the translation.

1 Like
#6

Hi,

happy new year to all of you!

@jasper_ryder
The circuitry for the MIDI is the same in the original 16n and my redesign, therefore the firmware is fully cross compatible.

I think Make Noise uses Type A midi connectors therefore the switch should be on the left. (Try both sides in case I’m wrong)

I tested the new release again with 16n with teensy LC and Teensy 3.2 and I had no issue.
Are you sure you get midi data at all?
Do you get signal from the faders?
Make sure the MIDI Thru function is activated in the editor, it’s off by default.

If you don’t get signal out, I’d start by reinstalling the firmware.

If you continue to have issues with MIDI I’d check if R83 and R85 are soldered properly.

Let me know

3 Likes
#7

Hi @AtoV,

It seems that maybe it is a hardware issue? Here you can see output over USB is normal. The strange output is from the Midi Jack with the B style dongle. Zero output from the A style dongle still. I did reinstall the firmware a couple times. Maybe the surface mount parts are backwards?

Screen Shot 2021-01-05 at 10.23.46 PM
Screen Shot 2021-01-05 at 10.23.46 PM1315×361 28.4 KB

Screen Shot 2021-01-05 at 10.21.24 PM
Screen Shot 2021-01-05 at 10.21.24 PM876×770 93.3 KB

Screen Shot 2021-01-05 at 10.22.15 PM
Screen Shot 2021-01-05 at 10.22.15 PM923×787 94.6 KB

IMG_1633
IMG_1633800×600 130 KB

#8

Hi,
I’ve just installed this firmware on my 16n and it now I need power it after my 301. The 16n is powered from my case and used to all boot up correctly and connect without needing to unplug and plug the 16n back in. Is there an option to change the boot up time?
Pretty sure I was running an older firmware that had a boot up delay built in.
Thanks in advance :relaxed:

#9

This doesn’t look like a hardware issue as you’d have invalid data if that was the case.

Does this happen when the midi Thru is deactivated?

To me it looks like data if being sent to the 16n USB MIDI, do you have any other program running in the background. Please activate “Spy on output to destination”. Then you’ll see if something is sent to the 16n. If the data being sent to the 16n is sent to the output this means that everything works fine on the 16n side and that the issue is elsewhere.

Let me know

#10

If you are comfortable compiling the firmware yourself, you can uncomment the line 37 in config.h (removing the // )
#define BOOTDELAY 10000

This will delay the start up and give time for your ER301 to boot before the 16n does.

Otherwise send me a PM with your email, I’ll send you a precompiled firmware.

@infovore maybe this can made by default when the 16n is set as i2c Master so that it gives time for slave devices to boot before the 16n. This would make the connection more reliable IMO. If you like the idea, I’ll make PR.

2 Likes
#11

I actually have no idea how to compile a firmware so your help would be awesome!
I’ll pm you :slightly_smiling_face:

Having it set as a default for future firmwares would be a fantastic addition!

#12

@AtoV

No

When sending midi from Norns the only data received is all invalid. Like this:

Screen Shot 2021-01-08 at 7.27.01 PM
Screen Shot 2021-01-08 at 7.27.01 PM1367×823 115 KB

#13

Actually, that’s a good idea. It was suggested once that we just delay the boot everywhere, and I wasn’t happy with that. But adding a the slowdown if the faderbank is i2c leader is actually a good idea - it doesn’t affect most users (who are all on i2c follower by default), and if you care enough about i2c to have your faders as leader, you won’t mind the 10s bootup delay.

I think that’s a good idea?

5 Likes
#14

Hi @jasper_ryder

To be honest I’m really confused by your issue, I have been testing the firmware again and could not fault it. I tried sending any kind of midi data at once and compared what was sent and received as well as measured delay and there was no issue at all, no invalid data nor dropouts. I even tried with a norns and I’ve had no issues.

The first few screenshots you sent me shows that midi is going through properly. I see that some messages are repeated, I only had this when I had some unwanted midi loop

Do you mind trying to fix this problem through emails? I’ll come back to the feed and explain the issue when we figure out what is happening.

2 Likes