TK.

MIDIbox NG Release + Feedback

348 posts in this topic

I soo wish I was not traveling until after the New Year... This is so exciting!!

Share this post


Link to post
Share on other sites

I soo wish I was not traveling until after the New Year... This is so exciting!!

...you forgot to put the MBHP_CORE_LPC17 module into your bag (as I will do during my christmas travelings) :twitch:

I've enhanced the "First Steps" tutorial; now it also describes:

  • toggle buttons
  • buttons and LEDs in radio groups
  • encoders
  • LED Rings
  • Banks

-> http://www.ucapps.de/midibox_ng_manual_fs.html (press the "Reload" button of your webbrowser if you don't see the updates)

Pots/Faders/Motorfaders are fully supported by the firmware, but not described in the tutorial yet. Please consult the configuration examples in the cfg/test directory instead, and the .NGC spec of course!

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

I have a general Question about the planed Router and Link option of NG and MF_NG.

In the tutorial of its written that its possible to chain multiple MF_NG modules on one Core by setting the last as a end point in chain.

Will it also be possible to chain several NG with one MF_NG "slave"?

like this:

DAW_Midi_OUT ->\

LPC17_#1_Midi1_IN -> LPC17_#1_Midi2_OUT -> MF_NG_#1_Midi_IN -> MF_NG_#1_Midi_OUT -> LPC17_#1_Midi2_IN -> LPC17_#1_Midi1_OUT -->\

LPC17_#2_Midi1_IN -> LPC17_#2_Midi2_OUT -> MF_NG_#2_Midi_IN -> MF_NG_#2_Midi_OUT -> LPC17_#2_Midi2_IN -> LPC17_#2_Midi1_OUT -->\

LPC17_#3_Midi1_IN -> LPC17_#3_Midi2_OUT -> MF_NG_#3_Midi_IN -> MF_NG_#3_Midi_OUT -> LPC17_#3_Midi2_IN -> LPC17_#3_Midi1_OUT -->\

LPC17_#4_Midi1_IN -> LPC17_#4_Midi2_OUT -> MF_NG_#4_Midi_IN -> MF_NG_#4_Midi_OUT -> LPC17_#4_Midi2_IN -> LPC17_#2_Midi1_OUT -->\

DAW_Midi_IN.

I wold like to get more displays and a flexible 8 fader module design...

can't test it because i don't have the multiple LPC17s jet..

best regards

novski

Share this post


Link to post
Share on other sites

I have a general Question about the planed Router and Link option of NG and MF_NG.

This option is already implemented and working! :)

A simple configuration example can be found here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_cc.ngc

And a more complex example where motorfaders are sending Pitchbend instead of CC here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Flogictrl.ngc

In the tutorial of its written that its possible to chain multiple MF_NG modules on one Core by setting the last as a end point in chain.

Will it also be possible to chain several NG with one MF_NG "slave"?

like this:

DAW_Midi_OUT ->\

LPC17_#1_Midi1_IN -> LPC17_#1_Midi2_OUT -> MF_NG_#1_Midi_IN -> MF_NG_#1_Midi_OUT -> LPC17_#1_Midi2_IN -> LPC17_#1_Midi1_OUT -->\

LPC17_#2_Midi1_IN -> LPC17_#2_Midi2_OUT -> MF_NG_#2_Midi_IN -> MF_NG_#2_Midi_OUT -> LPC17_#2_Midi2_IN -> LPC17_#2_Midi1_OUT -->\

LPC17_#3_Midi1_IN -> LPC17_#3_Midi2_OUT -> MF_NG_#3_Midi_IN -> MF_NG_#3_Midi_OUT -> LPC17_#3_Midi2_IN -> LPC17_#3_Midi1_OUT -->\

LPC17_#4_Midi1_IN -> LPC17_#4_Midi2_OUT -> MF_NG_#4_Midi_IN -> MF_NG_#4_Midi_OUT -> LPC17_#4_Midi2_IN -> LPC17_#2_Midi1_OUT -->\

DAW_Midi_IN.

Such a configuration is already possible (in theory), but to be honest: it doesn't make much sense!

You are adding unnecessary latencies between the host and core modules, and between MF_NG and the core module which controls the faders.

It will also much more difficult for you to debug the core modules, e.g. to upload new configuration files, when you don't have a direct USB connection between host and core.

Isn't your DAW able to handle multiple USB MIDI ports?

If not: you could merge the USB MIDI ports at the host side, and route them to a virtual bus.

