gm02froe

Hi Michael as it looks not all is that clear, since I dont have the desired results. here as I wrote in my codes: core1: MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP); sends MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0x91); MIOS_MIDI_TxBufferPut(newpin); MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x01); MIOS_MIDI_EndStream(); core2: MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP); core2 receives this midi message, but should pass it on, since its a "framed" event, right? however, it doesnt. why not?

hi didier its good to hear that you are also involved in this. let us know once you have more infos. as i mentioned i am not using the toolchain but a workaround with an ants building file. cheers martin

Hey Michael, works just sweet, thank you very much!

Hallo zusammen es scheint, dass ich hier auch noch meine aktuelle LED - flimmer -geschichte loswerden kann: immerhin habe ich jetzt eine funktionierende lösung mit den widerständen, danke vielmals! ich arbeite mit einer leicht modifizierten version von ain64-din128-dout128 -> nur benutze ich nur dout64 (oder 2 DOUT - Module). das flimmern verschwindet auch wenn ich in der applikation NUMBER_OF_SRIO auf 8 setze. leider ist das für mich keine lösung, da ich ja 4 DIN - module benutzen will. grüsse martin

hi simple question: how can I create a control message as mentioned in http://www.ucapps.de/midibox_link.html (the brown one) that just passes from core 1 to core 2? (I dont use core 3)

