TK.

Are you able to compile the $MIOS32_PATH/apps/misc/usb_osc_midi_proxy app? If not: update your repository! cd $MIOS32_PATH svn update . [/code] Best Regards, Thorsten.

Now let's see your statements from a user point of view: This requirement wasn't documented, it leads to incompatibilities with existing panels and it will result into some programming effort at the user's side - can it be avoided to make the usage as much comfortable as possible? From my (programmers) point of view it is a design flaw if events are triggered before all objects of the "mother class" (-> the panel) have been constructed. So, after I spent a lot of time to create this panel, I should spend some additional time to workaround the way how Ctrlr handles the panel construction now. How should this continue in future - I don't have enough time to check with each Ctrlr version if my panel is still compatible with all OS versions - wouldn't it be better to run some consistency (resp. "unit") tests before a release, even if it's only a "nightly build"? I would be glad to provide the MBSID panel as a "unit test" ;-) From my point of view unnecessary programming effort because I assume that all objects exist before a modulator event triggers a Lua script. I only want to be informed (via error message) if I accessed an non-existent modulator during runtime - but I don't want to consider programming details of Ctrlr during the undefined construction phase (objects could be constructed in any order...) Sorry if this sounds a bit harsh, but I must say that I'm a bit de-illusionated after I changed from JSynthLib to Ctrlr, and now have to face new compatibility and maintenance issues that I originally wanted to see solved. I even can't build Ctrlr by myself because of the usage of undefined library versions... Best Regards, Thorsten.

Actually the bugs which currently prevent us from using the MBSID panel with newer Ctrlr versions exists in the Windows and Mac build. After the Panel is loaded, a lot of "attempt to index a nil value" messages pop up. I guess that this happens because Ctrlr tries to send MIDI events via the Lua scripts before the complete panel has been created. The Lua scripts are trying to access components which haven't been constructed at this moment - and this leads to the failure. This also automatically disables the scripts, and therefore most controllers don't send MIDI events anymore. It would be helpful if controllers wouldn't be sent during panel load (or only if explicitly requested by the panel created), because this is leading to inconsistencies at my side (4 engines with different SysEx views are handled by a single panel). It also increases the startup time (ca. 2..5 mS per parameter due to the MIDI baudrate related bottleneck) Note that this not only causes a problem with MIDIbox synths, e.g. some older synths could fail if they are receiving too much data. And in general it's always a good idea to construct all components first before triggering actions (the current handling could also cause issues with other panels) Will it be possible to provide a standalone version with multiple panels? I'm asking because it could be that users who are working under Windows mostly don't have a multi-client capable interface, which means that they could only use a single panel (e.g. either MBSID *or* MBFM) anymore. Best Regards, Thorsten.

Ein ambitioniertes Projekt, bleibt an der Sache dran! :) Ich denke, dass Du mit "ADSR Daten" generell die Soundparameter meinst, also nicht nur die Huellkurve fuer die Lautstaerke, sondern auch Wellenformen, Filtereinstellungen (falls vorhanden), Filterhuellkurve, LFOs fuer Vibrato usw. Die sind zunaechst einmal sehr synth-spezifisch. Ich behaupte mal, dass Du eine GM kompatible Bank mit einem subtraktiven Synth nur Ansatzweise hinbekommen wirst. Mit einem FM Synth geht das schon eher (und mit einem samplebasierten Synth natuerlich am besten) Vor Urzeiten habe ich ein Skript geschrieben, welches das .o3 Format (das mal im Linux-Soundkarten Treiber verwendet wurde, evtl. immer noch) in ein lesbares Format umwandelt, und darueber hinaus auch in MBFM Patches. -> es befindet sich hier: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_fm_v1%2Futils%2Fpatches%2F Gruss, Thorsten.

