-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
Thorsten, würdest du das grundsätzlich empfehlen um möglichen Fehlerquellen gleich vorzubeugen oder nur unter gewissen Umständen? Falls ersteres wäre es toll, wenn man das in den anderen Schaltplänen auch sehen würde :smile:
Du solltest vielleicht erwaehnen, auf welchen Schaltplan Du Dich beziehst (jedenfalls nicht auf den neuen Schaltplan)
Man benoetigt die RCs, wenn die LEDs anfangen wild zu flackern. Das wird bei einer sauberen Verdrahtung mit den neueren MBHP_* PCBs nicht passieren.
Bei den alten PCB Layouts war das noch ein Problem, weil die Module bspw. nicht ueber Flachbandkabel verbunden wurden. Auch wer das Frontpanel komplett auf Lochraster aufbaut, und dabei auch noch die DIN/DOUT Shiftregister wild vermischt, laeuft Gefahr, dass die SR Signale nicht mehr sauber uebertragen werden.
Siehe auch
Das Problem ist also eigentlich mit den neuen PCBs von SmashTV seit einigen Jahren geloest, ich lasse jedoch den Hinweis im MBSEQ Schaltplan, und werde ihn in keine anderen Schaltplaene uebertragen, weil er in den meisten Faellen nicht relevant ist.
Gruss, Thorsten.
-
- Ist das: http://www.ucapps.de...bseq_v4_din.pdf
noch die Taster/Encoder-Belegung in der normalen Seq 4-Software?
- Und verstehe ich das richtig, dass ich dafür 3 DIN R5 brauche?
Ja, an der Standard-Belegung hat sich in den letzten 10 Jahren nichts geaendert (ansonsten wuerden mir einige User aufs Dach steigen! ;-)
Ich habe das HW Manual (-> http://www.ucapps.de/midibox_seq_manual_hw.html) jedoch gerade um ein neues Kapitel ueber das "Reduced DIN/DOUT" Kapitel erweitert, in dem die spezielle Verdrahtung von Wilba's Frontpanel PCB erklaert wird.
Siehe auch http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf
Hierfuer wuerde man also nur ein MBHP_DIO_MATRIX und ein MBHP_DINX4 (und kein MBHP_DOUTX4) Modul benoetigen.
Wird der dritte DIN R5 wie hier der zweite an den ersten "in Reihe" angeschlossen?wenn man es benoetigt: ja
- Ich möchte 16 Taster einbauen, um im Pattern-Modus die einzelnen Spuren schneller selektieren zu können.
(Statt Track Group + Track)
Es gibt nur 4 Pattern - fuer jede Gruppe (bestehend aus 4 Tracks) eins.
Diese kann man auf der PATTERN Seite sehr schnell mit den GP Buttons anwaehlen, die Gruppe waehlt man mit den Group-Tastern aus
- Wenn das geht, kann ich diese 16 Taster auch zum Muten benutzen?
(Im Patte
rn-Modus "Mute" + Taste mutet, nach Loslassen der Mute-Taste sofort wieder im Pattern-Modus)
Die 16 Buttons sind ja nicht zum Pattern-Switching geeignet.
Doch Du kannst sie zum Muten verwenden.
Dazu legst Du sie auf die Bookmark-Funktion (BUTTON_DIRECT_BOOKMARK1 .. BUTTON_DIRECT_BOOKMARK16), und schreibst in das Bookmark-File, welcher Track ueber den jeweiligen Button gemuted werden soll.
(Der Begriff "Bookmark" koennte hier etwas verwirrend sein, doch dahinter steckt eine maechtige Funktion, mit der man noch viel mehr machen kann also nur Tracks zu muten ;-)
Gruss, Thorsten.
- Ist das: http://www.ucapps.de...bseq_v4_din.pdf
-
Hi Tim,
the firmware doesn't allow to enter notes exactly the way you want.
You could play the notes in the Live page with the 16 GP buttons (they can be optionally forced to the selected scale) - but I know that this is no perfect replacement for your request - but it's currently the only possibility.
Best Regards, Thorsten.
-
Did you ever connect the LCD wrongly, e.g. with some cables swapped?
This could damage the LCD, with the result that it can't be initialized. Possible effects: sometimes you will only see a black bar at the upper line, or you won't see any pixel at all.
If you are sure that the LCD was never connected the wrong way, then it makes sense to doublecheck the connections between microcontroller, the 74HC595 SR and the LCD by comparing the signals at the source/destination with the two probes of your scope.
If this still doesn't help, then I can only recommend to try another LCD
(I'm not writing a different LCD type, Displaytech 162A works fine at my side)
Best Regards, Thorsten.
-
I'm lost, please help me!
I'm unsure if we are speaking about the same behaviour, resp. if you've misinterpreted a change in the firmware and therefore come to this conclusion, or if we are talking about an actual issue (which is unknown to me).
I changed the behaviour of the status LED with V3.019 - if you've used an older version before, the LED was dimmed (not so bright like with newer versions), and not fading/cycling.
Best Regards, Thorsten.
-
Ja, entweder DIN Sync oder (zusammen mit dem BLM Port) MIDI IN3/OUT3 option fuer das LPC17 Modul.
Gruss, Thorsten.
-
:phone:
Best Regards, Thorsten.
-
It works like intended.
The flashing LED with PWM modulated fading effect is a sign of life (application still running)
Best Regards, Thorsten.
-
Looks good!
So, it seems that the configuration isn't the problem, MIOS32 tries to initialize the LCD
Best Regards, Thorsten.
-
I fear that it isn't working anymore, StrydOne started with this but he left the forum long time ago.
Best Regards, Thorsten.
-
"=!" isn't a valid C operator, try "!="
Best Regards, Thorsten.
-
Hi Matteo,
yes, this is possible! :)
Just push the CC button so that MIDI events will be sent by MBSID, and can be recorded by your DAW
Best Regards, Thorsten.
-
1 - Is the setup for buttons correct with differents ports routing ?
yes, it should work this way
2 - What's the setup for the ledrings (to assignate the rings for each 24 channels) ?you've to define the "EVENT_LED_MATRIX id= 1 type=CC chn= 1 cc=0x30 led_matrix_pattern=LcAuto" events three times, each one has to listen to another USB port.
3 - For the meters could I assign lc_meter_port=USB1 then USB2 and USB3 ?Yes, you need three DOUT_MATRIX components, and each one has to listen to another USB port.
4 - Why my setup returns all the time at default when I reboot ?It works like intended.
Rename your file to "DEFAULT.NGC" so that it will be loaded after startup
Best Regards, Thorsten.
-
Thorsten Könntest du mir bitte noch sagen ob es möglich ist die eigentlich für midi out gedachten pins MI3 und MI4 des J11E auch für Midi out zu nutzen ?
Nein, das geht leider nicht, der STM32F4 ist leider nicht so flexibel im IO Multiplexing.
Die App muss aber Quad IIC explizit unterstützen, oder? Mit der klassischen NG-App wird das doch nix, oder fehlen mir hier auch Infos? Auf der ucapps - Seite gibt es leider keinen Eintrag zu Quad IIC.koennte ich in die MBNG einbauen wenn es wirklich jemand benoetigt.
Gruss, Thorsten.
-
Sauber! :)
Gruss, Thorsten.
-
Hi Chris,
it won't be possible to load a .NGC file without switching to another session, otherwise this could lead to inconsistencies (e.g. while storing/restoring snapshots, when labels are used, etc...)
However, it's possible to switch to another setup.
Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre2.zip
There is a new .NGR command called "LOAD"
e.g. if you want to switch to XXX.NGC file, write:
if ^section == 1 load xxx endif
and trigger this section from an event
Best Regards, Thorsten.
-
Today you replied to a posting which gives you a link to a C based application which is a much better example:
Best Regards, Thorsten.
-
Hi Alex,
I think that MIDIbox NG is the best choice in your case, no need to write a special firmware.
Presets could be written into .NGR scripts, see also http://www.ucapps.de/midibox_ng_manual_ngr.html
The script is directly executed from SD Card, there are commands to send any MIDI messages (including SysEx strings), so that there are actually no limitations.
MBNG also supports graphical displays, see http://www.ucapps.de/midibox_ng_manual_lcd.html
ST7920 GLCDs are not supported. If you don't want to write your own driver, please select a GLCD which is already supported by MIOS32.
Best Regards, Thorsten.
-
Hi,
this behaviour indicates a bad MIDI interface (as you've already noticed).
SysEx strings sent by the PIC are correctly received, but the PIC doesn't receive well shaped MIDI messages.
This could also be related to a problem with the MIDI cable.
Is TEST MIDI2 passing at your side?
However, the Neusonik interface is really worth the money.
Best Regards, Thorsten.
-
Hi Sacha,
two observations: does the lower waveform of the first picture really show the OE# line (Pin 13 of the 74HC595, resp. STM32F4 pin RC11, resp. J15:RW)?
The OE# state should never change while new data is shifted into the 74HC595.
If this is really J15:RW, then the problem is related to a connection error.
Please also check the signal slope, it should be ca. 100 nS
If a value transitions at the OE line takes more time (> 500 nS), then you are using the wrong pull-up resistors at R33, they should be 1k
Best Regards, Thorsten.
-
I think/hope that I found the problem! :smile:
You've used "SRIO num_sr=16" after the matrix configuration, and this caused an inconsistency in the selection line pattern configuration, because it has been prepared for num_sr=32 before the SR number has been changed.
Could you please try this version:
http://www.ucapps.de/mios32/midibox_ng_v1_033_pre1.zip
It doesn't fix the WARNING and ERROR messages.
- some "#" (comments) are added at the end of the command line; this is currently not supported (but could be supported in future) - the appr. ERROR can be ignored
- WARNING resolution=7bit: valid, because the resolution parameter is only supported for the AINSER device configuration command, not for EVENT_AINSER event commands
Best Regards, Thorsten.
-
Starlike SRIO wiring... do you mean DIN (in)<<-->>DIO_MATRIX (out)<<-->>DOUT ? 3 plugs on 1 cable where DIO_MATRIX is in the middle?
yes, however...
in your default.ngc file I found following line at the end:
DebounceCtr 20
please remove it
Best Regards, Thorsten.
-
Hi Bartosz,
(I will look into your .ngc file later if really required).
But to your questions: yes, the cable length does matter.
You already noticed with an earlier firmware version some unstable scan values.
Which means that the construct was already in a critical range - each change in the firmware can change the situation.
E.g. slightly more activity in the firmware can cause a higher power consumption and if your core module is powered from a weak PSU (or a weak USB based supply), the situation can get worse.
For further debugging it makes sense to check:
- if it gets better with a different PSU. Resp. if your core module is powered via USB, please use a USB hub with external PSU
- if v1.032 is working properly with less modules connected
> Question2: what maximum length of cables between modules would you recommend?
as short as possible (until it gets unstable ;-)
However, there are measures to compensate long cables
a) starlike SRIO wiring: after the two DIO_MATRIX modules, use a Y cable to connect two DINX4 and two DOUTX4 in a chain. Don't mix DIN with DOUT in the chain
b) termination of the last SRIO modules in the chain with a 100 Ohm resistor + optionally 100 pF cap (not important if not available) between SC+Ground and RC+Ground. See also http://www.ucapps.de/midibox_seq/mbseq_v3_din.pdf and http://www.ucapps.de/midibox_seq/mbseq_v3_dout.pdf
c) the usage of line drivers (brand new): http://www.ucapps.de/mbhp_line_driver.html
However, before you start to try these measures, please feedback on the power supply topic before deciding the next steps.
Currently I can't 100% ensure that the latest firmware changes were uncritical under all conditions, but under the assumption that the PSU and cable length topic isn't clarified yet, I think it's better to discuss this first before proceeding with the time consuming SW debugging round (where I will need your help as well, it will cost ca. 2..3 iterations to identify the root cause at your side)
Best Regards, Thorsten.
-
The modules have been tested successfully :)
Here the new page which also contains a link to the .brd files: http://www.ucapps.de/mbhp_line_driver.html
Best Regards, Thorsten.
DANKE FÜR ALLES! ES LÄUFT PERFEKT!
in Deutsch
Posted
Ja, http://www.ucapps.de/midibox_seq_manual_m.html ganz unten,
in Deinem Fall sieht das erste Bookmark wie folgt aus:
Der naechste:
usw.
Gruss, Thorsten.