#245

Works for me. First of the “bad” ones it was ch3 (3rd from the left) the second one was ch4 if thats any help

#246

OK, I’ve had a quick look at the firmware to see if anything could be funky there. The obvious thing I can think of is that writeMidi is just trying to do too much in the context of an interrupt; interrupt functions should be fast, but that’s doing a bunch of midi writing and possibly a bunch of i2c writing as well.

My initial proposal is to rewrite that so that the interrupts are just setting a flag, and the MIDI functions run outside the context of interrupts if that flag is true. I’ll see if I can get a branch with this code in done tomorrow am.

6 Likes
#249

Does anyone have a compiled 1.32 firmware with the Invert flag enabled that I could download? Would be much appreciated :slight_smile:

#250
#251

Thanks unity2K, but unless I am mistaken there is only the regular firmware for leader and slave? No worries though, I will take a shot at building the firmware with the invert flag.

1 Like
#253

Is the MIDI in the Faderbank bidirectional to support, say, pickup mode?

#254

Oh, interesting. So: the USB MIDI can be bidirectional. There’s a read hook in the code that is currently no-op, but exists to stop crashes on inbound data. You could add functionality to that if you wanted.

Minijack is assumed to be OUT only.

How do you envisage pickup working - or are there known standards for it you’re thinking of?

#255

Oh, interesting. So: the USB MIDI can be bidirectional. There’s a read hook in the code that is currently no-op, but exists to stop crashes on inbound data. You could add functionality to that if you wanted.

Minijack is assumed to be OUT only.

How do you envisage pickup working - or are there known standards for it you’re thinking of?

#256

Bearing in mind I don’t really know what can be done from within Faderbank:

Something like the Octatrack can be called to transmit its current CC values via MIDI so that when a pattern is changed, the controllers get information about what the new CC values stored within a scene are.

Then the pickup can work in many ways: passthrough (when the fader goes through the current value, values start changing), scale mode (i think this is Ableton naming. Let’s say that the fader is at 10, current CC value is 64. The fader is scaled so that moving the fader all the way up results in a CC change of 64, not 117.)

These are two common ways, but there are more. IMO, and many agree, the scale mode is very nice. Is this what you were looking to hear about? :slight_smile:

#257

That’s normally something the “host” side of things is responsible for, right?
Interesting approach to maybe turn this around

#258

What I know is that at least the Faderfox UC4 has a “snap” fader mode, which is like the passthrough mode I described above. I think that at least the Octatrack doesn’t offer a passthrough or scale setting, so it would be beneficial with those devices.

Saying that, I’m no huge expert on the matter, just trying to read up on it :slight_smile:

#260

OK, so I read the UC4 docs. “Snap” mode is partly useful on the UC4 because you can swap between banks of faders - meaning you’ll “page right” and your first fader is now fader 17, not fader 1, and it’s possibly not right. So ‘snap’ mode is a meaningful choice when that’s a possibility, for starters. That’s not something 16n supports, so it’s not really relevant

It also sounds like it has some way of snapping based on MIDI input, but that’s poorly defined/documented, so I’m going to pass. Still: good to read up on.

1 Like
#261

Thanks for the info, learning this myself! Good to know what the 16n does and doesn’t do :slight_smile: :+1:

#262

Infovore, is this the 1.32a build that you sent to Raph? If so, I can confirm that this fixes my fader issue with i2c. However, could I possibly trouble you for an “inverted” version of this build? Or maybe the latest code in Github (which I’m not very familiar with yet) already contains this fix?

1 Like
#263

I can get you a latest firmware with inversion. I’m probably going to merge the 1.33 branch into master tomorrow, it seems to have tested correctly. When I do that, I can compile you a version.

3 Likes
#264

it has the changes to the interrupt mentioned earlier

1 Like
#265

just wanted to say that i’d be also a happy recipient of such an inverted version!

#266

Looking around for firmware 1.33 :slight_smile:

#267

I have not got around to merging the code and doing a release on GitHub, which takes a little time to do right. I would announce it hear when it is done, but pestering doesn’t fill me with enthusiasm to do so.

This weekend, I hope. Bear in mind this new firmware literally just changes what was going on inside an interrupt function. I’m not even sure that will change much, but it’s tidier code.

3 Likes
#268

My apologies as it was just my enthusiasm and by no means was it meant as pestering.

1 Like