TK.
-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
It's definitely not possible to feedback the CS parameters to an external device or to LED rings, regardless if they are driven by MBSID itself or values are output via MIDI. Too much code would be required, I'm not really interested to implement this, and I'm even not sure if there would be enough code memory free for such a feature...
Best Regards, Thorsten.
-
Ok, this explains why I haven't noticed this issue yet... I will check this soon.
Best Regards, Thorsten.
-
As mentioned before, USB host mode doesn't fit into the 16k bootloader range, there is no need to try this out - it won't work.
Accordingly, code upload via USB host won't work as well.
Bootloader update application != bootloader.
So: whenever you want to upload code via MIDI, you've to connect the STM32F4 USB port directly to your PC
Best Regards, Thorsten.
P.S.: I just have improved the MIOS32_DONT_USE_USB_HOST switch, so that it excludes parts of the STM32F4 driver - bootloader should fit into memory again (with support for USB MIDI Device mode only...)
-
Before installing the PIC/ICs, while measuring voltages on the PCBs i accidently shorted pins 5V and GND (on the LCD) with one of the multimeter's test leads. The display went dark and comes back to "life" immediatly after releasing the short. Could i have damaged some kind of controller unit of the LCD?
That's very unlikely, because this caused a short circuit for the complete unit.
It's possible to damage a LCD if it's plugged in the wrong direction into the socket, but I guess that you haven't done this.
Which LCD are you using exactly?
(I remember that Wilba provided two different types)
Best Regards, Thorsten.
-
Ok, so this only doesn't work with drum tracks, but it works with common tracks, right?
Best Regards, Thorsten.
-
Compile & upload this application: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_midi_4x4%2F
Third MIDI port working? -> compare the mios32_config.h file of this application with your one.
Third MIDI port not working? -> hardware connections wrong
Best Regards, Thorsten.
-
the only problem is, that you cant use the usb-port for mios-studio anymore, because, windows cant detect it as a mios32-device, but i guess this is normal...
Yes and no.
Yes: a code upload won't be possible, because the Bootloader doesn't support USB Host (not enough memory available in the 16k boot section)
No: MIOS Studio contacts the core via SysEx messages, which should also be possible via a USB device which is connected to your PC/Mac via another MIDI interface.
I just tried following setup:
- MBHP_CORE_STM32 USB connected to a GM5x5x5
- MIDI IN1/OUT1 of the GM5x5x5 connected to MIDI OUT1/IN1 of a second GM5x5x5
- the second GM5x5x5 is connected to my Mac
After a robustness update in the MIOS32 USB MIDI Host driver a Query and terminal access are possible! :smile:
Please update your repository to get the changes
Best Regards, Thorsten.
-
I noticed that when using song/phrase mode for mutes that if you have individual drums or layers muted that they do not get unmuted when a song position unmutes an entire track. I can see the usefulness of both but in my case using song positions to reset a track its kind of cumbersome. Would it be possible to have a flag or another song position type to unmute all layers?
Ok, I will add a function which allows to disable all track and layer mutes
Something else I noticed is that the controls for VelN and VelA in the Euclidian generator do not seem to do anything. Normal and accented always get put in as their default values.They are working at my side.
Could it be that you are using a special track configuration without velocity parameter layer?
Best Regards, Thorsten.
-
Since you know how to build MIOS32 applications by yourself, it's sufficient to update the SVN snapshot :)
Best Regards, Thorsten.
-
It was an interesting experiment anyhow.
Yes, of course it works :smile:
But if the STM32F4 Discovery board is powered by the Debug USB Socket, the Micro-USB will only output ca. 4.3V which is not enough for the GM5
Solution: plug a 5V PSU to J2 of the MBHP_CORE_STM32F4 module, and let the USB PWR jumper J17 stuffed:
All 5 MIDI IOs of the GM5 are recognized, and can be used for MIDI message processing.
Best Regards, Thorsten.
-
@3: not relevant anymore, because you confirmed that the animation stops after 3 seconds... MIOS is installed
@1: the most likely reason why the LCD doesn't work
No, there is no concrete target temperature - the voltage regulators get hot, that's normal!
Best Regards, Thorsten.
-
This was a nice challenge for the weekend: I implemented a driver for USB MIDI Host mode into MIOS32 for STM32F4 :smile:
(LPC17 and STM32F103 don't support USB Host mode...)
Tested with following devices:
CME X-Key:
Waldorf Blofeld:
MIDIbox (here MIDIbox SEQ V4L):
Ploytec GM5x5x5
USB MIDI Host mode just replaces USB MIDI Device mode via the USB OTG socket.
The update will be available with all future MIOS32 applications, it's always available without special configuration.
A special USB Micro-B -> USB 2.0-A adapter is required to connect the MIDI device.
Such an adapter is for example available at Reichelt (DELOCK 83183) for 5 EUR:
http://www.reichelt.de/DELOCK-83183/3/index.html?&ACTION=3&LA=446&ARTICLE=126860&artnr=DELOCK+83183&SEARCH=DELOCK+83183
Pluck this adapter into the Micro-USB socket of the STM32F4-Discovery board, reset (or power-cycle) the core, and MIOS32 will automatically switch to USB Host mode.
Limitations:
- USB hubs are not supported, the MIDI device has to be connected directly.
- USB based Power-Supply is weak (limited to ca. 200..300 mA), which means that it might be required to power the MIDI Device with an external PSU
- the MBHP_CORE_STM32F4 module has to be powered from the USB debug socket
Please let me know if you are interested to beta-test this enhancement, I could provide a preliminary version of a MIOS32 application.
Best Regards, Thorsten -
Hi Sebastian,
filter ranges will be more time consuming than processing more than 16 MIDI router nodes.
The number could be increased in the mios32_config.h file, e.g.:
#define MIDI_ROUTER_NUM_NODES 32
this requires to recompile the application.
Do you know how to do this?
Best Regards, Thorsten.
-
And what´s about the SID control surface encoders itself?
I can´t find any Sysex or NRPN which "simulate" them.
This sounds like you are complaining me that encoders can't be "simulated" via SysEx or NRPN... :-/
It shouldn't be so difficult to add a pragmatic solution as long as it doesn't need to be documented, because I guess that you are they only guy who is interested on such a remote control...
Note that feedback won't be possible (too difficult to implement) - means: you won't be able to send the current values to MBNG, e.g. for LCD display or LED ring updates.
Best Regards, Thorsten.
-
Hi,
the LCD behaves this way if:
1) it isn't connected properly (e.g. because of bad solder joints)
2) it isn't compatible to the 4bit access mode (no problem if you got the LCD from Wilba)
3) you haven't installed MIOS yet - this has to be done before the MIDIbox SID application will be installed
If you are unsure, just install again the latest (public beta) versions which are linked here:
But you are saying that the LEDs are somehow animated - this is the normal behaviour during boot.
After ca. 3 seconds the animation will stop, right?
If it does stop: then MIOS and the application has been installed correctly - the error must be somewhere else (probably topic 1)
It's normal that the voltage regulators get hot, therefore they have a heat sink
Best Regards, Thorsten.
-
For MBNG the limit has been relaxed to 32 DINs and 32 DOUTs
Btw.: meanwhile there are also new methods which allow to connect the modules over long distances by using RS-422 like line drivers: http://www.ucapps.de/mbhp/line_drivers.pdf
Off topic: do you think that this might be a future platform for midibox?Not really, RaspPi has been made to run Linux, and no "bare metal" applications which give you direct (fast!) access to many IO pins and interfaces.
MBHP_CORE_STM32F4 is superior for MIDIfication purposes compared to such SoC architectures.
Best Regards, Thorsten.
-
Thank you! :)
Best Regards, Thorsten.
-
There is actually a very smart way: read the newbie documentation... ;-)
-> http://www.ucapps.de/mios32_bootstrap_newbies.html
Quote:
- MBHP_CORE_STM32F4 and STM32F4DISCOVERY: press and hold the blue "User" button, trigger the black "Reset" button shortly. This will restart the core and enforce bootloader mode as long as the blue "User" button is pressed.
Depending on the OS you are using at the host side (Windows, MacOS, Linux) it might be required to restart MIOS Studio in order to connect to the "safe" USB interface port.
Best Regards, Thorsten.
-
Yes, this is planned - I'm waiting for SmashTV, but he is currently extremely busy.
Best Regards, Thorsten.
-
Ah, you are using the MBHP_MF_NG module standalone (without a MIOS32 based module where MIDIbox NG could run) - in this case forget my idea.
Microcontrollers typically have an embedded flash memory. For a LPC17 or STM32F4 enough flash would be available, for the PIC we've two problems: it's much more time consuming to add code there (especially since the firmware is implemented in assembly language), and there is much less flash memory. Not enough for individual tables for all faders.
The SD Card approach would only work, if a table could be loaded into RAM, but as mentioned earlier, neither a PIC, nor a typical MIOS32 compatible microcontroller (which you are not using anyhow...) would have enough for your intentions.
How it will be complicated to add a new function in the MF tool (like a new tag or window) with a matrix or table where you can set the value for 12 point (0-5-10-15-20-25-30-40-50-60-70-inf).This would require an interpolation routine which consumes too much CPU time on a PIC, especially when multiple faders have to be handled in parallel.
In order to overcome the execution speed limitation, somebody would typically precalculate tables based on these "points" and store it in RAM... if enough would be available.
Ok, if somebody would spend some hours or (depending on his programming skills) days on this topic, he could be able to achieve this regardless of the hardware limitations.
But actually I'm not really interested on such a topic by myself, and sparetime is also not sufficiently available for such a "private" solution for you...
In other words: I'm not trying to find a perfect solution, just something which consumes as less as possible effort at my side.
Best Regards, Thorsten.
-
I created a quick&dirty documentation for the MBHP_MIDI_IO module today which also has a link to the Reichelt BOM (for Europeans who only order the PCBs): http://www.ucapps.de/mbhp_midi_io.html
Outside Europe it's better to order the kits in SmashTV's shop
Best Regards, Thorsten.
-
Great that this is finally solved :)
I already feared that something was wrong in the release process...
Btw.: is there a recording of your live show available? I'm very interested after listening to the sequences so often :thumbsup:
Best Regards, Thorsten.
-
I just got an alternative idea - we could hard-code the tables into the MIDIbox NG application.
In this case it will be programmed into flash memory.
It would still require to compile the version at your side (because you've to adapt the tables) - with the MIOS32 toolchain based on this flow: http://www.midibox.org/dokuwiki/doku.php?id=macos_mios32_toolchain_core
Currently there is around 200k free, but this would only be sufficient for 6 individual tables (mapping 14bit values)
But: if the mapping tables would only consider 10bit resolution, the memory consumption would only be 2k per table
Which means that individual tables for all faders are feasible.
I guess that you wouldn't change a difference compared to 14bit anyhow, because the PIC ADCs convert at 10bit resolution.
Best Regards, Thorsten.
-
Hi,
I think that MIDIbox NG would be the best choice for such a project: http://www.ucapps.de/midibox_ng_manual.html
The "programming" is script based (see "First Steps" in the manual) and therefore easy to adapt for your needs.
MBNG contains the same driver like MBKB -> KEYBOARD configuration, see also the kb_*.ngc examples under http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2F
Latency: then less rows are used in a matrix, then lower the latency.
MBNG supports up to 16 independent matrices, so that there is no need to create a 16x16 matrix.
Scan cycle is around 250 uS * <rows> as far as I remember
I would say, that everything which is below 1 mS can't really be recognized.
I can't answer the questions related to the SAMS hardware
Best Regards, Thorsten.
sammichSID: troubleshooting [SOLVED]
in MIDIbox SID
Posted
This LCD should work.
I would propose to install the lcd_interconnection_test, which can be downloaded from http://www.ucapps.de/mios_download.html
See the README.txt of this .zip package for test procedure details.
Note that D0..D3 won't output the voltage, because PIC18F4685 accesses the LCD in 4bit mode
Best Regards, Thorsten.