yes sure, in general.
the problem of supporting DIY versions is not really trivial:
on one level there is the systemic, logistical problem that we really cannot predict testable attributes of DIY devices; like device id strings, VID/PID, or even the exact serial protocol. (in fact that is a real sticking point: some of these arduino devices are pretending to be ACM modems, instead of the dumb fixed-baud devices that grids are; crow is an actual ACM modem so there is a bit of an issue - anything that tests for arduinos has to touch crow stuff, and so far we it seems the trellis+crow+developer venn diagram is empty.) and grid protocol doesn’t include a handshake sequence that we could use to test.
in any case, i wrote the original device listing stuff long ago, in a hurry; it is gross and dumb. i would like to rip it out and make it simpler, more testable, and with a small configuration layer so that you can customize the strategies for hardware detection. i’m not sure there’s any other way to provide general support for grid clones that don’t use the same USB profile as monome grids.
([ed: like @tehn points out below, if you really want to make a grid clone, either 1) use the same USB-serial driver chip that monome uses, making things very easy for developers and users, or 2) be prepared to roll your own software support for your alternate design, and/or provide robust upstream solutions for it if you expect full integration.)
but it’s a tall order right now. one reason is there are other parts of norns stack to work on. another is that have zero desire to put time into making DIY grids. so we need a stakeholder in this feature with the chops to implement it and the means to test it. or someone needs to send me a device and i will send it back.
i do agree that we should avoid the patching thing. it is a little weird. if we can add support for these devices in a feasible way to upstream norns, we will do it. appreciate that keeping crow interfrace working is a more primary goal.
