TK.

Hi, obviously "MIDI OUT4 will be available on the J5B.SA pin" was a typo (fixed), J4B.SA was meant. Anyhow, it seems that you haven't found this schematic yet, which describes more than 1000 words: http://www.ucapps.de/mbhp/mbhp_core_lpc17_midi3_midi4_extension.pdf Best Regards, Thorsten.

You could pass the default value with the EVENT_* command: EVENT_... value=<the-default-value> Does this help?

In order to get a feeling about the typical "Event Pool" RAM consumption, I'm asking you to post the amount which is consumed by your configuration files in this thread. Your feedback is important for the decision of future features! The RAM consumption can be determined in the MIOS terminal with the "system" command. The last two lines will print something like: Event Pool Number of Items: 70 Event Pool Allocation: 4593 of 24576 bytes (18%) These are the values I would like to know! Best Regards, Thorsten.

A new version is available - it mainly relaxes previous limitations related to (G)LCDs, existing panels should work like before! MIDIbox NG V1.013 ~~~~~~~~~~~~~~~~~ o overworked LCD handling: there is no buffer limitation anymore, any LCD and GLCD size is accepted, which especially means that GLCD fonts are displayed correctly independent from the specified number of connected devices. o this change has freed some RAM which can be used for other purposes in future Best Regards, Thorsten.

(there is no need to request for permission as long as you are not seeling more than 10 devices per year)

No additional bulk order is planned. If you've luck, you will be able to buy a GM5 via the http://midibox.org/forums/forum/36-fleamarket/'>Fleamarket Best Regards, Thorsten.

Before starting with the implementation, I would like to know if somebody has some additional usecases for the "conditional event" feature in mind? Best Regards, Thorsten.

Congratulations! This is the perfect replication! :thumbsup: I really like that you improved so many details and documented them so well! Best Regards, Thorsten.

As already mentioned - it works! :smile: See also the .NGC page in the user manual: http://www.ucapps.de/midibox_ng_manual_ngc.html Search for the keyword "mf" (see especially the description of the MF command) Best Regards, Thorsten.

It's empty because I'm not able to compile the VST variant. Best Regards, Thorsten.

Yes, there is no protection against duplicated IDs - and only the first id will be taken. Which explains, why the labels were not print out: because they were defined for the second set of (redundant) EVENT_ENC Best Regards, Thorsten.

Ja, da laeuft was schief! Vielleicht ist auch etwas mit dem Core-Modul nicht in Ordnung, so dass auf der rechten Seite (wo sich u.A J10 befindet) keine Spannung ankommt. Verfolge mal die Leiterbahnen zwischen J2 (Ausgangspunkt fuer die Spannungsversorgung) und saemtlichen Vss und Vdd Pins - sowohl an den ICs, als auch an den Buchsen. Am besten ueberpruefst Du die Vdd Pins gegen J2:Vss, und die Vss Pins gegen J2:Vdd - es sollten immer 5V anstehen. Gruss, Thorsten.

noticed ;) Btw: the NRPN handling for Multi Patches is fixed in V2.043

The MB64E application isn't prepared for inverted selection signals. You either have to replace the sink drivers (uln2803) by bridges, or you've to wait for the next version where this option will be available as a compile switch (i haven't integrated it yet...) Best Regards, Thorsten.

Ok, understood. Something like "conditional events" are not available yet. Please give me some time to think about a good solution which also covers other topics on the Agenda. E.g. it would not only be nice to print labels depending on values of certain elements, but also to send different MIDI messages. E.g. this would allow to send different CCs when an encoder is incremented/decremented. Or it would allow to realize a "split point" for a MIDI keyboard. It could work somehow like demonstrated in this snippet: /edit: final solution: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fconev_5.ngc But also: /edit: final solution: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fconev_4.ngc Best Regards, Thorsten.

Hi, see also: http://www.ucapps.de/midibox_ng_manual_ngl.html Following snippet should work: COND_LABEL sndbnk COND <127 "GM Bank" COND_ELSE "Alt Bank" This conditional label can be print with "^sndbnk" Best Regards, Thorsten.

Liegt eigentlich zwischen Vdd und Vss (74HC595, Pin 8 und 16) eine Spannung? Und wenn auf CS# keine Spannung liegt, dann ist das schon sehr verdaechtig: ist das Kabel wirklich richtig verbunden? CS# liegt ja bspw. direkt an PIC Pin #24 - wechselt hier die Spannung, wenn Du sie ueber den Interconnection Test ansteuerst? Gruss, Thorsten.

Hi Jo, great that the crash issue is solved! :) The delay_slowest value not only affects the latency, but also the (linear) velocity calculation. With higher values the velocity will get "stronger" earlier. This dependency could change once a non-linear velocity curve is available. Best Regards, Thorsten.

Wie hast Du eigentlich die serielle Verbindung zwischen Core und SID Modul getestet? Die einfachste (und sicherste) Moeglichkeit waere, den PIC und die 74HC595er aus den Sockeln zu nehmen, und die Verbindungen von den entspr. PIC Pins bis zu den entspr. 74HC595 Pins durchzupiepsen. Gruss, Thorsten.

Thanks for the sanity check, very useful! :smile: The scan rate is lower than specified at the MBKB page since I had to decrease the SPI rate after it turned out, that a too fast SPI overloads the application too much so that USB transfer were delayed by several mS - I aligned the latency values at the MBKB page now. To your proposals: It's possible to specify a separate delay_fastest_black_keys now. It's taken on black keys when the specified value is > 0 Currently the value is not stored in EEPROM, because I would like to wait for more potential parameters before changing the storage structure. The changes are available in the repository. I guess that with "made fixed" you mean, that the same value can be taken for black and white keys? done (but this was uncritical, since the runtime environment will initialize all variables with 0 anyhow I will keep this conditional check as it is - at a single place. Otherwise I would have to do similar checks at multiple places, which leads to more error prone code. In addition, it could be that in future kc->break_inverted could be considered for the optimized scan (which is only a testing issue - very hard if I don't own such an exotic keyboard...) I'm not able to reproduce this (neither with the latest revision, nor with r1633) Are you using the MIOS32 toolchain? (ensures that you are using the same compiler + newlib version) The PC indicates, that an unintended write operation into the FreeRTOS variable range happened. But I haven't found a place where this could happen. Anyhow, I added a check for an "invalid" read operation (kc->prev_row != 0xff) - which won't solve the problem, but is just more clean. And I added a check for the key number boundary (key >= KEYBOARD_NUM_PINS) for the case that I overlooked something during the key number calculation. Could you please check if the firmware still crashes with these changes when the upper notes are played? Best Regards, Thorsten.

Kommt darauf an - funktionieren denn die restlichen Pins? Gruss, Thorsten.

Das ist richtig, die Spannung bleibt gesetzt bist Du eine andere Taste spielst. Gruss, Thorsten.

Im README.txt der mbsid_interconnection_test Applikation. Gruss, Thorsten.

Hi Jo, thanks for the feedback! I will check your findings & proposals this evening. To the changes in terminal.c: they can't be the reason for such a crash, the root cause must be somewhere else - e.g. a stack overflow or something similar. I will try to reproduce this. Best Regards, Thorsten.

It makes sense to try it again with MBNG V1.012, it contains the latest LCD driver changes. Best Regards, Thorsten.