Grid-usbmidi hardware bridge

[zebra]

@okyeron cool

if you want to put something on GH i’d be happy to contribute, though i’m travelling without grid or much extra hardware until mid-january.

what i’m thinking is that another kind of “elegance” can be achieved by adding a small scripting layer (lua) to the adapter. using a 128-button grid as a 1:1 midi controller is minimally useful by itself. and requires software to manage state and mappings. something like isonome has a very small footprint, doesn’t require complicated timing stuff, and makes the grid+dongle into a simple but flexible controller.

the reason i think this is “elegant” is it takes the functionality out of the iOS (or whatever) software, so you have a playing surface that behaves the same regardless of what you plug it into. a “passthrough” setting can still be used for more complicated UIs implemented host-side.

MIDI issues: whats the best way to map multiple keys with the same note number? different channels? can audulus handle multiple channels? &c.

[okyeron]

iOS developer asks: Why not make monome grid USB MIDI class compliant?

if you want to put something on GH i’d be happy to contribute, though i’m travelling without grid or much extra hardware until mid-january.

@scanner_darkly and I started chatting about this earlier today and have a some ideas brewing. We could rope you in as prototyping comes along.

[tehn]

oh oh.

this is basically crow with a usb host and no cv (!)

which is like a micro-micro-norns in some ways.

main issue i see is finding a uC with both a host and device port (not sure this exists). a solution would be a avr8/etc as USB host getting FTDI in/out (connected to grid/arc) and then communicate with main stm32+lua+usbdevice via spi/etc.

stm32 could enumerate with multiple usb endpoints: usbmidi + whatever else (serial)

this should be a new thread.

[okyeron]

main issue i see is finding a uC with both a host and device port (not sure this exists)

Teensy 3.6 does this. Also it supports usb hubs so could connect multiple grids and arc at same time

[scanner_darkly]

what i’d like to try and prototype with @okyeron is a teensy based device that would host grid/arc and support a simple grid/MIDI bridge.

additionally (and this is where my own main interest is) i’d like to try implementing multipass for this platform. multipass is a very simple “framework” (if it can be called that) i’m currently working on that separates hardware specific bits from grid aware (but hardware agnostic) code which is separated from the actual app logic. one of the ideas behind it is being able to re-use the same app code on different platforms.

what makes it interesting for this case is that an app that is developed using multipass will be able to run on ansible or any of the trilogy modules, but it could also be easily ported (with no or very minimal modifications) to this grid/MIDI bridge. there are obvious benefits, of course, but i also like that this could bridge (pun intended) modular and non modular user groups (there are, of course, apps that exist for both eurorack and max but even if they’re similar they diverge in many ways, and maintaining separate versions will only make them even less similar).

re: scripting - makes total sense, and would be super useful and an easy way to extend the controller logic. lua would mean the potential of being able to re-use norns scripts. but i’m also wondering about supporting teletype language… (this is all just vague thoughts atm though)

[audulus]

I would humbly suggest making something that’s really simple and let the host do the work, just like most other controllers.

the reason i think this is “elegant” is it takes the functionality out of the iOS (or whatever) software, so you have a playing surface that behaves the same regardless of what you plug it into.

For an iOS app, the best user experience will come from the app having full control over the grid.

MIDI issues: whats the best way to map multiple keys with the same note number? different channels? can audulus handle multiple channels?

I suppose MPE would be the right way to do that. Audulus doesn’t yet support it, but I’m planning to

[tehn]

aha! this is an exciting development indeed.

seems we have a number of cross-pollination approaches, and they all sound great. let me know how i can help.

[scanner_darkly]

thanks @tehn, will do! for now i really just want to start super simple and get a working prototype and go from there.

@audulus - i think both use cases can co-exist quite easily (there could be a simple switch or some other way to choose what mode you want to run in). supporting your use case should be super trivial, unless i’m missing something, and yes, we’ll start with that. somewhat getting way ahead - i also don’t see why there couldn’t eventually be multiple versions of this, a super simple dongle for somebody who just needs ios functionality or a more advanced one for other users.

[audulus]

Yeah, sure… I would just do the super simple thing first, and get it out there and see what people think

[SimonKirby]

main issue i see is finding a uC with both a host and device port (not sure this exists)

An alternative would be to go wireless with midi over Bluetooth low energy, which I think would be a lovely way to interface a grid with an iPad for example and would be plug (or not plug!) and play on the iOS end of things.

[zebra]

