A use case for specifying the I/O ports in the Lua API

I’m looking forward to getting my hands on E1, and my use case would be extending the launchpad surface to provide better usability / features by extending it with a screen and encoders of E1. To me it’d greatly enhance my experience of using the launchpad if E1 could be a proxy device between e.g. the launchpad and an iPhone or a hw synth and I could program the launchpad surface to react in specific ways.

Here are a couple use cases I’m thinking of (some of those are covered by the launchpad itself, but for the moment let’s pretend launchpad is just a 8x8 touch sensitive button matrix):

  • specifying the key on E1 so it’d remap the incoming launchpad notes
  • specifying the chording on E1 so it’d take in the note down event from the launchpad, send back a light up events back to it and send the corresponding notes to the hw

These would requite routing the midi messages to specific interfaces and more so would rely on not having them broadcast across all the interfaces as e.g. the note on to hw would have the original velocity and the note on to the launchpad would have the velocity dictate the color.

1 Like

The 2.1.x branch of the firmware broadcasts the messages to all interfaces indeed. The only option is to remove an interface from the broadcasting. This setup is in place to provide simple routings for common usage.

The development branch of the Midi controller firmware - soon to be published on github - sees all ports and all interfaces as individual sources and destinations of MIDI data.That will allow all types of routings. That firmware will have to stay in “beta” version for some time as some of the changes are quite radical. I will be happy to cooperate to get in any types of ideas in. And as it will be opensource, anybody can join :slight_smile:

That’s exciting! What’s the firmware based on? Is it mostly or C/C++/rust?

1 Like

it is C++ with JUCE like API. The base firmware is available on GitHub already: GitHub - electraone/firmware: Electra One base firmware

1 Like

Heh, funny how I was sold on the device even before I knew that the firmware is opensourced and now it seems that it’s an even better piece of hardware! And you seem to have picked a pretty beefy MCU to run the show, too.

2 Likes

Thanks for your PR! Please ping me when your Electra arrives, we will have to tackle the command line version of the firmware uploader for linux. I have something but it is not part of the repo yet.

Yeah, I saw the IOKit code already. I think that could be ported to libusb to make it more universal but I don’t have good starting points on that yet (never worked with USB HID before). Might as well toy with an arduino hid while waiting for my Electra to arrive.

I have the libusb code and Electra One console app uses that. It works fine on Linux. Will share it with you.

Just got my electra.one and I’m thoroughly impressed by the build quality and just how nice it feels. Great job there! And it can bus power the launchpad, wow.

So, what about that firmware uploader source code? :slight_smile:

1 Like

Martin,

I’m also interested in the libusb code for the firmware uploader for Linux (and potentially Windows), as I tried with the Teensy one and could not make it play well. Would be nice to incorporate it into the Makefile of the firmware (as you have partially done already).

I see you support PR to the repos, is that the case? I’ve been discussing a small bug in the Lua API in the bug section, I can try to PR it knowing you’d double check what it’s doing is what is intended.

1 Like

@petruccigp @farcaller I am currently swamped with the work on assembling/shipping Electras. Will respond as soon as I can. Pls give me one / two days.