Piezos geben nur einen kurzen Puls aus, es erfordert eine hohe Samplerate um diesen "einzufangen" und akkurat auszuwerten. Am besten realisiert man das mit einem separaten Mikrocontroller, und schliesst diesen dann an einen der 4 MIDI INs des LPC17 Moduls an. Die Firmware des EDrum Projekts (http://www.edrums.info) waere hierfuer besonders gut geeignet. PSRs (auf "Widerstandsbasis") liefern hingegen einen statischen Wert, der zeitnah mit dem AINSER64 Modul abgeholt werden kann. :) Gruss, Thorsten.

Very likely only the LCD has been fried. Best Regards, Thorsten.

You have to include following file to get proper access over the UIP_TASK_* function declarations: #include <uip_task.h> [/code] Once you did this, the compiler will also tell you if the UIP_TASK_InitFromPresets function is used correctly before linking. Best Regards, Thorsten.

This happens if your sammichSID receives SysEx data from MIOS Studio, but MIOS Studio doesn't receive data from sammichSID. -> a timeout will happen and the MIDIbox will reboot. Is the MIDI OUT cable of sammichSID connected to your PC, and did you select the appr. MIDI interface in MIOS Studio? Best Regards, Thorsten.

My input: I would use a 6N138 and 1k/4.7k resistor values like in this schematic: http://www.ucapps.de/mbhp/mbhp_core_lpc17_midi3_midi4_extension.pdf This combination is well proven. I've no experiences with the 6N136, could be that the parameters are not matching with the electrical integrity (and baudrate) requirements. Of course, you could also work without an optocoupler if the circuit is supplied by the same PSU as the MIDI device. E.g. see the MBHP_LTC circuit (an expired module, but just have a look how MIDI Thru is realized): http://www.ucapps.de/mbhp_ltc.html Best Regards, Thorsten.

I agree that such customized setups are useful and I've also did some preparations to handle this, just only the store/restore functions have to be implemented. But concurrent usage of multiple setups is not considered and the implementation would result into a major code rework which I would like to prevent (to avoid an unnecessary high complexity) Instead, multiple instances of MIOS Studio have to be opened - does this sound acceptable? Best Regards, Thorsten.

Me too! (I've a second frontpanel which needs a case! :-) Best Regards, Thorsten.

Could it be that you are using a PIC18F452 (has only 32k Flash) instead of PIC18F4685 (has 96k Flash) This could explain why the upload is failing after 23%, because (considered that around 12k is allocated by MIOS and won't be overwritten by the app) Best Regards, Thorsten.

MC/LC protocol doesn't give direct access to the parameters. INs/OUTs, Busses, etc.. can be changed, but only with a user interaction which is (almost) impossible to automate. E.g. you have to switch between the busses by pressing InOuts or Sends button multiple times, it depends on the channel strip configuration how many times exactly to reach the first parameter again... So, maybe an alternative proposal: have you ever worked with the controller assignment page? It could be that there is a premade setup available... somewhere... Best Regards, Thorsten.

Just two different datasheets from two different companies, therefore H/L are listed in a different order but this can be ignored. The function should be identical Best Regards, Thorsten.

Please remember that the LPC17 core supports 4 internal UARTs as documented here: http://www.ucapps.de/mbhp/mbhp_core_lpc17_midi3_midi4_extension.pdf Using these UARTs is the preferred solution as the system load is minimal. (I'm not saying that the load generated by 4 IIC_MIDI modules is high, but the perfect solution would use as less IIC_MIDI modules as required) So, you only need two IIC_MIDI modules, and since the IIC address selection is done via jumpers, you only need a single firmware (just the precompiled .hex file) for the PIC16F88 The required jumper settings are documented at the MBHP_IIC_MIDI page: http://www.ucapps.de/mbhp_iic_midi.html Search for "Configuration and Interconnections", there is a picture which shows how to stuff the jumpers for address 10 and 12 Following application can be used to test if the LPC17 core can access the IIC Modules: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fiic_midi%2F Once this test is working, the part for a merger application is simple: just use UART0...UART3 ports to access the internal MIDI ports, and IIC0..IIC1 to access the IIC_MIDI ports E.g. you could take this app as a basis: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_midi_4x4%2F and enable IIC_MIDI in the mios32_config.h file: // enable 2 interfaces #define MIOS32_IIC_MIDI_NUM 2 // Interface and RI_N port configuration // _ENABLED: 0 = interface disabled // 1 = interface enabled // 2 = interface enabled, check RI_N pin instead of polling receive status // _RI_N_PORT: Port to which RI_N is connected // _RI_N_PIN: pin to which RI_N is connected #define MIOS32_IIC_MIDI0_ENABLED 1 #define MIOS32_IIC_MIDI0_RI_N_PORT GPIOC // not used due to mode #1 #define MIOS32_IIC_MIDI0_RI_N_PIN GPIO_Pin_0 #define MIOS32_IIC_MIDI1_ENABLED 1 #define MIOS32_IIC_MIDI1_RI_N_PORT GPIOC // not used due to mode #1 #define MIOS32_IIC_MIDI1_RI_N_PIN GPIO_Pin_1 [/code] Note: RI_N isn't used here, therefore the GPIO settings can be ignored (they are only valid for STM32, I'm unsure if the driver is ready to support LPC17 as well) Best Regards, Thorsten.

7219 isn't hardware-compatible to the 7221, because it uses a different protocol to access the registers. Unfortunately I've neither 7219 for testing, nor the time to develop a different driver for these chips + debug this remotely (with your help) Are you able to replace the chips and to change the wiring to a DIN->DOUT chain? If not, somebody else has to help you here, or you have to learn assembler! ;-) Best Regards, Thorsten.

This is some untested code which should allow to set/clear an individual bit: void STRIBE_SetLED(unsigned char stribe, unsigned char lr, unsigned char led, unsigned char value) __wparam { unsigned char and_mask, or_mask, offset; or_mask = lr << ((stribe&3)<<1); and_mask = ~or_mask; offset = ((stribe&4)<<4); INTCONbits.GIE = 0; // temporary disable IRQs to avoid clash with STRIBE_Timer() // set or clear LED state? if( value ) max72xx_digits[offset+63-led] |= or_mask; } else { max72xx_digits[offset+63-led] &= and_mask; } INTCONbits.GIE = 1; stribe_flags.LED_UPDATE_REQ = 1; } [/code] I hope that it says more than an abstract description of the required implementation... Best Regards, Thorsten.

There are no issues with the MIDI handling on Mac with Juce 1.52. So, if they are doing changes then these are either enhancements of features which are not used by MIOS Studio, and/or bugfixes of such functions. One more reason to wait for a stable release which has been pre-tested by software experts, no need to load the MIDIbox community with such trouble... ;-) Does this happen with your private build, or with the official build of MIOS Studio? If private build: try the official build, there are no known code upload issues. If official build: check the power supply of the core, maybe it's too weak? E.g. measure the voltage at J2 - it should be 5V before and during code upload. Best Regards, Thorsten.

kann ich uebrigens bestaetigen! :) Gruss, Thorsten.

Here a short overview over the uip_task_standard module which is demonstrated in the tutorial app: uip*: this code is required to handle UIP functions from a FreeRTOS task. The (simple) invocation of this task is demonstrated in the tutorial uip_task mainly handles incoming and outgoing packets and links to protocol demons, such as DHCPC... and the OSC Server There are also access functions to change IP parameters, e.g. from a MIOS terminal. osc_server: parses incoming UDP packets which are received over given ports. The entry point is OSC_SERVER_AppCall, which is a common uIP hook (see also the other examples in the uip directory, they are simpler but all use the same hook) OSC_SERVER_SendPacket sends a packet via the uIP layer. If you don't like the uIP based approach, because it means too much overhead for your application, then have a look into this directory: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fuip%2Fmios32%2FLPC17xx%2F network-device.c contains access functions to send/receive packets directly. Best Regards, Thorsten.

Btw.: still no update, it seems that they prefer to work with commercial business partners. Best Regards, Thorsten.

Even more patches -> first sticky thread in this forum section ->

Sidenote: you can use the original makefile if you set environment variables before "make" (which executes Makefile) I'm using different "setup files" for different scenarios, e.g. this one for LPC17: export MIOS32_PATH=~/svn/mios32/trunk export MIOS32_BIN_PATH=$MIOS_PATH/bin export MIOS32_FAMILY=LPC17xx export MIOS32_PROCESSOR=LPC1769 export MIOS32_BOARD=MBHP_CORE_LPC17 export MIOS32_LCD=universal export MIOS32_GCC_PREFIX=arm-none-eabi [/code] It's stored in my user directory under the name "lpc_init", and I call it with: [code] source ~/lpc_init thereafter all makefiles automatically take over these parameters when I'm typing: make [/code] in the directory of the application. Best Regards, Thorsten.

Die BLM16x16+X haendisch zu loeten ist wirklich eine Herausforderung und nicht unbedingt empfehlenswert. Ich warte immer noch auf einen Freiwilligen, der ein PCB fuer die Matrix layouted, ich wuerde mich auch finanziell bei der Bestellung der ersten Prototypen beteiligen, denn meine eigene BLM ist mittlerweile nicht mehr transportfaehig. Gruss, Thorsten.

Hi Tom, actually this is a better way when I was using on my own MIDIbox. -> go for it if there is no other proposal. :) Best Regards, Thorsten.