All Activity

thank you for your numerous answers, i will try to get it right when i find the time, br ranger930

Sorry to revive this long-dead thread after almost 13 years, I had MistralXG project on my to-do list for more than 10 years and I finally got to make the PCBs. Alas, meanwhile, Stever's website is down and Wayback Machine (https://web.archive.org/web/20210206041027/http://www.grapevyne.com/pic.projects/) only stores the primary site, not the linked images or other files. That means that I'm left with no firmware - anyone still has the binary HEX for PIC 18F2550 with (updated, based on the archived webpage contents, it should be v1.05)? Or even the sources, maybe? Thanks, freddy

i jst saw that tk answered the same question regarding mios8. The same should apply here. It works alsmost like the code i suggested above, with one big difference: I was suggesting a global variable. That does work, but is usually a good idea to avoid. The neat thing i just learned, and since we are both learning i like to share this:: What is a static variable? It is a variable that will be created once and not change over function calls. So if the code below would read "unsigned char ain_sent = 0;" without the static keyword, the variable would be recreated every tick and midi would be sent every ms. With static, this variable will be created once inside the function block (so it is not polluting the global namespace). Next time it will be 1 and the condition in the if statement will fail. ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) __wparam { static unsigned char ain_sent = 0; if( ain_sent == 0 ) { unsigned char pin; unsigned char num_ain = MIOS_AIN_NumberGet(); ain_sent = 1; // only sent once after startup for(pin=0; pin < num_ain; ++pin) { MIOS_MIDI_TxBufferPut(0xb0); // CC at channel 1 MIOS_MIDI_TxBufferPut(pin); // pin number corresponds to CC number MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); } } }

it´s in the manual under din http://midibox.org/mios32/manual/ I cannot try this right now, but i would assume something like int my_button = MIOS32_DIN-PinGet(0); will save 1 or 0 to the variable my_button. But again, if you have a normal "digital" push button this will only work while the button is actually pressed.

s32 MIOS32_DIN_PinGet (u32 pin) With this function you gen poll the state of a din pin, eg when using switches in your setup.

The thing is: With all digital inputs you cannot get any state UNLESS a button is pressed. It would be different with actual switches that hold their state low or high. But a button or encoder has no permanent state. When you press or turn it you get a pulse that will trigger the mios callback routine. Thats it. So the direction you should be looking is to save the last state of all buttons and encoders in your code, and load it on startup. Unfortunately i am still a noob, so i cannot really tell you how to do that. But there is some example code for sd cards and bancsticks.

Excellent ! Great news ! :-)

To use Studio on newer Ubuntu Desktops you need to install the old libwebkit2gtk-4.0.so.37. To do so create a sources.list file for apt containing the following line: deb http://gb.archive.ubuntu.com/ubuntu jammy main And install the lib. sudo apt update sudo apt install libwebkit2gtk-4.0-dev After this delete the sources.list file. More infos on https://www.weigu.lu/music/midibox_hp_2x2/index.html

II replaces the remaining ICs and its working! Woohoo!

Reflowed the ttasnsistors on the top side and now I am back to 12 LEDs on. I'm assuming the LEDs shouldn't be on, but otherwise that feels like an improvement as it means I get mattias switch events for 12 of 16. I'm also getting events for depresses on the right 4 encoders although they seem a bit random in the actual event details. I've also replaced IC2, IC3 and T3 based on advice from ChatGPT but that made no difference.

Thanks, perhaps I'll shoot over to the UK ;-) I've rebuilt the core board now and I'm back where roughly where I started. At least I feel confident I have eliminated the core as a possible cause; the problem must be with my LeMec board. Done some more reflowing on that board and now: - just 4 LEDs light up on power up now - all encoders generate counts when rotated but not depresses - botton left 4 buttons generate no events; bottom right four are working - mattias switches generate events for the four that have illuminated LEDs but not the rest

Update: MIOS Studio shows each button press with the Quad Genesis software so only LED testing is necessary. Hi everyone, I am half way through soldering the Front Panel PCB for MIDIbox Quad Genesis. I am finding that the SMT shift register ICs and SMT Resistor arrays are difficult to solder as the pads could be a little bigger as Sauraen mentioned in the wiki page and my SMT soldering isnt always accurate. This means that the connections can be unreliable and I am re-soldering each IC in order. I would like to test each LED and Button before soldering the remaining components (LEDs that go through the Front Panel, Numeric LED displays and Encoders are all thats remaining.) I have flashed MIDIbox NG to the core and can do some rudimentary tests such as lighting up all Red LEDs with the command "set dout all 1". I would like to be able configure the LED and Button Matrixes in MIDIbox NG so i can test each button and LED individually. This would really aid the troubleshooting process, verify each matrix is working before moving onto the next and will aid future builders also. If anyone could help me get started i would really appreciate it. You can find the DOUT matrix map here: http://wiki.midibox.org/doku.php?id=mbqg_fp#dout_matrix_map Thanks for your time, Smithy

I would like to ask my question more specifically: How can I get Mios to start the program sequence with which all inputs ( analog and digital ) are read ( without having pressed a button or turned a potentiometer ) ? This is only necessary once after the program start. Where should I insert a program code? I have already searched the entire forum and the repository for help, but have found nothing. Please help me. I have a test setup with buttons, potentiometers and LEDs and the respective inputs are read after pressing a button or turning a potentiometer. Mfg ranger930

Ah, ok - apologies - was just trying to help with some suggestions and was commenting on the shared photo. As I’m sure you know, you can often reroute lifted pads by using kynar wire or similar.... Reason I asked where you lived was that I was going to offer to look at it for you if you lived near me and wanted to drive over (shouldnt need to be said, but for clarity, not for any remuneration - just to be friendly. I have no interest in taking money for any DIY stuff - it’s just a hobby). I was making a (very) wild guess that is completely wrong that you were in the UK - again, apologies for any assumptions.... good luck.

At this point I don’t think the solder you see is representative of where I started. I have reworked the board at least once, in some cases multiple times, over the past 3 weeks, and yesterday before taking this photo just fluxed everything and retouched it. It’s looking much worse than when I started, but I am just throwing stuff at the wall at this point to see if anything sticks. Right after this I decided to replace the ICs on the core and one of the tabs got damaged so I now need to replace the PCB and rebuild the core before doing anything else. And yes, I am working with a microscope. I live in Seattle, not sure what that has to do with anything though!

Hi - 1. Midiphy people will send you snippets of the schematic if you ask (sub-optimal, I know, but better than nothing. When I built mine, the lack of schematics was a major concern for me too. Looking at the midibox schematics can help understand the midiphy reworking - look at the DIN shift registers and anything in that chain first for the inputs - it should be pretty solvable). (For background - I’ve built a midiphy seqv4+ and two seqv4s, one of which is very fully loaded) 2. There are issues with your soldering (sorry !) but even in that one photo there are loads of suspect solder joints. Type of solder, heat, flux, technique, etc can all contribute ! (Sorry to be negative!) 3. Do you have any magnification ? (Seeing what you are doing makes a massive difference - I use a stereoscopic microscope with a decent working distance - it’s pretty essential for me to build things reliably) 4. Where do you live ? (Your online accent implies UK !)

Hi all I am having a very hard time making any progress with a problem with my left LeMec board. When I first assembled the JA and LeMec boards and tested them, everything was working on JA board and the two LeMec boards except: - encoder 3 on left Lemec board was not registering depress events - encoder 8 on left LeMec board was generating garbage counter values when rotating. Since then I have gone backwards and been stuck for over several weeks with no progress. I first tried to solve the issues above with reflowing the ICs on left LeMec board but that didn't help. I then reflowed the ICs on the core, and after that, I am in this worse state with left LeMec board - encoder 8 does not register turns - none of the encoders are registering push events - 4 leftmost buttons on are not registering push events - 12 of the 16 LEDs light up immediately upon powering up as seen in attached pic I haven't bothered testing the Matias switch events as this is enough wrong already I have reflowed the ICs, diodes and transistors on that board multiple times, and on the core board too, and nothing is changing. The only advice I get from Midiphy is to reflow/check for dry joints/shorts which I have done over and over. It would help to have proper circuit diagrams to try to chase down likely culprits instead of messing with everything all the time. If I just connect the JA board to core and run the seq_l test, that is still testing fine for everything. The right LeMec board is out of the picture for now; I think it was all working well at least. Any help will be most welcome as I am close to assuming I just have to abandon this and write it off as a very expensive exercise in frustration and futility. Thanks Graham

I'd love to experiment with the STL file(s) if you're willing to share. A lovely build, with some nice innovations. Cheers!

i am also wondering about running a function once. I was under the impression that this could be done within the init function, but that does not seem to work. What does work (please tell us if this is not the way to do this) is defining a variable like: u8 has_run = 0; then in the background task you can check for has run == 0, do your stuff, set has_run to something different than 0. Your code inside the if statement will never run again... if (has_run==0){ do everything you want; has_run = 1; }

I assembled one more unit just in case if somebody wants to take sammichSID :)) Now in metallic-white acrylic case. Fully working and tested, comes with a simple PSU. Also the price for enclosure now is a bit more reduced so in total with ArmSID chips the synth can be offered for 160 EUR including shipping (within EU and UK; USA - negotiable)

