TK.

Since you've already tested the 12V voltage, it's very likely related to the caps. E.g. if no caps are connected at all, it would sound like described. Best Regards, Thorsten.

under the given pin constraints (parallel interface, most pins allocated): yes - but see also my answer on the serial interface approach below. with a parallel interface: yes interfacing the chip via the already existing serial interface sounds like a good plan! In this case, mulitple PICs could transfer data to the the chip independent from each other. And no 74HC595 shift registers would be required. The serial clock is ca. 10 MHz, this means that the "cog" would have to sample the data inputs at least with 20 MHz (better: 40 MHz) Best Regards, Thorsten.

It could help to add a small resistor (e.g. 10 Ohm) in serial to the 5V power input of the core module + a 1000..2200 uF bypass cap in parallel between ground and +5V *behind* the resistor (at J2) (in fact you could just re-use C2 by soldering the pins to J2 with small wires) I did something similar with the AINSER64 module with success: much less ripple noise :) See also this schematic: http://www.ucapps.de/mbhp/mbhp_ainser64.pdf Best Regards, Thorsten.

Also wenn Du mir auf diese Weise mit der Dokumentation aushelfen koenntest, waere ich Dir extrem dankbar! :) Wiki bevorzugt - so kann man im Nachhinein noch Updates einpflegen. Die App ist so gut wie fertig - zumindest fuer meine Beduerfnisse ist sie bereits voll funktionsfaehig. Doch ich moechte vor einer Release noch eine Moeglichkeit einbauen, das Hardware-Setup vom MIOS Terminal aus zu konfigurieren, und im EEPROM des LPCXPRESSO Moduls abzuspeichern, so dass die App bei Aenderungen nicht neu kompiliert werden muss. Auch die USB-MIDI Ankopplung wollte ich noch erweitern, so dass die beiden MIDI IOs wie bei einem normalen MIDI Interface angesteuert werden koennen. Zusammen mit dem dritten MIDI IO an J4B (dort wird dann das MBHP_MF_NG Modul direkt angeschlossen - also ohne Optokoppler usw... Schaltplan folgt) stehen dann also via USB MIDI 4 MIDI Ins und Outs zur Verfuegung. Der Source Code befindet sich hier: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_lc_v2%2F doch keine Panik: Du musst ihn nicht selbst kompilieren. Es wird ein Release-Package geben - falls es jemand bereits heute ausprobieren moechte, dann von mir aus sofort ;-) Gruss, Thorsten.

Hi, Not completely: data, address and control lines coming from the serial shift registers are shared, only the chip select line has to be connected separately so that both SIDs can get different data. No, this isn't possible since only a single stereo engine can run on a PIC, and since two PICs can't share the same bus (such an approach would have a massive performance impact) Best Regards, Thorsten.

sounds like there is a bug in the MIDI device driver. This also explains the blue screen (which is not caused by Java itself) It could make sense to search for an update or alternative MIDI driver. Best Regards, Thorsten.

They are only mounted on the bottom. no, this isn't required (and also not possible) Best Regards, Thorsten.

Both are correct: the serial input (SI) of the ENC28J60 chip has to be connected to the serial output (SO) of the core module, and vice versa. Just read the notes under the J1 socket, I tried to make this very clear... they are partly also visible in your snapshot. ;-) Best Regards, Thorsten.

Yes, correct. Don't forget to connect the grounds between the core and sound module together, then it will work. :) Best Regards, Thorsten.

My try: you are using an Emagic MT4 interface which provides an internal MIDI router. Could it be, that in your router setup the MIDI channel is changed to a different one? The MIDImon app should show the incoming MIDI channel - is it Chn1? Alternatively you could try to select different MIDI channels in the ensemble menu (press the first general purpose button in the main menu, go to INS and change the Chn value between 1..16 - this only has to be done for the first instrument INS1) Best Regards, Thorsten.

Hi, there are many possible solutions, so let's find the best one for you. First of all I need to know which DAW you are using, and in which mode the motorfaders should be controlled? -> common MIDI events or an emulated protocol? Best Regards, Thorsten.

