Hawkeye

Hola, after playing a game of Turrican I on the good old Amiga (and incidentially pressing "ESC" while having 23 extra lives, no joke, searched for the pause button :-)!), i managed to be somehow inspired and record a new retrowave tune in two hours :-). Only six tracks (+drums) occupied on the MBSEQ, but a lot fun was involved, so as usual, many thanks are in order to TK. for the AWESOME hardware (MBSEQ+MBSID)! :-D And many thanks for the Anushri PCB + preprogrammed microcontroller, Shuriken! It is a really nice piece of kit! :-) Thanks for watching and listening, Peter

Ok, a few hints, we will get this working at some point in time! :-D You might need to call "sudo" ahead of all commands listed below, depending on your *nix. bzip vs gzip bzip is a version with better compression efficiency than gzip - thus the extension .tar.bz2 to unpack a .tar.bz2 do a bunzip2 <filename> followed by a tar -xvf <filename-of-resulting .tar file> Now, unpacking should work and you can follow the toolchain installation guide again. Make sure you unpack into the right directory, where your PATH and set MIOS32 variables point to. arm-none-eabi-gcc To see what is going on in the build process, and why it fails (especially, where arm-none-eabi-gcc is being expected), in the midibox_seq_v4 directory, perform a make --trace this will show the paths it does try to load. On my machine, it displays something like Creating object file for seq_ui_pages.c arm-none-eabi-gcc -Wp,-MMD,project_build/core/seq_ui_pages.dd -g -Os -DGCC_ARMCM3 -L /usr/local/stm32-f4/arm-none-eabi/lib -DMIOS32_PROCESSOR_STM32F407VG -DMIOS32_FAMILY_STM32F4xx -DMIOS32_FAMILY_STR=\"STM32F4xx\" -DMIOS32_BOARD_MBHP_CORE_STM32F4 -DMIOS32_BOARD_STR=\"MBHP_CORE_STM32F4\" -DMIOS32_LCD_universal -DMIOS32_LCD_STR=\"universal\" -DUSE_STDPERIPH_DRIVER -DUSB_SUPP... This means, it tries to load arm-none-eabi-gcc directly from the $PATH to show, what is in the path, perform a set | grep PATH This will show you something like this: PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/local/stm32f4/bin Finally, try to call arm-none-eabi-gcc directly from the command line. The expected behaviour is, that is says, "no input files". [hawkeye@psy /home/code/midibox/mios32/trunk/apps/sequencers/midibox_seq_v4]$ arm-none-eabi-gcc arm-none-eabi-gcc: fatal error: no input files compilation terminated. I'd say, you unpacked the arm-none-eabi-gcc somewhere not in PATH, even when the "find . | grep ..." found it in /bin, it is probably some kind of stale softlink and not able to be directly executed. Please try again by following the unpacking procedure as stated in the toolchain installation guide (now with bunzip2 unpacking) and try again. If it fails, list the PATH, and try to call arm-none-eabi-gcc directly and tell us, what the error message is. If you are desperate and are sure you unpacked it right, you can also call rm /bin/arm-none-eabi-gcc This makes kind of sense, as the arm cross compiler should not reside there, but in the path you unpacked it to. Your *nix will follow your PATH from left to right, so it will try to load from /bin first - and if that version fails, you can install as many crosscompilers as you like, calling it will always fail. So the removal with "rm" is recommended in this case (it might break an os - installed package of the cross compiler, but never mind :-)). Many greets and have a nice weekend! Peter

Do we have a "list of compatible/tested cards"? Have tried a lot of cards and not had real issues, some were slow, but all worked... it would probably be better to create a blacklist of known-problematic ones instead of a whitelist listing all :-) But even the blacklist should probably also be validated by other users, as very often there might be some build problems, e.g. unstable power supply, bad soldering, etc... Many greets, Peter