main issue i see is finding a uC with both a host and device port (not sure this exists)

Teensy 3.6 does this. Also it supports usb hubs so could connect multiple grids and arc at same time

[edit] refreshing my memory here…

in the past i’ve used a host shield designed for arduino pro mini with teensy, for dev+host:
https://www.pjrc.com/teensy/td_libs_USBHostShield.html

but this is actually a kind of sub-processor (maxim MAX3420E host controller) connected with SPI.

does newer teensy actually have multiple ports onboard? needs research

[ed] yep, appears 3.6 really does have two full-blown ports on it. the cortex-m4 is pretty heavy overkill, processing-wise, but maybe thats fine for POC.

go wireless with midi over Bluetooth low energy,

later. power management is already my major concern here. (does the adapter also need to supply grid power? &c.) part cost and programming complexity also goes up.

For an iOS app, the best user experience will come from the app having full control over the grid.

well, i disagree a little, but NBD, we can support that trivially and even make it the default. in my limited capacity as an ios user, my preference would be to have something very slightly more sophisticated to plug into animoog or whatever. it would add tremendous value to the “adapter” object, transforming it from a liability to an asset.

so, concrete proposal: have the thing respond to Program Change by switching mappings. make “passthrough” mapping a fixed default (program zero or something.)

would be super useful and an easy way to extend the controller logic. lua would mean the potential of being able to re-use norns scripts

to me, having a lua interpreter on the teensy isn’t vague or blue-sky at all, but a trivial first step to provide basic config like channel selection. lua scripts make a nice config format and the LVM is super lightweight; these days it’s the first thing i add when prototyping this kinda stuff. (easier than rolling a bespoke config language with ragel or whatever.)

i’ll try and get going on some of these side channels (dev+host mode, config channel.) dovetails with some work stuff i gotta do in the next couple weeks anyway.

[okyeron]

(does the adapter also need to supply grid power? &c.) part cost and programming complexity also goes up.

I pondered this earlier. Keeping it simple… If using as a usbhost, power can come from the teensy usb (i.e. from the computer) and pass through to devices (I suppose I should check the values supported for that). If using standalone (plain midi out via minijack), usb power can just be plugged in to the teensy usb. If grid demanded too much power, then it would need an offworld or a powered USB hub.

[lijnenspel]

Instead of the expensive and overkill Teensy, I’d recommend the SAMD21/51 which also has both usb host and dev usb. I’ve recently ported MonomeHost to SAMD for my own project, it’s on github as a fork.

[zebra]

questions

