155 replies to this topic

[TK.]

In the last days I worked on a major MBHP_MF update, mainly triggered by Screaming Rabbit who gave me a big package of different Alps faders for free!

Design Targets:

• find a solution to handle high-quality faders like Alps K faders with "coreless" motors
  
• find a solution for MBHP_CORE_LPC17 which doesn't deliver stable enough ADC conversion results due to the reduced 3.3V voltage range
  
• find a solution for MBHP_CORE_LPC17 which cannot handle touch sensors properly without heavy CPU load (resp. without an additional external device or microcontroller)
  
• find a solution which is compatible with PIC based projects for best usability
  
• find a solution which is DIY friendly and doesn't require additional gear (e.g. chip programmer) for something which isn't part of the MBHP yet
  
• find a solution which can be easily tested and troubleshooted (no need to learn new processes)

Following circuit is the result: http://www.ucapps.de.../mbhp_mf_ng.pdf

• a dedicated PIC controller controls the motorfaders directly
  
• it can be accessed via MIDI (only) - this allows standalone usage, cascading (to chain multiple modules), and the re-use of existing infrastructure such as MIOS, MIOS Studio and MIOS Bootloader
  
• the module can either be connected to a PC directly, or controlled from a second PIC or STM32 or LPC17 (note that MBHP_CORE_LPC17 has a third and even a fourth MIDI IO port at TTL level so that the available two MIDI IO pairs are still free)
  
• native support of various protocols (e.g. PitchBender, CCs, even Logic Control and Mackie Control Emulation)
  
• support for 8 touch sensors
  
• instead of TC4427 I'm using L293D now - not at least because of the integrated diodes.
  
• due to the direct motor control connections, the PIC is now able to generate PWM with 50 uS steps for improved motor speed control while a motor is moved
  
• since the firmware is dedicated for this task, there was enough memory free to integrate advanced features, such as runtime-calibration and motor position tracing

Two snapshots of the prototype - currently I've only tested the circuit with high-quality K Faders, which were not properly controllable with MBHP_MF_V1



Meanwhile PCBs are available (layout created by SmashTV - thank you!!! )


MIOS Studio got a new configuration tool:


Especially the calibration is much easier now, not at least because of the new motor position tracing feature:



Currently following modes are planned:

• PitchBender Chn#1..#8
  
• PitchBender Chn#9..#16
  
• CC#07 Chn#1..#8
  
• CC#07 Chn#9..#16
  
• CC#16..#23 Chn#1
  
• CC#24..#31 Chn#1
  
• Faked Logic Control
  
• Faked Logic Control Extension
  
• Faked Mackie Control
  
• Faked Mackie Control Extension

There is no real need to add more modes, considered that MIDI events can be mapped on the host PC and/or from another microcontroller (like Core32) which uses MBHP_MF_V3 as a companion.
By using Pitchbender events, the highest resolution (10bit) is available.

More about this topic (e.g. test of different motorfaders) after holidays.

Best Regards, Thorsten.

[Hawkeye]

That looks very, very nice

[phunk]

yeah!

[findbuddha]

TK, I've got some Core8 and MF PCBs that were to be used for this purpose.
Can I solder the Core8 board as usual?
Should it be possible to fit the new circuit into the old MF PCB?

Thanks

[TK.]

When you compare the MBHP_MF_V2 schematic with MBHP_MF, you will notice that the motor control pins are now directly connected to the PIC.
The same can be done with the old module - just remove the two 74HC595 chips and use a 16-wire ribbon cable for direct connections between MBHP_CORE and the TC4427 based H-bridges.

You should also add the status LED, and a 470 Ohm resistor between the MF potentiometer (P1) and ground for improved voltage control.

Note that the MBHP_MF_V2 firmware hasn't been released yet, it needs some more work until it will run perfectly. If nothing unexpected happens I will release it in ca. 2..3 weeks

Best Regards, Thorsten.

[Skunk]

Hi Thorsten,

what about the noise of the motors during movement, the accuracy and the speed? Same as before?

Cheers,
Andreas

[TK.]

I haven't compared this with my RSAON11M9 faders yet, but I've the impression that the new method leads to better results, not at least because the increased PWM resolution allows more exact control over the speed so that probably *any* fader will reach the target position w/o overshoots.
The "sine" function of the MBFM tool moves all faders concurrently with slow target position changes -> this is the noise test -> this allows to optimize parameters for less noise.

Can't say more about this topic yet - after this posting I stopped the development, and I will continue in some days.
Thereafter more details.

Best Regards, Thorsten.

[Axel]

Hi Thorsten,

haven´t been around here for some ...eh.. years, mainly because my LC emulations are still working nearly perfectly and do what they are supposed to do (help making music?!).

Once in a while i have problems with some faders moving slowly or not completely reliable, so this new development could reanimate my former Midiboxeritis. To avoid sleepless nights thinking about it, i have a quick questions right now:

Is it necessary to use the new STM32 Core to provide the Midi I/O for the new MF Core?

Best regards,
Axel

[TK.]

Hi Axel,

welcome back!

By enabling the MIDI merger it will be possible to chain MBHP_MF_V3 with a common core module.
The "Faked Logic/Mackie Control" Mode will handle the Pitch Bender Events.
So: a Core32 won't be required, you can re-use your existing hardware and just only have to replace the MBHP_MF_V1 module.

Best Regards, Thorsten.

