TK.

I will have to migrate it first, this will probably take one evening (together with testing it with the original hardware), therefore please don't expect an immediate solution. However, there is no real blocking point, it will work on the Core32 If you want to get some more impressions about MIOS32 and C programming, work through the tutorial: http://www.ucapps.de/mios32_c.html The README.txt files are very verbose! I will also give you access to the hidden programmers lounge where you will find more informations, e.g. about toolchain installation etc (stuff which isn't documented on my website yet...) There are some errors, e.g. instead of J5-DOUT write J8-DOUT The AIN multiplexers have to be connected to J19 A BLM_SCALAR module cannot scan encoders, you will need dedicated DIN registers for this. When you compare the pin assignments (resp. signal names) between J8/9 of the MBHP_CORE and MBHP_CORE_STM32 module you will notice that they are identical. There are no special/new DIN/DOUT modules for Core32 - if people want to connect separate DIN/DOUT chains, they will have to split the cable, or they have to use SmashTV's special DIN/DOUT module variants, which are available since years. Best Regards, Thorsten.

No problem - you can leave out buttons and/or LEDs, there are no dependencies. :) Best Regards, Thorsten.

I'm interested in such an option as well since months, but haven't found an easy to handle solution yet, resp. a solution which fits with the available memory resources (that are very limited). This seems to be the best one so far: global knob assignments are hardcoded and defined in setup_*.asm files for people who really want to customize them (but I guess that most people will be happy with the default assignments) we need different assignments for lead/bassline/drum/multi engine global assignments are selected whenever the local (patch) parameter assignment is set to 0 - this means that they will be active for all existing patches (since this is the default setup anyhow) Now I only need some proposals for useful default assignments for Knob 1 (Modwheel) and Knob 2-5 --- anyone? Best Regards, Thorsten.

Something seems to be wrong with your MIDI interface - an error scenario which isn't detected by MIOS Studio. E.g., the high upload time of more than 800 seconds for MIOS (usually it takes ca. 10 seconds) indicates, that a lot of errors have already been reported by MIOS during the upload procedure (you should see some SysEx based error acknowledge responses in the MIDI IN monitor), but you haven't mentioned them... Do you own another MIDI interface that you could try? Best Regards, Thorsten.

Hi Rics, short question before continuing the discussion about the best approach: do you have programming skills? for 152 LEDs and 166 push buttons you could just re-use the BLM_SCALAR firmware (see http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2F) see also this special forum section for further informations: http://midibox.org/forums/forum/43-midibox-blm/ adding software handlers for encoders and pots isn't a big task, this would just be a 1:1 integration of existing programming examples: http://www.ucapps.de/mios8_c.html using the LEDs in matrix configuration has another big advantage: it decreases the power consumption dramatically! if you would drive LEDs with dedicated DOUT outputs, the MIDIbox will probably consume more than 1A and therefore cannot be powered via USB. at the end only a single core8 module will be required. another hint: if you have semi programming skills, I could also give you a similar BLM_SCALAR firmware for the MBHP_CORE_STM32 module - you only would have to adapt it for your own needs. eagle schematics to the .brd files at ucapps.de don't exist, as i enter the netlist directly into the layout editor (thats really a FAQ) best regards, thorsten.

hallo, robin fawell moechte etwas sehr aehnliches realisieren. am besten liest du dir mal folgende threads durch (doch vorsicht: bis zum ende, da sich konzeptionell immer wieder etwas geaendert hat - es wurde auch noch nicht implementiert). da bei ihm die tasten zu einer matrix geschaltet sind, lassen sie sich mit wenigen DOUT/DIN SRs scannen, dies waere auch bei deinem projekt eine elegante loesung. anzahl der DIN/DOUT: somit definitionssache anzahl der AIN: bis zu 96 gruss, thorsten.

without knowing the SD card error number (which will be displayed on LCD on failures) it's impossible for me to determine what happened. my proposal: as it seems that other users are not affected by such issues, try another SD card just to check if this is the reason. you can copy the files from one card to another with your PC. it would be interesting, if your PC can access all files... in the next MBSEQ release i will add an optional logging-mechanism for SD card errors (e.g. they could be sent to the MIOS32 terminal) to simplify debugging. a "cleared" message won't be displayed, but the actual operation (all steps cleared) will be performed. can you confirm this? is it really an issue that no confirmation message will be displayed? i think that too many messages will slow down operations too much. best regards, thorsten.

Hi, you have to consider that patch changes consume more than 1 mS (unfortunately, thats the disadvantage of the low-cost PIC) If too many patch changes are sent at the same moment, a MIDI buffer overrun can happen, accordingly some patch changes can get lost. Solution: add a delay between the patch changes. Alternative solution: if you need to change sounds very often, consider to use Multi Engine based patches instead, and assign the sounds to different channels and/or keyboard zones. This allows to realize typical C64-like tunes with many different sounds. Best Regards, Thorsten.

