Pablop

Audiocommander, I wrote your spell and it became alive... Your're a magician! Thank you a lot! Pablo

Thanx, Stryd, I followed your instructions and everything worked ok! I've just posted something about MIOS_Timer not working on GUISim, though, heh, there's always something new to stumble upon! ;-) Cya Pablo

Hi! I'm having trouble using MClock_Timer(); in GUISim. Something as simple as: void Timer(void) __wparam { ++counter; } doesn't work in guisim, but it does in the midibox.. Is there something I have to set especially for timer to work on guisim? Thanx a lot Pablo

Hi! If I understood you well, I took makefile and where it said OBJS=$(OUTDIR)/pic18f452.o $(OUTDIR)/main.o I added mtc.o so it now reads OBJS=$(OUTDIR)/pic18f452.o $(OUTDIR)/main.o $(OUTDIR)/mtc.o Sadly, I got the same error, and what's more, once the project is built, makefile returns to it's original state. thank you, anyway!

Hello people! I'm starting my way programming in c, and made my first steps using Notepad++. Everything was ok, but then I saw that with Acsim i could test my apps without flashing the pic. So, following the instructions in the wiki I started to setup Codeblocks and all the needed other things for ACsim to work. It's been complicated, but everything seems to be right. Everything but: I have a project based on mclock, where there's main.c and mtc.c, with their respective headers. When I try to bulid the project, either as debug or release I get the error: error: missing definition for symbol "_MTC_DoRew", required by "_output\main.o" error: missing definition for symbol "_MTC_DoStop", required by "_output\main.o" error: missing definition for symbol "_MTC_DoPlay", required by "_output\main.o" error: missing definition for symbol "_mtc_state", required by "_output\main.o" error: missing definition for symbol "_MTC_Timer", required by "_output\main.o" error: missing definition for symbol "_MTC_Tick", required by "_output\main.o" error: missing definition for symbol "_MTC_Init", required by "_output\main.o" error: missing definition for symbol "_MTC_DoFwd", required by "_output\main.o" error: missing definition for symbol "_MTC_FPSSet", required by "_output\main.o" error: missing definition for symbol "_MTC_DoPause", required by "_output\main.o" error: missing definition for symbol "_mtc_long_timeMSW", required by "_output\main.o" error: missing definition for symbol "_mtc_long_timeLSW", required by "_output\main.o" ERROR! Process terminated with status 1 (0 minutes, 1 seconds) 0 errors, 1 warnings It seems it cannot find the definitions in mtc.h Although they are just as they were when using Notepad++ and there was no trouble at all. I copy the start of main.c, and some parts of mtc.h //////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include "main.h" #include "mtc.h" //#include <cmios.h> //#include <pic18fregs.h> #ifndef _DEBUG_C #include "cmios.h" #include "pic18f452.h" #endif ------------------------------------------------------------------- mtc.h: #ifndef _MTC_H #define _MTC_H ///////////////////////////////////////////////////////////////////////////// // Global definitions ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// // Global Types ///////////////////////////////////////////////////////////////////////////// // status of MTC typedef union { struct { unsigned ALL:8; }; struct { unsigned RUN:1; unsigned PAUSE:1; unsigned START_REQ:1; unsigned STOP_REQ:1; unsigned CONT_REQ:1; }; } mtc_state_t; ///////////////////////////////////////////////////////////////////////////// // Prototypes ///////////////////////////////////////////////////////////////////////////// void MTC_Init(void); void MTC_Tick(void); void MTC_Timer(void); void MTC_FPSSet(unsigned char rate); unsigned char MTC_FPSGet(void); void MTC_ResetMeter(void); void MTC_SendMeter(void); void MTC_DoStop(void); void MTC_DoPause(void); void MTC_DoPlay(void); void MTC_DoRew(void); void MTC_DoFwd(void); unsigned int MTC_GetTimerValue(unsigned char rate); ____________________________ As you can see, mtc.h is included in main.c, an the functions not found by the linker are declared in mtc.h. So, it's puzzling me beyond my efforts. I know it must be some stupid thing I'm overlooking, but, well, I spent many hours and couldn't find a solution. Thanx for your wise advice Pablo