[Lorcan]

Very impressive ! The pcb layout looks very tidy, even in prototype form.
It's great that you still invest your time in this project. Apart from Tango (very expensive) and Euphonix Studio (not too sturdy looking and Mac only) controllers, there hasn't been much innovation on the commercial side, so I guess this is even a bigger incentive to build one yourself.


Out of curiosity, may I ask what type of algorithm you use for tracking and control of the fader ?
I guess you use of some kind of regularization of the control curve, or movement / speed prediction, so the motor speed is as smooth as possible.
I know very little about automation theory (more about dsp) but as I said, I'm curious

Cheers,
Lorcan

[TK.]

Basically I'm using the same algorithm that I described under http://www.ucapps.de/mbhp_mf.html

The biggest differences compared to the previous solution:

• Duty cycle has much higher resolution for more precise motor speed control
  
• Duty cycle depends on distance between current and target position -> than closer the target position, than slower the motor
  
• separate values for upward/downward movements, now for each motorfader individually. This is important to ensure that even after years all motors are running synchronously, because some get a bit slower, some others are still fast (the same problem which probably Alex noticed)

Following picture shows how precisely a fader can be positioned now


This is a ALPS RSAON11M9 fader at 5V.
It overshoots the target position at t=100 mS, but can be precisely repositioned at t=180 mS to exactly the middle value (512)
Such a control wasn't possible with the old solution.

For those who prefer slow faders: just reduce the Max Duty Value


Best Regards, Thorsten.

[Hawkeye]

looks very nice, especially the time-graphs!
/got to stop reading this thread, says my wallet.

Edited by Hawkeye, 09 January 2011 - 03:17.

[Casey_Pittman]

Greetings! I've been doing a lot of reading about the midibox project and I think I'm about ready to take some steps. I'm particularly interested in this new MF V3 board. Any further progress made as of yet?

-Casey

[TK.]

I haven't continued yet as this is a low-prio project for me.

My Core32 based MBLC is already stuffed with a module, communication goes through a STM32 module via USB to Logic Pro - it works perfectly.
I built a second module for testing different faders, but haven't found the time yet to run the tests and to find + document the best calibration values.

Also a PCB layout is not available yet...

However, if anybody wants to build this on a veroboard: just do it!
The schematic is final, the firmware is released in the repository and I can send you an MIOS Studio update for calibration (or you can compile it by yourself).

Best Regards, Thorsten.

[findbuddha]

(or you can compile it by yourself).

Anyone know how to compile MIOS Studio on windows?

Using JUCE 1.52, VC++ Express 2010, I get this sort of fail:

1>------ Build started: Project: mios_studio, Configuration: Release Win32 ------
1>  MbCvTool.cpp
1>..\..\src\gui\MbCvTool.cpp(94): warning C4244: 'argument' :  conversion from 'juce::juce_wchar' to 'unsigned char', possible loss of  data
1>..\..\src\gui\MbCvTool.cpp(145): error C2440: 'initializing' :  cannot convert from 'juce::TableHeaderComponent' to  'juce::TableHeaderComponent *'
1>      	No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\MbCvTool.cpp(741): warning C4244: 'argument' :  conversion from 'juce::int64' to 'size_t', possible loss of data
1>..\..\src\gui\MbCvTool.cpp(742): warning C4244: 'argument' : conversion from 'juce::int64' to 'int', possible loss of data
1>..\..\src\gui\MbCvTool.cpp(751): warning C4244: 'argument' :  conversion from 'juce::int64' to 'const juce::uint32', possible loss of  data
1>  Midio128Tool.cpp
1>..\..\src\gui\Midio128Tool.cpp(145): warning C4244: 'initializing' :  conversion from 'double' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(150): warning C4244: 'initializing' :  conversion from 'double' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(211): error C2440: 'initializing' :  cannot convert from 'juce::TableHeaderComponent' to  'juce::TableHeaderComponent *'
1>      	No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\Midio128Tool.cpp(412): error C2440: 'initializing' :  cannot convert from 'juce::TableHeaderComponent' to  'juce::TableHeaderComponent *'
1>      	No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\Midio128Tool.cpp(975): warning C4244: 'argument' :  conversion from 'juce::int64' to 'size_t', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(976): warning C4244: 'argument' :  conversion from 'juce::int64' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(985): warning C4244: 'argument' :  conversion from 'juce::int64' to 'const juce::uint32', possible loss of  data
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

JUCE and the JUCE example progs build successfully

[philetaylor]

Hi.

I haven't build the latest SVN for Windows for a while (I usually only build it when TK wants to release a new version). Those errors are all in the latest additions and usually just require specific casting of the variables as GCC is a bit more tolerant than VC++

I will try and build it tomorrow and update SVN.

Cheers

Phil

[philetaylor]

If you update your SVN repository, you should see a new build directory for VS2010 which will hopefully work for you!

Cheers

Phil

[findbuddha]

Thanks.

The warnings are gone, but I still get the errors about TableHeaderComponent

[philetaylor]

Try Juce 1.50 (as that is the recommended version). Juce seems to change prototypes between versions so it is likely that the definition for TableHeaderComponent has changed!

Cheers

Phil

Edited by philetaylor, 15 February 2011 - 09:09.

[TK.]

Meanwhile it's Juce 1.51

Once I update to a new version and change the source codes accordingly, previous Juce releases won't work anymore.

Best Regards, Thorsten.