Under MacOS I recommend the MIDI Patchbay which is simple to use, and very robust (I'm using it in very exotic setups ;-))

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Well thats exact the problem of my software. Its not possible to connect more than one midi in and out.

Is there a other possability to connect a Display for each fader then with one LPC17 Core for 8 displays?

Wold you sugest to rather connect al 4 fader modules to the first core and chain 3 more cores just for the displays?

Best regards

Novski

Share this post


Link to post
Share on other sites

Somehow I've the feeling that you don't listen to my proposals... I don't know, why you still want to chain LPC17 modules if there are more elegant solutions available which will lead to a faster and easier handling!

Let's focus separate USB-MIDI connections, bundled to a single MIDI interface on your host.

Meanwhile I guess that you are not a MacOS user, so here is the solution for Windows:

- use a virtual MIDI cable, such as this one: http://www.tobias-erichsen.de/software/loopmidi.html

- use a patchbay, such as this one: http://www.hermannseib.com/miditrix.htm

After the installation of the virtual cable, you've a MIDI IN/OUT connection for your DAW.

Connect the LPC17 modules, thereafter start MIDItrix

Now just interconnect all MIDI OUTs of the LPC17 cores to the MIDI IN of the virtual cable

And all MIDI INs of the LPC17 cores to the MIDI OUT of the virtual cable

-> done

I fear that if you don't go this route, you will be lost in an overcomplicated setup, and you will be unable to debug it if you don't know the technical backgrounds.

Such a simplified setup also means, that you could use a dedicated LPC17 core per MF module + 8 LCDs

The performance will be excellent due to the dedicated USB MIDI connections to your PC (you can bundle them with a USB hub of your PC hasn't enough USB ports)

Where do you not agree with such a solution?

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Now I have a display! Nice toy ;)

I also tried the different encoder-modes again. There is no difference between non_denteded, detended1 and detended2. At detended3 the enc just sends one single value.

Without fastmode I need five and a half rotations to get from 0 to 127....thats hard ;)

The "fastbutton"-method is good working but I don't want to press the button everytime I use the encoder. It would be better, to have a "slow down" button. Is there a way to fasten them up in general and to slow them down with the button?

Edited by FantomXR

Share this post


Link to post
Share on other sites

I could allow to set the default fast mode directly with the ENC command... but I think that there is actually a different problem which has to be determined first before doing such countermeasures (which are only compromises)

Which encoder are you using exactly - did you buy it from Reichelt? Resp. do you have a datasheet?

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Its from eBay. I will send you the link in a minute.

The seller says, it's alps EC11.

Share this post


Link to post
Share on other sites

EC11 encoders send only 15 ticks per rotation - thats the problem.

However, in V1.003 I made the acceleration mode (provided by MIOS32) configurable.

Previously we only had the Auto mode, which selected the acceleration depending on the value range...


MIDIbox NG V1.003
~~~~~~~~~~~~~~~~~

o added "enc_speed_mode" parameter to EVENT_ENC
Valid modes are Auto (speed automatically adapted according to the value range),
Slow:0 .. Slow:7 (divides the increments),
Normal (no special measure) and
Fast:0 .. Fast:7 (accelerates the increments)
A configuration example can be found under cfg/tests/encspeed.ngc
[/code] Direct link to configuration example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencspeed.ngc It allows to test all available modes if 16 encoders are connected. If you've less encoders, just copy&paste at least the Fast:* examples into your .NGC file. There isn't much more that I can do at the software side. :-/ /Edit: meanwhile we've V1.004:
[code]
MIDIbox NG V1.004
~~~~~~~~~~~~~~~~~

o some minor code cleanup

Ok, during the cleanup I found out, that incoming MIDI events to AINSER parameters were not correctly forwarded... ;)

This is fixed in V1.004 - probably the last release before christmas.

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

HI TK.

There is no point i don't agree with your proposals. I didn't think about latencies yet.

I don't have permission to Install any software on the Audio console. {For understanding of the host software:

Its a 72 stereo channel real time mixer. It has 2ms latency from audio input to output. All running on a WinXP OS. Thanks to the Assembly language programed Audio processing, its really possible to even make in-ear monitoring for acts on stage with so low latencies.}

Thats why my thought are always going back towards a independent working midi controller.

Do you think it cold be possible to enhance latencies with a connection over the CAN bus with MBNet?

Merry christmas!

best regards

novski

Share this post


Link to post
Share on other sites