its here yea?
[ https://github.com/monome/MonomeHost/compare/master...jellea:master ]

doesnt seem to break anything for Uno…? shall we just PR upstream (and try it out?)

is something like these usable? (sparkfun samd21 breakouts)
[https://www.sparkfun.com/products/13664]
[https://www.sparkfun.com/products/13672]

is there any example / POC for simultaneous dev+host?

[ed: close https://www.arduino.cc/en/Guide/ArduinoZero#toc10]

[ed: considering going straight for atmel board and bypassing arduino. esp as i can’t find any Zeros for sale, there is some weird bootloader fork related to trademark dispute, and no other arduino-compatible boards seem to ship with the 2nd usb wired up.
https://www.microchip.com/developmenttools/ProductDetails/atsamd21-xpro ]

dang wish i had not left the grid at home this time

If using as a usbhost, power can come from the teensy usb (i.e. from the computer)

is this a terrible idea for a lightning port?

[lazzarello]

is this a terrible idea for a lightning port?

Thunderbolt 3/USB-C alternate mode device :troll:

[lijnenspel]

its here yea?
[ https://github.com/monome/MonomeHost/compare/master…jellea:master ]

doesnt seem to break anything for Uno…? shall we just PR upstream (and try it out?)

Yes exactly. Not sure if it would break the Due as I don’t have one, wouldn’t PR for now…

I’m using the Arduino M0 Pro for dev as it conveniently has the two usb ports already, but I believe its discontinued.

For a Dadamachines project we’re using a custom samd21 pcb, but with arduino code. Its a sequencer taking USBHost (monome and launchpad) and spitting out i2c to the Dadamachines automat’s extension port. I can send you the eagle files if you like. There’s not much to it.

This seems to be the best USB Host lib out there for samd https://github.com/gdsports/USB_Host_Library_SAMD/
Although I had to hard code some things to make it work with MonomeHost (but that might be my lack of c++ experience as well): https://github.com/jellea/USB_Host_Library_SAMD

[greaterthanzero]

MIDI issues: whats the best way to map multiple keys with the same note number? different channels? can audulus handle multiple channels?

How would this come up?

(Default “passthrough” is one note per key, and you’re talking about a 128. Alternate apps might introduce overlap, but that will call for different solutions depending on use case, and should be handled by those apps individually. Count on some apps requiring multi-channel, bur not necessarily for this purpose.)

I suppose MPE would be the right way to do that. Audulus doesn’t yet support it, but I’m planning to.

Absolutely not.

MPE comes with overhead and expectations that don’t apply here. Specifically, channel 1 is off limits for everything but global messages, which utterly breaks the default plug-and-play functionality you’re aiming for.

Also, interface development on either device requires predictable channel behavior from the other half. MPE isn’t about that.

It’s about layers of expression not suplorted by grid. And there’s no need to muddy the waters on that.

(Do support MPE on Modulus, but also a generic multi-channel mode for loose MPE-like behavior.)

Instead of the expensive and overkill Teensy, I’d recommend the SAMD21/51 which also has both usb host and dev usb.

Does SAMD21/51 support multiple endpoints?

Teensy can present as up to 16 ins and 16 outs.

I contend that this isn’t overkill. And in fact, that it’s going to prove invaluable for concurrent app usage on iOS and beyond. (Think “pages”, on a grand scale)

Y’all are gonna want that.

(Also multiple grids, arc support, and 256. None of which is strictly necessary at launch, but they’re all doable in firmware without any hardware changes; just add a USB hub.)

[zebra]

Does SAMD21/51 support multiple endpoints?

yes, 8 physical pipe/endpoints addresses, plus virtual endpoints. (datasheet)

i’m looking over the atmel SAMD environment. i don’t mind it, and MonomeHost comes from similar environment originally, but seems like it’d be better to base this thing on arduino instead of requiring ASF stack and atmel studio.

(aside, this will be a good opportunity to hit some FIXMEs in MonomeHost.)

so i think will attempt to use this library with the SAMD21 “x-plained pro” board as a first stab, before getting into custom boards. (again would be nice to find off-the-self arduino zero with the 2nd port wired, but it just doesn’t seem to exist at the moment, closest is MKR package with a little extra wiring. gonna go with the atmel board for starters b/c of the onboard debugger.)

---

on first and second glance, teensy 3.6 truly does seem like overkill. this application just doesn’t obviously need a 72/180Mhz CPU. in this context it’s significant that the cortex m4 draws 2-4x more power than the -m0 (depending on clock setting.) less power-hungry teensys lack the extra USB controller.

but again, if it’s built on arduino the cpu spec doesn’t need to be set in stone which is nice. maybe i’m wrong and running soft-realtime lua for this will just choke on 48Mhz. (really doubt it)

multiple channels?

How would this come up?

in non-default, overlapping layouts that are not 1:1, unisons can stack across channels. similar to MPE. this just seems like a more musical use of 128 buttons when paired with a multitimbral synth. not really something to worry about though.

[TheTechnobear]

for the ‘midi api’ perhaps take a look at the launchpad api for some ‘inspiration’
has some of the concepts discussed here, and also some ‘features’ which help with midi efficiency for more complex host applications.

launchpad-programmers-reference.pdf

[okyeron]

Instead of the expensive and overkill Teensy, I’d recommend the SAMD21/51

I don’t understand this comment. The Teensy 3.6 is $30. @zebra found a SAMD dev board that 's also $30. How is the Teensy more expensive here? Are we talking some future with a custom board? How much does it cost to develop that board? Teensy is a ready to use right now solution.

Who cares if the Teensy is overkill for a processor? I sure don’t.

in this context it’s significant that the cortex m4 draws 2-4x more power than the -m0 (depending on clock setting.)

Power consumption - yeah maybe this is an issue, but seems pretty solveable.

The question becomes - what’s the goal here? Is this specifically for mobile devices or is it a general tool that can support multiple use cases? Is it a "product’ or is it a DIY project?

Sure - multiple approaches to hardware/software are fine and dandy. It’s obvious there’s going to be many different opinions on how to do something like this.

Please keep in mind I already put together a working prototype with the Teensy 3.6 and have it doing MIDI pass-thru from a grid. It works, today, with about 4 hours of work.

@zebra I’ll send you one of the teensy 3.6 prototype shield pcbs I designed and ordered last night when they come in from oshpark (after christmas).