thank you for the hints. I solved it the following way: unsigned char Math_Scale10BitTo7Bit(unsigned int v, unsigned int min10Bit, unsigned int max10Bit, unsigned char min7Bit, unsigned char max7Bit) __wparam { // scales an 7-bit (0-255) value between min & max unsigned char scaled = 0; unsigned long promille; if(min7Bit <= 0){min7Bit = 0;} if(max7Bit > 127){max7Bit = 127;} if(min10Bit <= 0){min10Bit = 0;} if(max10Bit > 1023){max10Bit = 1023;} if(min10Bit <= v && v < max10Bit && min7Bit < max7Bit){ promille = (unsigned long)(v); promille = (promille - min10Bit) * 1000 / (max10Bit - min10Bit); scaled = (max7Bit - min7Bit + 1) * promille / 1000 + min7Bit; }else if(min10Bit > v){ scaled = min7Bit; }else if(max10Bit <= v){ scaled = max7Bit; } return scaled; } this way I can call the method like this: void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // a pot has been moved, send CC#<pin-number> at channel 1 MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xb0); // CC at channel 1 MIOS_MIDI_TxBufferPut(pin); // pin number corresponds to CC number MIOS_MIDI_TxBufferPut(Math_Scale10BitTo7Bit(MIOS_AIN_PinGet(last_ain_pin), AIN_10BITMIN, AIN_10BITMAX, AIN_7BITMIN, AIN_7BITMAX)); MIOS_MIDI_EndStream(); // notify display handler in DISPLAY_Tick() that AIN value has changed last_ain_pin = pin; app_flags.DISPLAY_UPDATE_REQ = 1; } and not to forget: AIN_DEADBAND = 5 (I dont really understand how deadband really works, this value is experimental) plus http://www.ucapps.de/mios/mios_libsdcc_v2_5_0.zip - which is the library for my humble java-like calculations.

hmm, thanks, didnt see that page. how do i get editors rights for the wiki?

Hi again recently I set up my eclipse as MIOS development environment on my old G4 iBook. Is there any interest for more infos? For now I use it like an editor, with the compile button to execute the make script. But eclipse allows the creation of customed tool-chains, so as a next step ... but thats for the moment beyond me.. cheers martin

Hi is there a way to change the voltage range (instead of 0V...5V -> 0.4V...5V) that is translated into 127...0 values?

Hi all thanks both of you for your quick reply! even though nothing is clear, it sounds marvelous. TK: The project was put on hold for the last 5 months, and I didnt want to fiddle around with the midibox-application during troubleshooting, at least not until now, because I need the "running status" feature. I will get back to you as soon as I have results. stryd_one: I hope u dont mind me skiping your questions, because it looks as if TK's lead makes perfect sense, though I hope now that the C-compile tutorial for beginners will do the trick! and that its possible to send sysex messages with max. cheers martin

Hi The problem I am confronted with is probably a unique one in this forum: I am using the midibox for my px1m0d project (http://www.maybites.ch/tikiwiki/tiki-index.php?page=px1m0d, it has been introduced last fall), and I want to play movies on the display (8x8 = 64 pixels or rather 12v lamps). now beside the fact that it is a unique widescreen experience, I have the limitation that controlling px1m0d via max/msp it can only play about 10frames (or 640 midi events) without starting to lag behind. the effect is thus, that while max/msp keeps producing the midievents, it looks as if the events are stored until they can be passed on. there is obviously a bottleneck, I I wonder where it might be. a - the midi - protocol can handle only so much events (1600(8x8x25) events per second is certainly beyond every virtuos musicians abilities) b - the midibox is too slow (I know its very fast, but fast enough?) c - the problem is max/msp or my computer, in this case I would be rather happy... or maybe d? cheers martin

Thanks very much for your kind feedback. I took the time to write a short making of, this will give some details of the development process and the hardwarework behind the shiny surface. http://www.maybites.ch/tikiwiki/tiki-browse_gallery.php?galleryId=6 cheers martin

got it sorted: TK helped me with a code snippled for the midbox64 app: -------------------------------- inside mb64_pots.inc: MB64_POT_Handler ;; save current pot number in MB64_CURRENT_POT SET_BSR MB64_BASE movwf MB64_CURRENT_POT, BANKED movlw 0xb0 call MIOS_MIDI_TxBufferPut movff MB64_CURRENT_POT, WREG call MIOS_MIDI_TxBufferPut movf MIOS_PARAMETER2, W goto MIOS_MIDI_TxBufferPut -------------------------------- this stops the internal communication between the AIN's and AOUTs and reduces the comunication on pure midi. thanks again Thorsten cheers martin

Hi moebius thank you very much for your quick reply. it works. almost... cheers martin

Hi I just read the other "jitter" post, and I probably should check on my soldering again, though right now I would like to avoid this because 1. all my modules work fine for themself AND 2. all my modules are installed and wired up. (64 AIN and 64 AOUT) here is my problem: I run midibox64 with 64 AIN's connected to pots and 64 AOUT connect to a PWM-module I reengineered and adapted. with the pwm I am able to dimm 64 12V lamps. this works fine, though my PWM works only between 4V and 7V, so I cannot use the whole midi range of 127 values but only a range of 30. but this is enough for my purpose. this works fine. the problem starts when a value change occours on a AIN pot (for example CC 91 Ch 5). this sets the voltage of the AOUT pin (in this example CC 91 Ch 5) on the voltage corresponding to the value sent by the AIN, until I send a midi signal to this pin (again CC 91 Ch 5) and it changes back to the sent value. this means for my lamp it either just switches off (above 7V) or on (below 4V) or it simply flickers if its in the process of dimming. since its an AIN pot that influences only the corresponding AOUT pin I assume its rather an application issue than a wiring or soldering problem. ah yes: I disabled midi merge. any suggestions highly appreciated. cheers martin

Hi how do I switch off midi trough on midibox64? I control 64 AOUT and 64 AIN, and because they both are mapped to the same cc's it would confuse my application. best regards martin

Hi I found the following discrepancy in the documentation for the core: http://www.ucapps.de/mbhp_core.html it states under available ports J2: ....In both cases the voltage regulator (IC2) should not be connected, also the rest of the voltage stabilization circuit between J1 and J2 (X1, C5, C6) can be left out... according to this diagram: http://www.ucapps.de/mbhp/mbhp_core.pdf IC2 is the optocupler. same thing further down under "used components". I assume the labeling in the core diagram is wrong, right? I am a newbee in electronics and just want to be sure, cause I want to power my two cores with 5V supplies. best regards martin

Hi Thorsten It works. My mistakes (as I learnd to expect): First I was mistaken: NO, I didnt switch on AMUX. I was 100 percent sure (though when I replied I wasnt able to check). Please excuse. Switching on didnt work either -> cause the one I wired up has a problem. the second one works fine (which obvioulsy didnt work either before because AMUX was switched off). Building two midiboxes with all the modules has helped me tremendously to find those little soldering glitches a newbe is prone to make. thank you very much best regards martin

Hi Thorsten Yes, I have.

Hi I dont know how to get my SHX8 module to work. I tested all the components involved, the core and the AOUT work fine, tested them with MIDIboxCV. I connected the modules acording to this schema: and this schema: http://www.ucapps.de/mbhp/mbhp_shx8_interconnections.pdf the shx8 has all the ground where there is supposed to be ground and 5v where there is supposed to 5v. I have two SHX8 modules, both show the same effects (or better: none). I send controller values to the midibox and follow the midibox64.ini configuration for the pots: pot 1..16 channel 1..16 controller 91 pot 17..32 channel 1...16 controller 93 pot 33..48 channel 1...16 controller 74 pot 49...64 channel 1...16 controller 7 the tested output pin doesnt show any signs of change when I test with all above controllers, sometimes there is a flickering, but really minimal. can somebody help me here? do I have to make additional entries in the midibox64.ini? or do I assume right that like between the buttons and the leds, the 64 AOUT correspond with the Pots? best regards martin

Hi Thorsten No, I didnt know. :-[ Now I get it! Sorry, I couldn't make any sense out of this table at all. I always clicked on the link because I expected a diagram... :-\ Best Regards Martin

Hi Thorsten Thanks for this Information, it was very helpfull. I was able to change the midi mappings for the pots. I assume that the mappings also apply for the 64 AOUT's. But I was not able to control them. I setup the connection according to http://www.ucapps.de/mbhp/mbhp_shx8_interconnections.pdf and made successfull tests with MIDIBox CV this way, but when I run the MIDIBox64 Application the red LED's dont react. I assume that the LED's light up when a MIDI signal is received that controls some output via AOUT even when the SHX8 is connected and DEFAULT_ENABLE_AMUX = 1. I compiled the MIDIBox64 application with the setting DEFAULT_ENABLE_AMUX = 0 in order to test the AOUT, but no success. The MIDI signals reach the core though and in this display-submenu: the signal value is displayed. Where do I make a mistake? best regards martin

Hi me :D Sorted!! Problem was not on application side but on PC side. Since I did my troublshooting with puredata (it can send Control data while MIOSStudio doesnt) I ran into this problem. Afther powering off/on the midibox didnt get any of the midisignals anymore, though my midi-usb interface did say otherwise. but when I sent a midi note via MIOSStudio, midibox received the event, and from this moment on from puredata as well. So when ever midibox reboots I have to reapply the midi settings in puredata and everything works fine. cheers martin

Hi Thorsten I enabled the AOUT and AMUX inside the main.asm, played around with mios_tables.inc, but dont seem to get any electrons moving (well, not on the SHX8 module). As I mentioned above I am looking for a straight forward mapping of midi note/velocity events to voltage like with the MIDIbox CV. How can I do this? that sound perfect to me, but I shy away of such an enhancement, since I am not well established in assembler. though your suggestion would be very elegant, I would rather opt for the modified ain64_din128_dout128_v1_3.zip application and link it with a second core on which a MB64 runs. what do you suggest? best regards martin

hi thorsten unfortunately yes. After a fresh upload I unpluged the midi out connection and I was able to control the led's, when I powered off/on -> no reaction. It actually looks as if the method "USER_MPROC_NotifyFoundEvent" is not called anymore. I tested this with an additional lcd-display call: USER_MPROC_NotifyFoundEvent ;; here we could insert code which switches the LEDs on/off via MIDI: ;; Entry number is in WREG ---- it corresponds to the LED which should be switched ;; the note velocity (or CC value) switches on/off the LED, it's stored in MIOS_PARAMETER3 IFSET MIOS_PARAMETER3, 6, call MIOS_DOUT_PinSet1 ; set LED if value >= 64 IFCLR MIOS_PARAMETER3, 6, call MIOS_DOUT_PinSet0 ; clear LED if value < 64 ;; print "DOUT event" message TABLE_ADDR TEXT_DOUT_EVENT_0 ; init pointer to string call MIOS_LCD_PrintString ; print line 1 call MIOS_LCD_PrintString ; print line 2 return TEXT_DOUT_EVENT_0 STRING 16, 0x00, "Received a DOUT " TEXT_DOUT_EVENT_1 STRING 10, 0x40, "Event: " ??? martin p.s. it would be nice to display the received midi event since its inside MIOS_PARAMETER3, but I havent figured that out yet. And its not really important.