Yes, i did. That's the problem being among others who share your passions... You're original ideas stay only ideas. The "original" part it's usually left apart. ;) I'll see what comes up to my mind, I think i'll end up making an "it's-been-made-many-times" thingie, but by my own, at least! Cya, P

:D Isn't it already done? I mean, a Midi Router Midibox project is in the site afaik.. I would have loved to, but someone (you know who "someone" is, heh) did it first! What I'm planning to do is some midi realtime processor. Obvious idea, an arpeggiator, but I'll try to come up with some more midi-processing ideas. Well, ideas are easy to find (convert this to that, etc.), thing is they should be useful, right? ;)

Well, here it is. Sources www.giboon.com/pablop/midi_router/Sources.rar Full Installer www.giboon.com/pablop/midi_router/Setup_Midi_Router_V1.01.rar Full mabrymidi release, source codes, ocx, license, etc. www.giboon.com/pablop/midi_router/mabrymidi.zip This is not necessary if you use the installer, but this is the way its meant to be distributed, according to its license. The sources of the graphic controls is still to come. (I have to find the last version). Hope someone finds this useful, cya.

I'm a little late with this, you will have news soon. Cya P

Hey Stryd Yes, I think this is a good place for this thread, nevertheless misc is not very "exciting". :-) The Mabry MidiLibs are Free Software (I always mean Libre when saying Free), and so there wouldn't be any trouble at all in that respect. I think it could be asumed that I should be able to distribute the source code without a problem. I'll try to inform myself a little bit (want to read the GPL license during the weekend) and I suppose the app will be publicly available next week. BTW, what does "PDW" mean??? ;-) Cya Pablo Oh, I found it!, Google you mighty God. :-/ You mean "Package and Deployment Wizard"? Yeah, I can make an installation package with that. I actually made it, and the PDW puts the VB runtimes oleaut, etc. inside it...

Hello people, I've written a MIDI application some time ago, and although is not strictly related to the MIDIBox Project, this community has given me so much and I'd like to share this with you. The program is basically a MIDI Router and was written for a friend of mine, and is aimed to Live performances. Here´s a screen capture. It offers three "Slots", each of them can be connected to a different MIDI port or to different channels on the same port. Each slot is able to: * filter Midi events by pitch (to create keyboard zones), * filter Midi events by velocity (you could for instance stack different sounds at high velocity values, but play just one sound when the velocity sent is low) * filter modulation, pitch wheel, sustain, or other controllers. * add or substract a velocity value. * transpose notes up or down. * send a program change to the port/channel you designate. * send bender range message. They have also the possibility to midi-learn keyboard zones. (for the lazy ones) Each whole configuration can be saved as a preset (there are 127 of them) which can be named and you can copy one to another. Presets can be changed by sending the app. a program change. And that's the main idea, you are playing on your keyboard, and by changing your "sound" you will be able to send three program changes at once to your virtual instruments, and as explained above, apply all the filtering and changes the program is able to do. It is programmed in Visual Basic 6,and thus needs installation (VB6 runtime, an ocx for the customized buttons, and Mabry Midi I/O -open source- for accessing to midi ports). I would release the ocx for the buttons would be released as free software as well as the app. remaing all free software but the VB runtime. I've never released any software, and so, I'd like you to help me to do things the right way. Especially, VB runtime not being free software makes me wonder whether the whole thing can be released as free soft. One more thing, for routing MIDI to Virtual Instruments it's necessary to have maple virtual midi cable, Hubi MIDI Loopback Driver, or any other similar application. cheers, Pablo PS: I've read the stickies and know this post is not strictly a user project as defined here, it may even not be the place to post this. I hope no one gets pissed off! PS2: if anyone would like to try it, let me know.

