Gioxannes

Soon is turning into later. I only was able to finish the pots and push-buttons connections on the backside of the panel. But I am still there, and still thinking about my second box... ;)

I am not an electronics engineer, but I do know that LED's especially the bright ones, work as solar collectors producing electrostatic energy on incoming light. You may want to discharge them first before the power on by creating a shortcut first. The caps only backfire on you on this moment, as they are working as a battery. But again, I maybe all wrong. When they do not go on at power up, was that shortly after power down? What about running it in the dark for a try... The fact that they got fried even with proper resistors means we're dealing with abnormal voltages here. All the best... Gio.

Just to let all know, I am still there, but very busy doing other things on the moment. I hope I can inform you about some progress soon. Gio. ;)

For all others who are reading this here. THIS ONLY APPLIES FOR THE DINx MODULE. Don't try this with MF or AIN. (and please don't start a threat on DOUT).

The synthesizer board is ready. It only has one button: for On and Off. Midi in/out Ethernet Stereo out (48Khz, 16 bit) In the end I used init level 4 to adjust the startup sequence. This level is not used in Mandriva. The biggest work was going into fault recovery. What if something crashes? It has to recover by itself without rebooting, since this takes more than a minute (power down, 10 secs, power up 75 secs, something to work on in the future), and there is no mouse, keyboard or display connection. So, I had to write some script to restart jack after a crash, like fluidsynth, the midi I/O and to reconnect everything with everything afterwards. For Jack this takes 5 seconds, for Midi I/O less than one, for the synth about 3. However, under normal use it doesn't crash... (I had to pull some tricks to test it). Memory usage went down to about 100Mb as well. The OS with network, secure shell, alsa, and midi: 14 Mb Jack: 28 Mb fluidsynth with soundfonts: 60 Mb. Under heavy load (Rachmanicov Symphony with lots of speed changes) processor usage is around 30% and on a steady 45o celcius. Power consumption 75 watt, so lots of power left (150W ATX power supply). I am happy... :D

Oops. It looks like you are right. (and I am testing under linux) The midibox64e.ini only gets the encoders translated. The midibox64.ini only the pots. There is no output about buttons and leds. I don't know if that means that they are not processed either. For that i have to load them into the vmidibox tool. Later...

Je zou aan smash de leveranciersnaam kunnen vragen of de producent en dan bij de locale electronica zaak kijken of ze ze daar ook hebben. Advies: bestel altijd teveel! Die dingen kosten bijna niks. De mijne komen van Conrad (per 100). Succes. Gio

In short: I am a freelance engineer in computer science for my own agency. MUSIC As 6 year old young kid I sneeked secretly behind the electronic organ we had at home which my father used to play, and my sister was having lessons on. After a few weeks I got trapped and was assigned private lessons in musicology and organ playing till 12, which I absolutely hated. I did not do much with it till at 18 I got a 120 button accordion and picked up having lessons again for a few years. ELECTRONICS As a kid I developed an interest in micro electronics. Build my first radio at 12 and continued building (illegal) radio transmitters till 15 when at school they showed me a computer (Apple IIe, first program I wrote [10 PRINT "JOHAN"] [20 GOTO 10] ) I dropped electronics until I got my own Commodore Amiga (A1000) a few years later and started combining computers with music. At this time I build samplers and midi interfaces, even if I did not have my own keyboard. COMPUTERS At 22 I graduated as an engineer in computer science at the poly-technical university of The Hague. My graduation project resulted in a patent of pattern recognition, which is still in use today (for over 20 years) to find postal codes on pre-printed postcards and envelopes (Yes, those little dots in The Netherlands is my idea; No I did not get any money for it). After spending a few years writing educational software in Paris I moved into telecommunications and Oslo. I worked a s a trouble shooter in other peoples' software for over 10 years and got to see nearly the whole world. TODAY I live on a Greek Island in the Mediterranean see. Part time taking projects for the financial world, programming cryptographic security algorithms, which pays enough to spend the rest of the year spending time with my computers, girlfriend and nature. Gio.