Why is the midibox limited to eight displays? I would love to have a ninth :)

Share this post


Link to post
Share on other sites
Thats why my thought are always going back towards a independent working midi controller.

Ok, understood.

 

 

Do you think it cold be possible to enhance latencies with a connection over the CAN bus with MBNet?

Yes, the usage of CAN would simplify the wiring, and it would allow to communicate between the cores with reduced latency. But the integration of MBNet into the application is a low-prio task for me. It will require intensive testing at my side, and currently you are the only guy who would really use this approach due to the restrictions of your DAW.

Therefore I'm thinking about a solution which already exists, and still would be sufficient for your usecase.

The "MIDIbox Link" approach was the best solution for PIC based cores, which had only 1 MIDI IN and OUT -> chaining the cores, and tunneling MIDI events from forwarding points to the endpoint was the only solution for a bidirectional communication.

LPC17 has 4 MIDI IN and OUT ports, this allows a better strategy for such a purpose, which still has acceptable latencies.

And here it is:

multicore_interconnections.png

Under the assumption that:

 

 

 

  • we need a fast communication path between the first core (connected to the host via USB) and the other cores, MIDI OUT3 of the first core sends the same data to all MIDI IN3 of the remaining cores. The selection of MIDI events has to be done with the channel number in this case (e.g. Core1 only listens to channel 1, Core2 to channel 2, etc...)

    The latency would be 1 mS per MIDI event to Core2/3/4 (*)

  • the backpath to the host would mainly transmit MIDI events generated from motorfader or button movements. Latency doesn't really matter here, and we also don't have to expect so much MIDI traffic. Therefore for such a path we could use a chained arrangement. In the example above I chained MIDI IN4/OUT4 of the cores (*)
  • the MBHP_MF_NG modules would have to be connected to MIDI IN2/OUT2 (not shown in this picture) via the normal MIDI interface. In theory you could connect them at TTL level as well, like the core-to-core interconnections), but the advantage of the optocouplers would be the galvanic isolation, e.g. between the PSU you are using for the motorfaders, and the LPC17 core supply which could come from the USB port. This would avoid the danger for jittering values at high resolution, and it would avoid ground loops.
  • (*) in theory we could even increase the baudrate of the MIDI3/4 interfaces, e.g. 10 times faster -> 100 uS per event... or even faster. In this case we would reach the same performance like the CAN based solution!
The attractive point on this solution is, that it doesn't require firmware enhancements. The MBNG application already gives you all functions to realize such a routing! smile.gif

 

 

 

Why is the midibox limited to eight displays? I would love to have a ninth smile.gif

I've prepared MBNG for 255 LCDs - but the electrical connections will be a challenge, because you won't be able to connect them in parallel without decoupling and "amplifying" the signals. Also the selection lines would have to be multiplexed - somehow - this will be difficult to handle.

The RAM for the LCDs is limited to 512 characters (/edit: for CLCDs 1024 characters), which means that 64 2x16 LCDs could be handled, or 32 2x16 LCDs, or 25 2x20 LCDs, or 12 2x40 LCDs (I don't want to count the GLCD combinations ;-))

The LCD size configuration isn't implemented yet - and currently it's especially only possible to use 2 (G)LCDs with up to 64x4 characters. I will work on a more flexible configuration next year.

The electrical part will be a challenge - it will probably require dedicated solutions depending on the LCD types being used.

So: only recommended for experts who know how to develop the appr. circuits, and would directly implement & test the LCD driver by themself.

 

/edit: discussion about displays will be continued here: 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

@TK: Thanks for thinking about a problem of mine! Sounds great. Enjoy Holidays!

Share this post


Link to post
Share on other sites

Hey,

I finally found time to play around with MB_NG tonight and I must say I'm amazed! So simple and yet so powerful. I love the new conditional labels. Great stuff!

So far everything is working fine here: LPC17 + LCD 16x2 + DIN2x + AINSer8 (breadboard)

I guess I have to upgrade my other MB64e soon...

A couple of questions:

1. I'm thinking of upgrading my "midiboxed" Tascam controller which uses the MAX7221. Will this chip ever be supported by MIOS32 / MB_NG? I'm pretty sure the answer is no, but I'd better ask before planning something else. (a simple solution would be to leave a Pic8 core in there just for the LEDs/MAX7221 and connect that to the LPC17. I just hope there is enough space in the case..)

2. Is port J10 reserved exclusively for the SCS, or could this be made available for "normal" buttons, encoders... too? Could be useful for someone (like me;) who only needs a few control elements. Would save a DIN module.

Cheers,

and Merry Christmas to everybody

Lars

Share this post


Link to post
Share on other sites

Thanks for the nice feedback! :)