Hola Eduardo, sí está bueno tener un congénere de estas tierras de la mala calidad, la baja tensión y el siempre bien ponderado "lo atamo' con alambre" :D ¿De dónde sos? Suerte con eso! Pablo PD: que los potes no lleguen a los extremos a veces, puede deberse a la baja tensión? o más bien otra cosa? pablopo@giboon.com

How bad are they?

Happy Birthday and long life to MidiBox!!! An applause to its father! Thanks TK!

Em.. ok, acabo de ver tus conocimientos, y entiendo que quizás no haya sido de mucha utilidad lo que te acabo de decir. Mis fuertes son justamente del otro lado, soy pianista, y trabajo con MIDI y audio desde hace 17 años, pero de electrónica toco de oído. Lo que sí, también soy de Argentina, ciudad de Bs. As. así que cualquier cosa, podemos pasarnos datos que nos sirvan. Abrazo, Pablo

HOla Edu, Mirá, no soy un entendido en electrónica, y quizás sea muy básico lo que te digo, pero, ¿Checkeaste que las soldaduras a los potes sean buenas? A mi me han traido problemas algunas que realmente no parecían estar mal. Otra cosa que en mi caso resultó problemática fue que yo usé terminales (no soldé) para los cables que van desde el AIN al Core y desde el AIN a los potes. Como antes, una mínima diferencia de resistencia, y empezaban a volverse locos. Por último, tuve un problema bastante extraño, quizás potes de mala calidad. Ya con todo lo demás estable, todos los potes, a veces, y sobre todo cuando los bajaba o subía muy muy lento, no llegaban a los valores límite de 0 y 127. Terminé decidiéndome a internarme en el Assembler para solucionarlo por soft. Creo que el código quedó bastante bien (a mí me funciona bárbaro). Escalo los valores para dejar pequeñas deadbands abajo y arriba, y para hacerlo lo hago sobre los valores que lee el pic en 10 bits, para no perder tanta resolución al escalar. Este es el thread con el código: http://www.midibox.org/forum/index.php/topic,11572.0.html y si quisieras ver a mi baby, está en http://www.midibox.org/forum/index.php/topic,10931.0.html como verás no soy un experto ni mucho menos en las técnicas del soldado, pero la maquinita quedó estable, y estoy muy contento con ella. Otra cosa, fijate que mis cables no son nada especiales, lo que sí, respeté el tema del "starlike connection", eso de no conectar más de 8 potes por cada línea de 5v y de gnd. Ojalá que sirva y no sean pavadas lo que estoy diciendo. Saludos, Pablo