Yes! We might make a *nix user out of you, after all! :-D That problem should be solvable. Here is a small shell trick: if you are looking for something, go to the / directory and type cd / find . | grep "arm-none-eabi-gcc$" that should list all files that contain the "grepped" string arm-none-eabi - the $ is the end-of-line marker, looking only for strings that end in that word. Please post the output. My guess is, that you installed it somewhere out of your $PATH How did the installation of the gcc-arm-none-eabi... bz2 package as documented in the linux toolchain page fail? Many greets, Peter

Good job! :-)

For moar bling and a bit of brass look, you could go for gold aluminum knobs like this one: http://www.musikding.de/Aluminium-knob-15mm-gold-6mm-knurled-shaft Maybe the "knurled shaft" is not the best thing, but there might be other knobs like this one there (also with a smaller diameter and no indicator, if possible). You probably also need VFDs for full steampunk look! :-) Many greets, Peter

You are welcome! But wow - no clue! Never seen this before, but never built on windows.. Really, a small linux on a memory stick is a nice thing to have! :-) Maybe others have some ideas regarding the last errors. We made some progress, but not enough, yet... Many greets, Peter

Congrats, looking great! Good idea to get it lasered from bamboo! :-) Many greets, Peter

Hmm... earlier on, you posted you got this output: C:\MIDIBOX\Mios32\trunk\apps\sequencers\midibox_seq_v4>make Makefile:150: /C/MIDIBOX/mios32/trunks/programming_models/traditional/programming_model.mk: No such file or directory Makefile:153: /C/MIDIBOX/mios32/trunks/modules/app_lcd/universal/app_lcd.mk: No such file or directory was this in the normal command shell? This had the trunkS problem, but otherwise looks good. because the current output Lamouette@LAMOUETTE-PC /c/Midibox/mios32/trunk/apps/sequencers/midibox_seq_v4 $ make Makefile:150: /programming_models/traditional/programming_model.mk: No such file or directory the whole path ahead of /programming_models is missing. It looks like your environment variable MIOS32_BASE is still not set. Or that I gave you the wrong tip of switching to the msys console. Or the msys console does not honor the paths set in the windows preferences, which might be the case. Can you try two things? a) retry in the command shell of windows b) in the msys console, do not write set MIOS32_PATH=/C/Midibox/mios32/trunk but instead write export MIOS32_PATH=/C/Midibox/mios32/trunk for all the other environment variables as well... and then retry to "make". Good luck and please report back! Peter

Oh man, did not nearly get enough sleep in the last time :-) And a very good find, EsotericLabs! I just blindly copied and pasted the error line, without checking the path :-), but now am confident, EsotericLabs has found the problem :-) --> Please recheck your MIOS32 variables, you set in windows, according to the wiki. I have a feeling, you specified "trunks" somewhere within the MIOS32_PATH. <-- Also, the command to set MIOS32_PATH manually in the console should be "set MIOS32_PATH=/c/midibox/mios32/trunk", not "set mios path..." or "set mios_path...", uppercase/lowercase is important, spaces are not allowed and you need to set the 32-bit variables, i.e. you do not need to set MIOS_PATH, as you are building for the new 32-bit platform, follow the mios32_toolchain tutorial and set it in the windows preferences. Methinks you just need to kick the "s" out of "trunks" in your MIOS32_PATH :-): http://www.midibox.org/dokuwiki/doku.php?id=windows_mios32_toolchain_core (you also only need the mios32 directory on your harddisk, as you are only building for a new 32-bit core) Many greets and good luck! :-) Peter

Yes, the recommendation to go to a linux VM (or a parallel installation on a memory stick or partition) is very good :-) Other than that, in the msys console, if you do a ls /C/MIDIBOX/mios32/trunks/programming_models/traditional/programming_model.mk does it show the file? If not, your installation directory is wrong. That's what the first error is about, it cannot find the file listed above... Many greets, Peter