Yes, I can support the MAX7221 - now where we've generic configuration commands, it isn't a big problem for me to change the purpose of a DOUT_MATRIX by providing additional parameters.

I will try this before New Year.

J10: yes, will be possible as well. J10 needs a configuration command anyhow, e.g. if it should be used for additional chip select outputs for the LCDs

Best Regards (& Merry Christmas), Thorsten.

Share this post


Link to post
Share on other sites

This is great news indeedflowers.png

I was thinking of hacking in support for the MAX695* series of ICs, so that they could take care of a time-code display with 14- or 16-segment LEDs as well as some debounced button scan, but those functions could be made with a PIC as welllogik.png Or the ICM7243.

Decisions decisions...

Merry Christmas!

Edited by jojjelito

Share this post


Link to post
Share on other sites

Yes, I can support the MAX7221 - now where we've generic configuration commands, it isn't a big problem for me to change the purpose of a DOUT_MATRIX by providing additional parameters.

That sounds like "Stribe" to me - I still need to rebuild mine, there is something severely wrong with my 8bit core built. TK, do you still have yours?

Share this post


Link to post
Share on other sites

That sounds like "Stribe" to me - I still need to rebuild mine, there is something severely wrong with my 8bit core built. TK, do you still have yours?

Exactly - I will test this on my Stribe (and I can post a schematic once the DOUT_MATRIX driver has been enhanced :))

Btw.: the DIN/DOUT_MATRIX should already work with your "MBSEQ 16x4 BLM board", because it supports rows=4 mode

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Btw.: the DIN/DOUT_MATRIX should already work with your "MBSEQ 16x4 BLM board", because it supports rows=4 mode

Great news! 2013 will be exciting :frantics:

Share this post


Link to post
Share on other sites

Ahh, I knew I regret not having taken your BLM board someday...

Share this post


Link to post
Share on other sites

Exactly - I will test this on my Stribe (and I can post a schematic once the DOUT_MATRIX driver has been enhanced :))

Btw.: the DIN/DOUT_MATRIX should already work with your "MBSEQ 16x4 BLM board", because it supports rows=4 mode

Best Regards, Thorsten.

I'm looking forward to see the schematic ;)

Stribe is still a nice project!!

Share this post


Link to post
Share on other sites

V1.005 comes with some nice goodies:

 

MIDIbox NG V1.005
~~~~~~~~~~~~~~~~~

   o support for value MAPs.
     Various examples can be found under cfg/test/map*.ngc

   o support for EVENT_CV
     Various examples can be found under cfg/test/cv*.ngc

   o AINSER modules now disabled after RESET_HW
     They have to be explicitely enabled with the AINSER command

   o the AINSER command now supports the "resolution" and "num_pins" parameters

 

 

All new options are documented under http://www.ucapps.de/midibox_ng_manual_ngc.html

 

Best Regards, Thorsten.

 

Share this post


Link to post
Share on other sites

A new version is available:

 

MIDIbox NG V1.006
~~~~~~~~~~~~~~~~~

   o corrected LED pattern output for the case that the selection lines are inverted.

   o the new SCS command allows to assign emulated button/encoder functions if the SCS
     shows the mainpage.
     A usage example can be found under cfg/templates/lre8x2.ngc

 

I also started to document the Standard Control Surface here:

http://www.ucapps.de/midibox_ng_manual_scs.html

 

Best Regards, Thorsten.
 

Share this post


Link to post
Share on other sites

Based on the discussions in http://midibox.org/forums/topic/17542-bank-selection/'>this thread I changed the way how banks are handled in V1.007:

 

MIDIbox NG V1.007
~~~~~~~~~~~~~~~~~

   o changed bank concept: the BANK command has been removed, instead the EVENT
     command got a new "hw_id" and "bank" parameter.
     A simple configuration example can be found under cfg/tests/encbanks.ngc
     More complex configuration examples under cfg/tests/bnk*.ngc

   o added meta=CycleBank (increments bank, resets to 1 if last bank reached)

   o additional new metas: SetBankOfHwId, DecBankOfHwId, IncBankOfHwId, CycleBankOfHwId

 

The new handling with "hw_id" and "bank" is now also described in the User Manual: http://www.ucapps.de/midibox_ng_manual_ngc.html

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now