Ok, seems that I just was just to lazy to type "grep -i broadcast $MIOS32_PATH/modules/uip/uip/*" for you! ;-) There is an option called "UIP_BROADCAST", which is derived from "UIP_CONF_BROADCAST" I guess that this flag has to be inserted into the local uip-conf.h file of your application: #define UIP_CONF_BROADCAST 1 [/code] For more background details, just search for the keyword "broadcast" in uip.c E.g. following part indicates, that this option checks for an All-One IP address (255.255.255.255): [code] #if UIP_BROADCAST DEBUG_PRINTF("UDP IP checksum 0x%04x\n", uip_ipchksum()); if(BUF->proto == UIP_PROTO_UDP && uip_ipaddr_cmp(BUF->destipaddr, all_ones_addr) /*&& uip_ipchksum() == 0xffff*/) { goto udp_input; } #endif /* UIP_BROADCAST */ Forget what I wrote about port 65535, this was related to a different topic. Best Regards, Thorsten.

Thanks! :) I had this in mind while programming the code ;-) It's a nice source for inspirations - and especially allows to modify the results later so that the pattern doesn't sound like "generated" anymore. :) ha, I got you! ;-) Best Regards, Thorsten.

The module is designed to be controlled from another MIDIbox (or from a PC). There are no free pins for a MBHP_DINX4 modul, or even a free pin to connect a single button. Best Regards, Thorsten.

Hi Marcelo, welcome to the forum! :) It could work without optocouplers at both sides. No problem with the DB50XG MIDI Out -> LPC17 MIDI In connection, because the appr. Rx input of the LPC1769 is 5V tolerant. For the other direction LPC17 MIDI Out -> DB50XG MIDI In I'm not 100% sure if a level shifter is required, because the LPC1769 only outputs 3.3V, but DB50XG probably works at 5V basis. If you want to design fail-safe, I recommend to use one free "channel" (buffer) of the 74HCT541 for level-shifting, because you won't need J19 anyhow. It should work this way: / Pedal / Switch 1k Resitor 3.3V o----/ ----o---|####|----o Ground | +----> to J5A0 [/code] Best Regards, Thorsten.

No, you have to use the uip_udp_bind function. Just have a look into the osc_server.c file (I guess that you remember this file). Search for osc_local_port, it gives you all the places where I'm "installing" and checking for the port number. Note that only ports announced with uip_udp_bind will notify the OSC_SERVER_AppCall() function about new packets. There are other possibilities of course, but this would require a change in the original uIP code (search for UDP in uip.c) I tried to find a solution which is compatible (although not optimal). Best Regards, Thorsten.

Did you already exclude that this is related to a hardware issue? E.g what happens if you write: BUTTON_TRACK_SEL 19 3 # NOT USED # BUTTON_BOOKMARK 18 2 BUTTON_PATTERN_RMX 18 2 [/code] does this allow you to control the Remix function with the "bookmark" button? Best Regards, Thorsten.

Hallo, dieses PIC basierte Projekt ist zwar voll lauffaehig (sie wurde in den letzten Jahren von vielen Leuten nachgebaut), doch eigentlich kann ich sie nicht mehr ruhigen Gewissens weiterempfehlen, da die LPC17 basierte Variante wesentlich anwenderfreundlicher ist. So entfaellt bspw. das externe MIDI interface, stattdessen laesst sich das MBHP_CORE_LPC17 Modul ueber den USB Port direkt an den Rechner anschliessen. Das spart auch etwas Geld, zumal die heutigen Billig-MIDI-Interfaces fuer 20 EUR abwaerts, die es so bei Thomann, Ebay und Konsorten gibt, noch nicht mal SysEx Daten sauber uebertragen koennen, so dass eine Kommunikation mit der DAW nicht zustande kommt. Das MBHP_MF_NG Modul wird von der PIC basierten Applikation nicht unterstuetzt. Im Vergleich zum MBHP_MF werden die Motorfader praeziser angesteuert, und auch die Kalibrierung ist wesentlich einfacher geworden. Nun fragst Du Dich sicher, warum es zu der neuen App noch keine Informationen auf meiner Webseite gibt: nun, weil ich mir bisher unschluessig war, ob ich sie weiterhin Standalone bereitstellen soll, oder als Teil der geplanten "MIDIbox NG" App, die MIDIO128, MIDIbox64, MIDIbox64E und MIDIbox LC vereint. Mittlerweile denke ich jedoch, dass eine separate Applikation fuer den Anwender einfacher zu ueberschauen ist, und dass die entspr. Code-Module spaeter immer noch in einer MBNG Firmware vereint werden koennen - quasi fuer die "Power-User" - somit muss eigentlich nur noch die Dokumentation auf der MBLC Seite ueberarbeitet werden. Im Grossen und Ganzen sieht sie wie die PIC basierte Loesung aus: - statt des MBHP_CORE Moduls nimmt man ein MBHP_CORE_LPC17 - statt des MBHP_MF Moduls nimmt man ein MBHP_MF_NG - Buttons, LEDs, LED-Ringe und LED Digits werden genauso wie beim PIC an J8/J9 angeschlossen - die beiden LCDs werden an J15A/B angeschlossen (die beiden Ports sind also schon vorgesehen - keine "Kabelpeitsche" notwendig wie beim PIC) -> fertig! :) Noch ein Kommentar zu den LED Ringen: die finde ich ziemlich teuer. Vergleiche mal mit der Loesung, die LEDs direkt in das Frontpanel zu kleben (so wie bei mir) Gruss, Thorsten.

