a monome hub?

  • Tried searching for this but didn't get anything relevant... Thinking - could it be useful to have a small device that would act as a hub for Monome devices?

    As I understand it when using a computer a USB hub would work since the OS already implements USB Host functionality, so to any app running on a computer all devices appear as if they were connected directly. But when using a USB hub with eurorack modules or the Aleph it would require its own implementation in the firmware (and I think Ezra mentioned some difficulties with implementing it on Aleph?).

    So if there was a device that would implement a USB host layer then it would mean not having to do it for any of the modules / Aleph. Does this make sense? Additionally it could translate older protocols to serial.

  • i have something like this .
    i have 256 & 64 even though i connect them directly to my mac together, my 64 doesn't response suddenly and i need to wait 20 to 30 second to use.

  • if it worked flawlessly with pc, euro, aleph and wasnt unwieldy i'd buy


    a few questions i'd have:

    how many ports?
    can such a device be bus powered?

  • Oh I should've made it more clear - it's not something I'm planning on building (wouldn't know where to begin!) just throwing an idea out there - I do think it would be useful now that it would help not just with the Aleph but the eurorack modules as well or anything Arduino based as you wouldn't have to implement the USB Host support. But yeah, it could have a port to connect it to a computer as well, and could have the option to be bus powered or have its own PS.

  • i know @a_s_d

    those just popped in my head if somebody actually were to attempt this project

  • it'd be easier to just implement usb host support in the aleph and modular series, if someone wants to do that!

  • i would say rather that it's just as difficult to implement hub support in a host stack for new device as for the existing devices - which is to say, damn hard. ASF and LUFA developers both gave up. i have yet to see an open-source solution outside the linux kernel.

    but indeed, i too fail to see the benefit of throwing more hardware at the problem.

  • and to be clear: certainly extending the host stack would be necessary. what you are describing (thing that connects to multiple devices and forwards them) is itself a hub, or a host presenting as a hub. or a hub and a host on the same board. or a whole bunch of USB hosts on one board. it doesn't simplify anything.

  • last post sorry: look at the ASF sources for an unfinished implementation that could serve as starting place: http://www.atmel.com/tools/avrsoftwareframework.aspx?tab=overview

    the main host stack source is here:
    https://raw.githubusercontent.com/tehn/aleph/master/avr32_lib/asf-3.7.3/common/services/usb/uhc/uhc.c

    you can see that the hub support is preprocessed out. that's because it doesn't work. i have been waiting and hoping that Atmel fixes this in future versions (up to 3.12 now i think) but it hasn't happened yet.

    fixing this ourselves would be, by far, the path of least resistance to the functionality you desire.

  • Interesting - thanks for the info, I'll read up (mostly for curiosity as I don't have the skills to attempt implementing something like that). But that to me is the benefit of having a device like this as you wouldn't have to solve this problem or re-implement for each different platform. And there might be some hardware limitations too depending on the platform which this would solve. Not sure what the White Whale runs on but it would be nice to easily create a new firmware that would take advantage of having both a grid and an arc connected at the same time, for instance.

    What about an easier hardware solution, something that would simply merge incoming messages and broadcast any outgoing messages to each device? (apologies if this is crazy talk). I guess this wouldn't work for, say, two grids, but should work for a grid and an arc since they would just ignore messages that are for a different device type?

  • Did some reading and I see that I'm guilty of muddying the terminology somewhat - it is indeed the hub support in the USB host stack that seems to be missing (at least in Aleph and nw2s::b, not sure if WW/Meadowphysics use their own implementation instead of a USB host stack).

    And what I said above about simply merging upstream messages and broadcasting downstream messages to all devices is I guess exactly what a hub does, the only exception being when any status changes appear in downstream devices - so that's the hub support in the USB host that is missing then? Meaning that the host won't learn about any devices connected through the hub until it knows how to talk to the hub?

    If that's the case I'd love to read up on the reasons why it's proving to be difficult - are there good forums / discussions that would go into more details on that? I'll take a look at that ASF link as well.

  • Was talking with scanner about this offline. There is one (AVR I think) hub support in host stack available from the guys who built the Arduino USB Host shield (http://www.circuitsathome.com/mcu/usb-host-shield-library-version-2-0-released)

    The difficulty it seems to be the abstraction required to be able to effectively virtualize connections. hub-less USB itself is pretty darned difficult within an MCU environment... and if anyone else is like me, some shortcuts get taken to just make sure it works...

    Since it's a controlled environment with specific hardware on both ends of the cable, that's not too embarrasing to admit... with something like the linux kernel, you have to do it right as you're going to have an install base of some odd million devices with a good 10 times that number of devices hanging off no telling how many brands of hubs. You've got stack space and CPU to spare and some random manufacturer probably paid for it with a government contract.

    It's certainly an interesting challenge and one I may take up one day, but I definitely need to just get plain ol USB host support considerably more solid... Maybe one day... and if, in the mean time someone else picks up the torch, I'm happy to leverage as much as possible!

    s