Hm, that sounds indeed very strange. You'll probably have to open her up again, and examine the section around the power-in plug and power switch. It sounds like some (quite big) soldering problem there... You can also take photos and post them here (frontside and backside, high-res), if you want people to look at it. Good luck and many greets! Peter

... have you set the other environment variables, as well? for lpc17: set MIOS32_GCC_PREFIX=arm-none-eabi set MIOS32_FAMILY=LPC17xx set MIOS32_PROCESSOR=LPC1769 set MIOS32_BOARD=MBHP_CORE_LPC17 set MIOS32_LCD=universal am not a windows user, but methinks you should also not call "make" from the windows console, but from the msys console, I think, only this one will properly resolve paths like /c/... to map to drive c: (this explains the first error). Many greets and good luck! Peter

Hi there, unfortunately no news - afaik the IPB-Forum tech support did not report back - the gallery repair process crashes, when it is launched, and we would basically just have to do a lot of work by hand (editing and saving all gallery images). Unfortunately, this also cannot be scripted very easily, so we are currently stuck (or would need to invest a lot of time). For now, hoping for a new version to resolve the problem. Many greets, Peter

Thanks for your insights and many greets! Bye, Peter

Hi Ixox, great you got it working and that the old post was maybe of some help! I've still not fully understood what causes the incompatibility - i need the exact code as posted for the 4x20 VFDs, but found it only out through trial and error - it would be so nice to have a general solution working with the standard CLCDs, OLEDs and VFDs :-). Did you get any more insights when hacking your driver? Many greets! Peter

Looking great! If you think the datawheel is sitting a bit high, you can shorten the shaft (encoder shaft or datawheel shaft, depending which one is longer). It is no problem to lower the datawheel by about 5 millimeters using this method. Many greets and enjoy! Peter

Yay! Congrats to these ALPS encoders, you'll love them, even if soldering was a bit of a pain. Cool, that they also fit into your panel well. Many greets, Peter

If you are looking for "switchability", there is also a quite cheap alternative to powered usb hubs with switches - just use usb cables with integrated power switches :-) https://www.adafruit.com/products/1620 (These are also available with a mini/micro usb socket) Then you can power from any (chinese) USB wall wart adapter (rated at 5V/1A) you may have lying around... Not that this is the recommended way to obtain clean 5V, but it is cheap! :-) Many greets, Peter

Also check for a stable power supply - these Raystar OLEDs have some trouble, if there is some noise (e.g. from a cheap switching PSU) on the line. How do you power your SEQ? USB? You might change the USB-cable or the USB power supply for a test... Many greets, Peter

Are you using a standard init patch on the MIDIbox V2? MBSID V2 allows free controller assignments to velocity, modwheel and aftertouch, maybe it is somehow connected to the filter? Can you load up the standard MBSID V2 patch bank and experiment with different patches? Does it happen everywhere? Many greets, Peter

If the added numbers are very small, don't worry too much, these might be floating point inaccuracies. It is important, that the drawing is precise to 0.05 - 0.1mm or so, the rest is quite irrelevant when lasering acrylics :-) Many greets, Peter

Yes! If you are missing that one connector and just can't wait to "fire her up", you can always solder in the required wires directly on the CS board (and add an IDC plug on the other end of the ribbon wire for the core, so you can still disconnect things). You can measure with a multimeter in connectivity/beeper mode from the core and solder in the wires on the appropriate pins of the cs... This should be done in a few minutes... :-) Many greets! Peter

I've got some builds (e.g. old LPC17 based SEQ and the MBProgramma with Fairlightiiis encoder boards) working 100% alright with DETENTED1 and non-crossed 12mm encoder pins - somehow this works, as the encoder pulses are correctly recognized by MIOS. But recently, I ran into slight (almost unnoticable, but present) problems with a STM32F4 and the MBSEQ. That's why I remembered faintly norbim1's statement from a while back, tried the "pinswap" and can now only give the general advice to build it correctly from the beginning :-) Many greets, Peter