I added an an Euclidean Rhythm Generator into the MBSEQ V4 firmware today! :) It's inspired from http://ruinwesen.com/blog?id=216 and http://crx091081gb.net/?p=189 In distance to these solutions, the generator writes static sequences into the track storage so that they can also be modified if desired: Parameters can be changed for each drum instrument individually. Here a recording where I'm changing the parameters while a single drum track is playing: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_euclid1.mp3 The generator can also be used for the trigger layers of a "normal" track: E.g. in this example I entered different chords into each step, and the gates are modified by the rhythm generator: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_euclid2.mp3 Next steps: add possibility to generate accent in drum tracks as well + searching for some more interesting parameters. :) Best Regards, Thorsten.

The LCD parameters are stored in the bootloader configuration range and read by the "universal" LCD driver. Advantage: somebody can run any application with the display and doesn't need to recompile the code! (not true for your special case of course...) The configuration details are described at the bottom of this page: http://www.ucapps.de/mios32_bootstrap_newbies.html Best Regards, Thorsten.

The changes are in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2F They are not released yet, as the setup_seq_dr_default.asm contains some workarounds which are only valid for the first prototype PCB, and which will be removed with the second prototype. Also the trigger assignments have to be changed. In order to avoid confusion, I prefer to wait for a release until the second prototype is finished (and working). Best Regards, Thorsten.

Hi Lars, you need: an array which stores counter values for each LED a timer (see mios32_timer tutorial) which decrements these counters as long as they are > 0 - it could be called each mS. Note that there is already a function which is called each mS which you could re-use for such a purpose: APP_SR_Service_Prepare()! a task which periodically updates the MAX7221 whenever the state of a LED has changed. This task should also set LEDs as long as the appr. counters are 0 your MIDI receiver sets a counter to 300 -> the timer will decrement the counter each mS, your task will notify this and update the LED accordingly. Best Regards, Thorsten.

As far as I remember, you've to listen to port 65535 to receive broadcasted packets. Best Regards, Thorsten.

fine! :) Best Regards, Thorsten.

I will test it once my panel is working again! :) Probably you misunderstood me, because... ...this is exactly what I requested! Also under the consideration that checking for the existence of an object costs time. As long as the guy who created the panel has ensured, that all accessed objects exist, there is no danger. In distance: if the guy forgot a certain object, he will be informed with an error message - all good! It was already working this way in r946, you just changed Ctrlr into the wrong direction. The panel will only work with MBSID V2, because V1 uses a different SysEx format, there are less parameters and they are structured differently. See also the SysEx documentation in the doc/ directory of the release package (compare v1 against v2 and you will see all the differences). Btw.: the SysEx format of MBSID V1 is similar to MBFM - so if you want to create a special panel for MBSID V1, take the MBFM panel as a starting point. Strange... are you really using this JSynthLib Snapshot 2010-12-18: http://www.ucapps.de/jsynthlib.html with Java 1.6 (J2SE 6.0)? Best Regards, Thorsten.