Hello people, I have finally solved the pot trouble. The fact that some pots didn't reach 127 was a hardware problem, but what really was awkward was why they didn't reach zero, sometimes. That happened with ALL of them, and it did happen when I moved the pots SLOWLY down. It never happened in any pot when moved quickly down. Many other tests done, I concluded that it was not a soldering problem. So, having no clues for something that puzzled me, I opted for the software solution. I modified the MIOS_AIN_NotifyChange in main.asm (mb64) in order to have a small dead band up and down the pot and sliders way. The deadband is really small (32 of all 1024 steps in a 10bit ADC conversion), but was enough to fix the issue. Nonetheless, the code is adaptable to greater deadbands. I'll paste it here. It's full of comments, heh, I think it's more comments than code, actually. I wrote most of them to help myself in tracking what I was doing, it may be useful to someone, or maybe it's useful for me that someone takes a look at it. I'm really happy because it works, and because I learnt a lot while doing it. I did various versions, and this is the best of them, because it does the scaling from the whole 10bits the Pic delivers. That means that MB64 still doesn't skip any value from 0 to 127, and that there are not "difficult" values to be output. Here, the code: ;; -------------------------------------------------------------------------- ;; This function is called by MIOS when a pot has been moved ;; Input: ;; o Pot number in WREG and MIOS_PARAMETER1 ;; o lower byte value in MIOS_PARAMETER2 ;; o upper byte value in MIOS_PARAMETER3 ;; -------------------------------------------------------------------------- USER_AIN_NotifyChange ;;Reading= 1023 (max) ;;Scaled = ( Reading - 31 ) * (33 /32). I'm dividing by powers of two, to use bit shifts, so the next smaller ratio would be (65/64). ;; That would permit a smaller deadband, but maxreading (1023)*65 goes beyond the 2^16 (two byte) limit. ;;I will split the 31 values deadband in 16 low and 15 high. ;;Easier just to take into account the low deadband here, and limit higher than 127 values at the end of the process ; * if reading < (16) then reading = 16 ; * for reading to be < 16, MIOS_PARAMETER3 must be 0, and MIOS_PARAMETER2 <=16 ; *if MIOS_PARAMETER3 not zero, goto CONTINUE1 movlw 1;; w==127 IFGEQ MIOS_PARAMETER3, ACCESS, rgoto CONTINUE1 ;*if MIOS_PARAMETER2 <=16 then MIOS_PARAMETER2 =16 movlw 16 ; IFGEQ MIOS_PARAMETER2, ACCESS, rgoto CONTINUE1 movlw 16 ; movwf MIOS_PARAMETER2 CONTINUE1 ;----------------------------substract 16 ;I substract 16 to put values on the range 0 - 1007. (That's an 8 bit substraction from a 16 bit value. I took a model of a 16bit substraction and optimized it a little bit) ; movf SourceL,W ; ;;;;;;;THIS IS THE MODEL 16 bits--------------------- ; subwf DestL; ;;;;;;of 16 bit substraction ; movf SourceH,W; ; btfss STATUS,C ; incfsz SourceH,W ; subwf DestH ; -------------------------------------------------------------------- movlw 16 ; --------------------------------------------- subwf MIOS_PARAMETER2, F;substracts 16 from MIOS_PARAMETER2 movlw 0 btfss STATUS,C ; if result was positive or zero, SKIPs next instruction decf MIOS_PARAMETER3, F; if negative, we need to substract 1 to the upper byte. ;; NOT NECESSARY________________ I'll limit output to 127 after calculation is done ;;* if reading > (1023-15) then reading = 15 ;; ______________________________ ; * ---------------------multiply reading by 33. ; Result = upper byte*33+lower byte*33 (upper byte in MIOS_PARAMETER3 and lower byte in MIOS_PARAMETER2) ; * I know MIOS_PARAMETER3 will never be > 3 so, 3*33 = 99, I don't need to care about PRODH movf MIOS_PARAMETER3, W mullw 33 ;;movff PRODH, TMP1 -----------> Don't care about PRODH movff PRODL, TMP2; So, I have MIOS_PARAMETER3 * 33 in TMP2 movf MIOS_PARAMETER2, W ; Now, I multiply lower byte *33 mullw 33 ; Result in PRODH:L ; -------------------------------But I will have to divide by 256 (see below) so, I don't care about PRODL, now. ;movf PRODL, W;----------PRODL would hold a resolution I won't use ;addwf TMP2, F ; movf PRODH, W; So, let's add Original upper byte * 33 + the upper byte of the product of (ORIGINAL lower byte*33) addwf TMP2, F; ; ----------------------* divide by 32. ;I should immediately divide by 8, so that's a 256 divide, I can Just keep my upper byte. ; Keeping just the upper byte of my multiplication implies dividing by 32 and then by 8. That's just what I needed movff TMP2, MIOS_PARAMETER2 ; ;------------------------Now, let's limit output to 127 ; * if MIOS_PARAMETER2 > 127 then MIOS_PARAMETER2 =127 ; If MIOS_PARAMETER2<=127 then goto CONTINUE 3 movlw 127;; w=127 IFLEQ MIOS_PARAMETER2, ACCESS, rgoto CONTINUE2 movlw 127 movwf MIOS_PARAMETER2 ;MIOS_PARAMETER2=127 CONTINUE2 ;; FIN PABLO, end of my code ;; now: pot number in MIOS_PARAMETER1 ;; 7-bit value in MIOS_PARAMETER2 #if DEFAULT_ENABLE_DRUMS ;; if drum trigger (MIOS_PARAMETER1 < 8) : ;; branch to the DRUMS module movlw 8-1 IFLEQ MIOS_PARAMETER1, ACCESS, goto DRUMS_AIN_NotifyChange #endif ;; else continue with MB64 pot handler ;; (expects number of pot in WREG) movf MIOS_PARAMETER1, W goto MB64_POT_Handler

