Hi Dave,
the MBSEQ V4 firmware is in a pretty good state meanwhile - all functions I’ve implemented so far are working flawlessly, and whenever I find the time (currently not so often…) I’m able to add new features with much less effort than with the old PIC based firmware.
I also already did some experiments with OSC via Ethernet and don’t see a blocking point. E.g., I controlled the motorfaders/buttons/LEDs of my MBLC via OSC datagrams from an Reaktor environment, and I also tried an OSC->CAN bridge which works fine.
So, for the MBSEQ V4 controlling the BLM matrix via OSC wouldn’t be a big task, maybe 15 lines of code since the OSC parser is implemented in a very generic (and flexible) way.
Also increasing the number of BLM lines isn’t a big problem (from the software side), as the driver provides parameters to define the number of rows and columns.
MBSEQ V4 itself will be able to send and receive OSC messages via ethernet. The configuration has to be done in a (simple) .c program, because this is much more flexible (and less RAM consuming) than providing a configuration file which is read from SD Card - this also means, that there won’t be a limit to customize the OSC server/client for your own needs.
Example for sending a button value:
/////////////////////////////////////////////////////////////////////////////
// Send a Button Value
// Path: /cs/button/state <button-number> <0 or 1>
/////////////////////////////////////////////////////////////////////////////
s32 OSC_CLIENT_SendButtonState(mios32_osc_timetag_t timetag, u32 button, u8 pressed)
{
// create the OSC packet
u8 packet[128];
u8 *end_ptr = packet;
u8 *insert_len_ptr;
end_ptr = MIOS32_OSC_PutString(end_ptr, "#bundle");
end_ptr = MIOS32_OSC_PutTimetag(end_ptr, timetag);
insert_len_ptr = end_ptr; // remember this address - we will insert the length later
end_ptr += 4;
end_ptr = MIOS32_OSC_PutString(end_ptr, "/cs/button/state");
end_ptr = MIOS32_OSC_PutString(end_ptr, ",ii");
end_ptr = MIOS32_OSC_PutInt(end_ptr, button);
end_ptr = MIOS32_OSC_PutInt(end_ptr, pressed);
// now insert the message length
MIOS32_OSC_PutWord(insert_len_ptr, (u32)(end_ptr-insert_len_ptr-4));
// send packet and exit
return OSC_SERVER_SendPacket(packet, (u32)(end_ptr-packet));
}
[/code]
On a similar way you will be able to generate messages sent by the sequencer itself.
Arduinome: you have to consider, that Monome (and derivatives) always require a PC based proxy to convert text messages into OSC datagrams. This means, that it doesn't really matter if the HW device itself sends MIDI or text messages or any other format, since a proxy has to convert them anyhow.
Therefore - so long a proxy is used anyhow - I don't really see an advantage if the HW sends text based messages instead of MIDI messages. In distance, using MIDI messages would speed up the transfers, since they are more compact (IMHO a design flaw in Monome)
For MBSEQ this means: so long it isn't a problem for you to use a proxy (like for Monome) to convert a datastream into OSC messages, you could use the common MIDI protocol, sent via USB (-\> superfast!)
This also has the advantage, that you can configure OSC messages in the proxy (very flexible, as the firmware doesn't need to be touched)
If you prefer a standalone OSC solution which works without OSC proxy, and is able to send directly to ethernet, the "true OSC" option for MBSEQ could be interesting for you which only requires a MBHP\_ETH module in addition.
Components: the old Frontpanel can be re-used. An improved (and easier to build) frontpanel is provided by Wilba. Only the core module has to be replaced by MBHP\_CORE\_STM32
A SD Card is strongly recommented (no support for BankSticks anymore)
And MBHP\_ETH is optional
The MBHP\_CORE\_STM32 PCB itself is final - SmashTV is still working on a solution for providing presoldered STM32s when shipping the kits, which saves you from soldering SMT parts
Best Regards, Thorsten.