Hi, short answer: you are trying to upload a v1 library, this won't work, because the SysEx format has changed. Just upload the v2_vintage_bank.syx file which can be found in the preset/ directory of the midibox_sid_v2_*.zip release package. long answer (for the records): no, the firmware is clever enough to detect firmware dumps even during runtime! :) If you really need this: just send a ping as documented in the doc/mbsidv2_sysex_implementation.txt file of the release package please add the soundcard to the list if upload is still not working, but as mentioned above you are trying to upload the wrong files anyhow. if MIOS Studio detects a valid bidirectional connection, then MBSID should return an acknowledge message whenever a valid SysEx block has been received. but you are trying to upload SysEx blocks for another device - they are ignored (to match with the MIDI spec) please try the official vintage library first. there might be other libraries for v2 anywhere in the internet (or the forum) of course! the idea behind a device ID is *to be relevant* on SysEx uploads ;) Best Regards, Thorsten.

alright! :) somehow this makes sense to me: the power consumption depends on how many LEDs are active at once. Normally a single LED consumes up to 20 mA, but the current draw is already limited to ca. 10 mA via the 74HC595 and 220 ohm resistor. let's say you've connected 64 LEDs, makes up to 640 mA! So, your previous PSU was definitely not strong enough. during power-on it can happen that all LEDs are active for a short moment (ca. 100 mS, you won't notice this), as long as the 74HC595s are not initialized. putting a finger on a floating line (SC is floating during these 100 mS) will probably avoid that the LEDs are active during this startup phase, maybe because you are grounding a SC by doing so. however, good that you found the reason! best regards, thorsten.

thanks for the compliments! :) you can customize the menu pages in cs_menu_tables.inc http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fcs_menu_tables.inc the format should be easy to understand, especially if you only want to shift/swap some entries. thereafter just rebuild the firmware and upload the new .hex file best regards, thorsten.

it should tell you "all 4 patterns stored" for ca. 2 seconds at the right lcd. are you sure that the button is working? yes - you have to press&hold the button for two seconds, a message will be displayed which asks you to do this. so far i remember this special handling was requested by you? best regards, thorsten.

i'm not a live user, but i like the modular design idea, and the decision to create different firmwares for different purposes, because this avoids the difficult "resource management" (e.g. pin assignments, allowed external peripheral combinations, etc.). a "light wighted" firmware will also make it easier for other people to create derivatives, e.g. special adaptions for other DAWs :thumbsup: Best Regards, Thorsten.

you got mail... i'm using 20 and 10mm spacers, no 'double female' the screws are at the bottom side, i guess that there are better solutions? if a spacer was not long enough, i added a screw nut to extend it - this was the cheapest solution for me, no special reichelt order required. best regards, thorsten.

it cannot work properly this way, dedicated button handling functions have to be created. this would also allow to consider the shift button. if the examples under seq_buttons.inc don't help, you have to wait until i'm back from vagation. best regards, thorsten.

Hi, I would say: 1st priority: GP and ABCD LEDs 2nd priority: Mute/Pattern/Song/Edit, Gate/Aux and Live LED 3rd priority: Stop/Play LED 4th priority: Rew/Fwd, Shift and Alt LED Best Regards, Thorsten.

nice tool! Best Regards, Thorsten.

What is the voltage at J1 and J2? Maybe your PSU isn't strong enough? Best Regards, Thorsten.

Great sounds! Please add some reverb drums after ca. 4 minutes! :) Best Regards, Thorsten.

Hi Peter, I read the datasheet and haven't found any topic which would be in contradiction with the MBHP_CORE_STM32 requirements. You will have to jumper the VFD for Motorola mode (see chapter 6) However, since nobody tried this VFD before, it's probably better to test only one display before buying a second one. It would also be advantageous to have a return option for the case that the VFD isn't working properly for any reason. Note also that the power consumption is pretty high - the 7805 of the core module will need a heat sink! It could make sense to use a dedicated 7805 for the two VFDs. Best Regards, Thorsten.

I ordered a new backpanel and asked Schaeffer to compare it with the dimensions of the original panel before producing it. You don't really want to use (or even blind-order) my .fpd file before I tested the new panel, because it could cost you some money (ca. 75 EUR) or some fixing effort (three evenings at my side) if anything is still wrong! Best Regards, Thorsten.

Hi, there will be some news about motorfaders soon (in ca. 3..4 weeks) Please wait until then - it could be that as a beta tester you will get some high-quality Alps faders for free! :) Best Regards, Thorsten.

Great! :) Best Regards, Thorsten.

Hi, yes, this makes sense - it could be related to a power issue! You can check this by disconnecting the LCD backlight. Best Regards, Thorsten.

Ok, looks like a bad soldering joint at the core module - check the track which goes to the J8:Vd pin. Best Regards, Thorsten.