mbseq v4 and osc

[mirrorcrypt]

In the beginning of the midibox seq v4 features thread it mentions some things about osc. I'm wondering if osc will be a part of V4 and in what way? I'm thinking about building an 8 x 16 arduinome and I thought it might be cool to have the sequencer + arduinome in the same box. Or maybe it makes sense to build the blm matrix and use it as a replacement for the arduinome.... ?  (hoping to trigger + sequence Max/Msp + modular synth + midi gear from the midibox sequencer.)

Also, any ideas as to when V4 will be released? Are there any components I could order and put together in the meantime?

Thanks!

Dave.

[TK.]

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.

[mirrorcrypt]

Thanks TK for that very informative reply! Very helpful. I think I'll just go ahead and put together a V3 sequencer with BLM matrix and then upgrade the core once it's available.

What interested me initially about OSC was the reported "zero latency". So, the direct approach over ethernet would be my choice. It's interesting that the proxy slows the process down. I have to admit that I don't know what I need OSC for specifically but I was hoping to experiment with it in Max/Msp.... Hitting monome style buttons to trigger samples in Max/Msp with no latency was one idea.

  I was also thinking about sending OSC triggers to Max which would in turn send parameter changes to my Yamaha TG77. I wonder if sending the param changes back to the MBSEQ via osc would work well? Could I then record that information as a sequence and send it out over midi from MBSEQ to TG77? (that way it can all be stored together).

I'm also curious to know if there can be a direct osc to cv conversion possibility? Maybe could send an lfo in the computer to a modular synth for example.....

Thanks!

Dave.

[TK.]

I have to admit that I don't know what I need OSC for specifically but I was hoping to experiment with it in Max/Msp...

Max/Msp can handle MIDI messages as well. The advantage of OSC is the more comfortable and more flexible usage, but it isn't faster (in distance, it loads your PC as well as the STM32 core more than compact MIDI messages). However, STM32 is fast enough so that you won't notice a drawback on typical usecases.

I was also thinking about sending OSC triggers to Max which would in turn send parameter changes to my Yamaha TG77. I wonder if sending the param changes back to the MBSEQ via osc would work well?

Why not connecting your TG77 directly to the STM32 core? ;)

Could I then record that information as a sequence and send it out over midi from MBSEQ to TG77? (that way it can all be stored together).

You can set the program change in a mixer map, and a mixer map can be combined with patterns in "phrase mode"

An OSC method could be implemented which allows to modify the mixer map via OSC messages.

I'm also curious to know if there can be a direct osc to cv conversion possibility?

Yes, no problem - OSC path "/aout/<port>/<channel>/value"

Maybe could send an lfo in the computer to a modular synth for example.....

Yes, thats possible - I already tried this with my STM32 based OSC->CAN bridge, which acts as a proxy between Reaktor and MBSID V2. But I noticed that the CPU usage of Reaktor increases dramatically once the LFO waveform is sent with an update rate of more than 1 kHz. This wasn't an issue while sending the LFO waveform via MIDI.

The issue could somehow be related to the ethernet driver of my Mac, or to Reaktor itself. I haven't tried this under Windows yet...

Best Regards, Thorsten.

[stryd_one]

What interested me initially about OSC was the reported "zero latency"

Fairytale. Don't believe everything you read ;)