More software progress. There were moment that I was really tempted to put all functionality into the sequencer I am working on (ExCuSe, see also http://www.midibox.org/forum/index.php/topic,13091.0.html). Like just read out which button/pot/encoder creates what event and do all the conversion in the sequencer, like bank changes etc). The advantage would be: - enormous programming flexibility - unlimited memory But this would be totally respectless to the work Thorston did, and I could have well just have bought a parallel TTL IO controller. Bottle neck was that to be able to switch a track on or off, I need 3 control-change messages on the touch of a button. And then I discovered META events! :) In the mb64e_meta.inc I had to do some changing (and quickly learning some pic assembly) to change a sysex stream into a cc-stream. And this is what it turned out to be: MB64E_META_Handler ;; branch depending on second meta event byte movf MIDI_EVNT1, W JUMPTABLE_2BYTES 17 ; 17 entries rgoto META_Send_ExCuSe_NRPN <--- replacing Handler_00 rgoto MB64E_META_Handler_01 rgoto MB64E_META_Handler_02 rgoto MB64E_META_Handler_03 rgoto MB64E_META_Handler_04 rgoto MB64E_META_Handler_05 rgoto MB64E_META_Handler_06 rgoto MB64E_META_Handler_07 rgoto MB64E_META_Handler_08 etc.... and later: ;; -------------------------------------------------------------------------- ;; This is a subroutine which sends a NRPN stream for ExCuse Sequencer ;; IN: parameter address in working register WREG ;; enc/button value in MIDI_SEND META_Send_ExCuSe_NRPN call MIOS_MIDI_BeginStream ; begin stream movlw 0xb0 ; send 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x63 ; send NRPN_MSB call MIOS_MIDI_TxBufferPut movlw 0x77 ; 118/119 track on/off sublw MIDI_EVNT_VALUE ; send button value, stored in MIDI_EVNT_VALUE (0/1) call MIOS_MIDI_TxBufferPut movlw 0x38 ; send 0x38 call MIOS_MIDI_TxBufferPut movf MB64E_CURRENT_BUTTON, W ; send button-id (note: bank access) call MIOS_MIDI_TxBufferPut movlw 0x06 ; send 0x06 call MIOS_MIDI_TxBufferPut movlw 0x00 ; send 0x00 call MIOS_MIDI_TxBufferPut goto MIOS_MIDI_BeginStream ; end stream and exit ;; -------------------------------------------------------------------------- Unfortunately I have not been able to test it yet, but it compiles great, and I am not expecting any problems with it. ;) Gio.

Cecem: I do not have the possibility to run it on a ATNGW100, but I do not see a reason why it should not work. For much as it is worth I can borrow a UBNT 600Mhz router and check it on that one. For the rest. Programming is my profession and more too often I start making things myself only to realize later that somebody else has already done it, or there are useful libs that would have been of aid. About the sequencer. I ripped out the composer command functions (a way of controlling the sequencer with combination of keyboard keys). The recording functions, the punch in functions and metronome functions. I added track looping and muting. Then it was time to add controlling the looping and muting through midi commands. As mentioned earlier I thought of NRPN events. But while having a better ,look at it I was really tempted to dump the windows compatibilty and move to using the ALSA library. Nice events parsers and sequencer functions. As well it has an easier way of connecting it with jack. Currently the software uses file-desciptiors and is actually using the OSS /dev/midi functionality to keep windows compatible. Then I discovered the virmidi module, capable of adding 4 extra raw midi ports to the computer. Linked them to the /dev/midi[1..4] directory and was able to use the ExCuSe in combination with jack. (Spending time looking for alternatives, does pay off). On the moment it is capable of handling 16384 tracks simultaneously with midi controlled track muting/playing. Tested with Serge's vmidibox. The project is starting to take shape...

Yep. You understood. :D SR9 is chip 9, and you only have 4. Only if you extend with two more DINx4 boards you have to call me again :)

Sorry for interfering. But... You can not stop turning halfway a click. So every click gives as a result 4 or 2 times an inc/dec. The resolution therefore is the same as inc/dec-ing with times 4 or 2 on a single click. The advantage of the above approach is that it goes more smooth, even if it is very fast. Is that right?

Yep, I'll be busy for a while :) For the time being I called the project ExCuSE. Since it is heavily based on the CuSE project (Curses Sequencer)