Thank you people for your fast and thorough replies. I have been working on it, and found some issues, resoldered some joints, etc. Still have some minor problems in one or two pots, but I think it´s the pots themselves. I'll post any good news. See you around, Pablo

Hello, I'm having this problem, sometimes the pots only reach to 126 (or even 125) as the max value, and 1 as the min value. It is an intermittent problem, I mean, maybe you use it one day and everything's fine, and next day the problem appears. It affects several pots, and I didn't find a pattern. Sometimes some of the pots are affected, sometimes others. One thought is that maybe it has a relationship with the AC supply (I don't mean the PSU, but the 220v I get from the wall outlet), since in the neighborhood we have lower voltages at times, I mean, lights go dimmer. I don't know, anyway if this could be correct, since I understand we are using a stabilizer in the core's circuitry... My question is whether there is a software solution to this, scaling the readings, not the way mb64 already is able to do (limit the same voltage reading between a reduced range), but exactly the opposite. I've been searching in the forums, and found some info that relates to this sort of scaling, but in general it's coded in C, and I would need to modify MB64 software, which is written in Assembler. I also read that this kind of calculations which involve division could slow things down more than acceptable... Any clues will be greatly appreciated. Regards, Pablo

Sorry I asked offtopic. I must have been too sleepy when making this post. I meant to post it in the Midimerger 16f88 thread. ::) So offtopic it was that I couldn´t find your answer. :-[ Heh! Thanx stryd. Cya

Yeah, stryd, I´m not ignoring your answer ;) But, your answer is not very clear for me. I know that it is possible to use MBHP + Adapter to burn the 16f88, but what about JDM + Adapter? As far as I can see, the adapter has been designed, as its name states, to work with MBHP, and that´s why I'm in doubt. If you can be specific to this point, I promise my questions about this will stop abruptly! ;D Thanx again P.

Hello everybody, I'm planning to build Midimerger, 16f88 version. I have already built a JDM burner a long time ago, and don't have MBHP. Is it possible to program 16f88 with JDM and the adapter designed for MBHP? Thanx a lot, Pablo

Hello everybody, I'd really like to build this one (finally got the 16f88). Could someone please tell me if it is possible to burn the 16f88 with JDM? I've seen http://www.ucapps.de/mbhp/mbhp_burner_16f88_adapter.pdf, but, Is that adapter specifically made for MBHP_Burner, or can it be used with JDM? I'd thank very much anyone who could confirm me this before I start building the module, which I want to incorporate to my MidiBox64. Pablo.

Thanx, tilted. Yes, I was talking about that adapter when I said JDM + adpater. So, it works both for mbhp burner and JDM burner? Good! Just as a commentary: I can't seem to find 16f88 at the stores here. It's far easier to find 18f452 or 16f877... I suppose 16f88 is a newer MC?

WOW nils that was lightning FAST!!!! :o :D I was studying the possibility of programming the 16f88 with JDM, and as far as I can see, all of the needed pins in 16f88 are supplied by JDM. Is that enough for JDM to be able to program it? Btw, ICProg has 16f88 in its list.