I’m thinking of building a MIDIbox LC but it seems that I can’t use the new STM32 module and would need to use the old PIC module.
Am I write and if so is it likely that LC will be ported to the STM32 as It seems to allow for a much more extensive build
Yes, I’m planning to do this.
The MBHP_CORE_STM32 module is already built into my MBLC, but it can take some weeks until I will find the time to port the PIC based firmware to MIOS32
Best Regards, Thorsten.
What would be the advantage of LC on the new core?
USB for more than 100 times faster transfers
the capability to drive any graphical LCD type (even the cheap ones) without performance impact
possibility to communicate via ethernet by using OSC messages (not related to LC protocol, but a nice option)
Best Regards, Thorsten.
USB for more than 100 times faster transfers
the capability to drive any graphical LCD type (even the cheap ones) without performance impact
possibility to communicate via ethernet by using OSC messages (not related to LC protocol, but a nice option)
Best Regards, Thorsten.
EXACTLY what I’m looking for - COOL! 
sounds good! Nice!
will it possible to use two 2x24 LCD Displays?
tk
will the core 32 mblc be able to handle more than 8 motor faders, without using another core32?
The current version of MBLC V2 (CORE32 Version) supports a maximum of 8 motorfaders. This is hard-coded in lc_mf.c.
The CORE32 supports up to 16 motor faders. From mios32_mf.h:
// number of motorfaders (0-16)
#ifndef MIOS32_MF_NUM
#define MIOS32_MF_NUM 0
#endif
Looking at the code, other than possibly rearranging the LCD display, I think it would be trivial to adapt mblc_v2 to support more motorfaders… Take a look at: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_lc_v2%2F
Cheers
Phil
thanks phil im just getting to grips with meta events again almost got them down, as soon as i have finished with them i will take a look at this lot, i need to brush up my “c” anyway. im going to make a little desk sort of a mackie d8b variant, i have already done the casework in solidworks chosen the buttons , encoders, knobs etc im just deciding on faders at the moment if i want touch or not.
being able to use 16 motor faders will be great, it means i can get some core 32’s in with my next order with smashtv
thanks i will keep an eye on things as they progress.
The OSC via Ethernet feature is ready in the STM32 core?
Protools can read/send OSC protocol?
Thanks!
Best Regards.
Fernando
The OSC via Ethernet feature is ready in the STM32 core?
I assume that is a question 
OSC is working with the STM32, there is a sample application that works as a simple OSC client/server but it doesn’t really do anything useful. None of the ‘proper’ apps currently support OSC (yet!) It would be (fairly) easy to add OSC support to the new Midibox LC though.
Protools can read/send OSC protocol?
Sorry I don’t know, I don’t use ProTools.
Cheers
Phil
Protools can read/send OSC protocol?
A quick google search leads me to believe that Protools can’t speak OSC. You’ll have to use another program, like Max or PureData to translate from OSC to Midi.
As TK said above, the OSC feature wouldn’t be related to the LC/Mackie protocol. In my understanding this means, any host application just doesn’t expect a LC to communicate via OSC because the “real” LC and all commercial clones are purely MIDI, only you might integrate an OSC-based section to the same box that sends stuff via OSC in addition (i.e. to some other app).
The other question is, what would it be good for to run the central LC functionality itself via OSC? TK ran a few performance tests some time ago (can’t find the thread right now) showing that USB MIDI is at least as good as OSC, sometimes better (regarding latency). Remember, it’s “only” 10 MBit Ethernet, connected via a serial interface and having considerable (IP etc) protocol overhead. If you even need to use an external MAX app to convert it back to MIDI, this can’t ever have any advantage compared to the standard solution.
And I didn’t ever read someone complaining about the bad usability or latency of the MIOS8/MIDI based MBLC. This is still a HUI controller where the human is mostly the limiting performance factor. As soon as the MIOS32 LC app is finished, I could imagine that it supports 16 faders and simulates two Midi interfaces towards the application, this might be a real advantage, but other than that, what are you trying to achieve?
S
a little OT, but…
OSC, Is it going to be coded into the MIOS32 so any app can run it easily, ie easy to modify an app that outputs midi to output OSC?
will you be able to take the 10bit readings out of the Core and transmit over OSC?
cheers.
MIOS32 already has all of the code required to use OSC but it will always take some coding to make use of it. I guess that TK will add OSC support to most of the “standard” MIDIbox apps where it makes sense to add it.
will you be able to take the 10bit readings out of the Core and transmit over OSC?
Of course, the issue is related to implementation, there still isn’t really a “standard” for OSC so it really depends on what your client expects to receive.
Here is “one implementation” (from the OSC example app) which sends a pot value as an OSC “bundle”. MIOS32 already has all of the functions required to “build” the packet.
s32 OSC_CLIENT_SendPotValue(mios32_osc_timetag_t timetag, u32 pot, float value)
{
// 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/pot/value");
end_ptr = MIOS32_OSC_PutString(end_ptr, ",if");
end_ptr = MIOS32_OSC_PutInt(end_ptr, pot);
end_ptr = MIOS32_OSC_PutFloat(end_ptr, value);
// 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));
}
Cheers
Phil