Hi to all! Like the "Midi router to share" topic, I placed this one here. I think we actually need a software folder for non-directly to midibox related projects written by the people here. I need a small and fast midi file player with midi-thru capability, and of handling NRPN events dedicated to the player. With the NRPN events I want to be able to mute/unmute tracks (NOT midi-channels), and everything else that comes to mind. It should be possible to run this on a machine as simple as 100mhz under window, or linux. Which I will put inside my synth. (I could use a 700mhz board if necessary, but I'll try to do it with the old one). So I decided to make it textmode based. Recording on the moment is not an issue. That I do with my desktop which is more powerful and running Rosegarden under Linux. So I spend the last two days collecting ripping, coding, compiling and I got something working. - based on curses/ncurses library which are free - using the CDK toolkit which is free as well - capable of handling up to 16384 tracks simultaneously - all the code I ripped was under the GNU license (version 2) Both the library and the toolkit are available under windows and linux. However I have problems with the midi-file reader. Does anyone have proper code (prefarably a single small routine) for reading midi-files. the one I have works, but does funny things if channel zero is specified. Is there interest in this project here? Are there suggestions? On the moment I am without a job assignment, so I got plenty of spare time ;) Gio.

Okay, I took the plunge and started writing my own dedicated midi sequencer for this project. I will start a separate topic for this "Light Weight Midi player/sequencer" After all, I am more a software than a hardware man. Remember: This is the sequencer that will go into my synthesizer box. Not the one I am composing with.

I meant two possiblities, not two things to do.

Ok, I had a look. (This is just dry code reading, I do not have the possibility yet to test these things in hardware). From the 64e.ini file # Navigation buttons, only available as MIDI triggers when they # have been disabled in main.asm 21 = 90 7C 7F @OnOff 22 = 90 7D 7F @OnOff 23 = 90 7E 7F @OnOff 24 = 90 7F 7F @OnOff This is your J4. As in the .asm you send me it says: #define DEFAULT_DIN_SR_PIN_01_08 2 #define DEFAULT_DIN_SR_PIN_09_16 3 #define DEFAULT_DIN_SR_PIN_17_24 1 #define DEFAULT_DIN_SR_PIN_25_32 4 #define DEFAULT_DIN_SR_PIN_33_40 9 Saying that your first chip (shift register) is allocated to pin numbers 17 to 24. There are two things to do now. 1. Change the main.asm to enable the pins and buttons (it's actually a buttons.inc file) 2. Change the pin numbering for the first shift register. I would go for number two. Remember that your buttons on J3 will get new numbers too! #define DEFAULT_DIN_SR_PIN_01_08 2 #define DEFAULT_DIN_SR_PIN_09_16 3 #define DEFAULT_DIN_SR_PIN_33_40 1 #define DEFAULT_DIN_SR_PIN_25_32 4 #define DEFAULT_DIN_SR_PIN_17_24 9 J3 is now 33-36, and J4 37-40. I hope this works.

No, there must be something wrong in the LCD PCB. Do you have the possibility to measure the Amp consumption on the feeding line? Preferably between the core and the LCD print.

Ok, I had a look at the code. I need a little more info. In short: Do you have buttons on J3 as well? In long: Can you tell me what exactly you have connected to which Jumper pins at J3 - J10 As you are an electronics guru I assume you have eliminated the possibility of a fried chip, broken power line, malfunctioning button, misplaced solder etc ??? You can send me your current .asm file as well as a private message and I will see what I can do for you. All the best, and don't forget to have fun! ;)

I indeed thought that considering your number of postings a newbie help with the link to serge's tool would benefit you. :-[ I am probably one of the best software troubleshooter on this planet, but my electronics is dusty so say at least. :P Even so, apparantly you earn your stars here with number of useless postings you make, so I better stay the newbie. ;) You can write your text in the personal profile under the personal picture, even if you do not have a picture. That's where I put my programmers status.

Hi Shaded, I am a newbie myself, but this I figured out already. You should use the tool made by serge (vmidibox64e_18f_v1_0c) on the download tools page. With a right mouse click you can edit every button. It runs under Linux too with the use of Wine. Gio.

Thanks SLP, I noticed something went wrong. Stryd_one suggested to have a look at banks. Now I am not so familiar with that, but I will look into it and let you know. Gio.

More progress, still no pictures :( Today uploaded MIOS and the midibox application to the core module (the PIC was already programmed with the bootloader by Mike, thanks Mike). An overview of the pitfalls. 1. My 5V stabilized power leaves only 2.74V after the rectifier and the 7805 (that I already expected). So I took out the rectifier and the 7805 and bridged the outer two pin-holes of the 7805. The elco and other caps I left in as additional stabilization. 2. MiosStudio found the bootstrap every two seconds, but failed to upload (unexpected bootstrap received). So I checked everything around the MIDI-in especially around the octocoupler. A tiny drop of tin had bridged two of the octocoupler pins, which I had to remove. Upload of the MIOS (v1_9f) went fine after this. I had to choose an application. The midibox64 can not handle encoders. The midibox 64e did not show any link to pots. And I have both! I had a short look at the Midibox16e, but was advised that this project is no longer supported. Then I discovered something VERY importent. AFTER an application upload, you still have to upload a settings file (ini/sys). This is not shown in the application development page. The settings in this file override the default application settings, like number of encoders and number of pots. The midibox 64e can handle both, so I had to upload this application. Uploading of the Midibox64e file went without problems. And the core started giving me lots of midi events since nothing else was connected. Hurray! Another milestone achieved. :D There is another confusion in the midibox64e_v2_b2 zip file. It does NOT contain a midibox64e.hex file! Apparantly the midibox64.hex has to be chosen, although I find this confusing. ???

AU-ssie A-dditional I-nfo C-onnect T-o G-round

There is a reminder picture (auaimbctg.pdf) showing a core umuxed and muxed. However on the muxed part there is text showing in the core "5 pots in unmuxed mode" while it is showing muxed to 20 pots. As well. Shouldn't Vs and Vd of J6 of the core be connected to J7 of the AINX?