you can of course fit it with heatsinks, but it's not necessary. It is normal for the 6581 to get warm/hot, but it is also in their nature to run at such temperatures. if i read it correctly, then there are only 8580 in use and there also a fan installed. I've never had to worry about anything like that (fan/cooler), nor have I ever had any problems during operation. they break when handled incorrectly (ESD). Note the fact that a heatsink, fan or whatever you use is fine, but that is never installed inside an original c64. ... and yes, your device does look cool.

Did you have any better result with the 5v version?

Dear Forum, like the titel suggests. The TLC5947 can be bought in ready soldered modules and was suggested to me for dynamically driving solenoids, as an alternative to dac channels i proposed in my other thread. Reason is the parts count, so before i build 24 ladders with analog shaping and drivers i thought i should maybe look into pwm once more. So the question is if from within an mios32 application, i can use the SPI interface. If so i would try to code some form of "hello world" example with the pwm module first and then go from there. Also is it fast enough? I need a pulse of less than 5ms to minimize the on time of the solenoids and give good response with pecussive instruments. Has anyone done something similar? Thanks!

hello i have a problem with switching patterns via remote midi cc 112-115 and time clock. Mbseq and Octatrack (via TM-1 ,is Elektron made usb to midi interface for faster(10x) midi transmission ,Tubo mode is ON) are connected to my computer via usb. in my computer i am sending Mbseq midi clock and notes on channel 1 to play samples in Octatrack on channel 1,Ocatrack sample player is set to time stretch mode so dependent of midi clock Mbseq patterns are controlled via launchpad via MIDI in 1 ,i made it so that via top row buttons i can switch all four patterns ,sort of groups so under each of eight buttons i have set of four Mbseq patterns ,so e.g button 1 mbseq patt 1,1,1,1 ,button 2 mbseq patt 2,2,2,2 etc.. i also can recall individual patterns with launchpad mbseq is set to -track sync steps per measure 32 -patt change sync each 8 steps -pattern change sync on, -restart all tracks on, ok so i have simple pattern with break sample in time stretch mode , when i am starting press constantly on my launchpad only pattern 1 button on my launchpad ,pattern is being recalled every 8th step as expected sample is playback as it should but,when i press my launchpad group button to recall all four patterns on mbseq ,what happends is pattern is being recalled,but just when recall happends midi clock slows down , and then comes back to normal when i stop pressing and because sample that is played by OT is in time stretch mode,so dependent on midi clock this is why i can hear that, also if i recall independently two patterns i can hear that but little less then when all four are recalled i also checked with monitor and i am sending clear cc 112 ,113 ,114 ,115 so no extra garbage is getting there this situation does not occur when i turn off Turbo MIdi Tm-1,or when i recall only one pattern,or when i recall pattern from MIDIBOX it self via panel, or when sample is not in time stretch mode. i am attaching two example recordings, so you can hear what happends for your self, one is just wav from octa,other is from ableton -in octa example in the middle of first part i am starting to recall all four patterns constanly with Turbo Midi off,and sample is playing correctly in the middle of second part i doing same thing but with Turbo Midi on,and clearly you can hear sample speeds down for a moment -in ableton example once im starting to recall all four patterns you can see that bpm counter is going from 154 to 147,and you can hear same playback speed is dropping so in conclusion 1.i think is possible that midibox gets little wierd when more patterns are recalled and midi clock is getting bit flaky during switching ,however internal Midibox Info does not shows any drops ,CPU Load goes 10% higher 2.maybe this is somehow regulated by 31250 midi bus speed and is not audible when using din 5 ,but becomes a problem when going over usb and bus speed is higher . thank you bests midiboxseq switching patterns via midi remote .wav Screen Recording 2025-05-02 at 15.53.13.mov

hello there i just experienced loss of my patterns data after i did SAVE and changed pattern via midi cc# 112-115 i am controling patterns with external controller,so i pressed SAVE "Complete Session stored" ,and right after i changed one of the patterns via external controller, then mbseq hangs,and after reboot patterns where gone. maybe mbseq does not protects save operation and allows to execute program change via midi cc's ,thus leading to data loss ? i had backups so it was ok for me but i can imagine when one does not have bests