TK.

Das Bild ist etwas klein, ich hoffe, dass Du den Edit Button nicht vergessen hast... Die Track-Selektierung wird so nicht funktionieren. Es gibt 4 Track buttons und 4 Groups buttons, aber keine 16 Track buttons. Gruss, Thorsten.

Hi, it's currently not possible to map a AOUT value from a customized map with the required resolution - I added this to the wish list. Best Regards, Thorsten.

The assigned (learnt) events will be part of the EVENT_* definition of the ModWheel, hence they are not part of a snapshot. Instead they are part of the configuration (.ngc) So: in the SCS Disk menu you could store the configuration to a new .ngc file, and restore it later. This also allows to give each configuration a name. However, each .NGC file will result into a dedicated snapshot, .NGR and .NGL file - that's probably not what you want, but this is the way how the MBNG firmware architecture is constructed. The "SendEvent" meta command is implemented now, it allows to send multiple events from a single controller. -> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre3.zip Here a configuration example which I've used for testing: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmetalrn.ngc Encoder #1 sends CCs of Encoder 3/4/5/6 in different ranges and directions Encoder #2 sends CCs of Encoder 7/8/9/10 in different ranges and directions LED rings and LCD messages are correctly updated -> seems to work! :-) The learn function isn't implemented yet - this was only a proof of concept. Best Regards, Thorsten.

:thumbsup:

During a long walk in the snow I got following idea - hope that it's matching with yours: Let's assume all learnable MIDI messages are already defined as EVENTs and assigned to control elements. Then they could be "remote controlled" from another EVENT within a specified range with a new meta command. Since it's possible to assign multiple meta commands to a single EVENT, this would also allow to remote control multiple EVENTs from one. If this mechanism would help, I could also provide a "MetaLearn" command which has to be assigned to a dedicated button. Press the button to start learning, move all controllers which should be assigned to the "meta controller" within the desired range. Release the button -> done. More concrete usage example (based on yours) You've one EVENT which sends the CC for CutOff, another one which sends the CC for volume. Both are assigned to encoders. Another EVENT assigned to the ModWheel. Prepare the CutOff and Volume encoders for the start position which is sent when ModWheel is at 0% Then press the MetaLearn button. Move CutOff and Volume to the end position, the values are sent when ModWheel is at 100% Release the MetaLearn button. Now you could remote-control the CutOff and Volume encoder with the ModWheel within the range that you entered during MetaLearn. Would this solve your request? I find it useful :smile: Best Regards, Thorsten.

Hi Mattia, please try v1.033_pre1 which is linked in this thread: If the matrix is still not working properly, I need your .NGC file for further analysis. There are no known problems with multiple button/LED matrices (with v1.033_pre1, there was a problem with v1.033) Older versions can be found here: http://www.ucapps.de/mios32/backup/ But again: it's unlikely that the problem is related to the firmware itself. Best Regards, Thorsten.

Hi Chris, a MIDI learn mode is implemented, did you already try it out? It can be enabled from the SCS menu, or alternatively with a meta event assigned to a dedicated button. See also http://www.ucapps.de/midibox_ng_manual_ngc.html, search for "MidiLearn" It learns the CC (or optionally a NRPN) + the value range - as suggested. It doesn't allow to learn multiple MIDI events for the same control element, instead the first assignment will be replaced by the learnt one. If learning multiple events is mandatory, we've to think about the best strategy how to do this. Best Regards, Thorsten.

Hugo, are you working for this company? Best Regards, Thorsten.

deleted

Here a hint how you can retrieve the changes from an "official place" in order to get an impression about possible reasons for such issues. Go to http://svnmios.midibox.org Select the MIOS32 repository, and then click on the "View logs" button. Check the comments, they are sometimes helpful. Select the potential problematic version with a "known good" one, or whatever you want to compare. Then click on the "show changed files" button: This gives you a nice looking diff over all changes: And with some luck you will find out quickly, that the variable has been declared in seq_ui.c :) I'm using this web based method as well whenever somebody reports a problem after firmware changes in order to find out what I did ;-) Best Regards, Thorsten.

The LTC module was used back in 2000 as a cheap MIDI interface replacement. It was the time of Windows 98 and ME. Unfortunately today (15 years later!) the drivers don't work properly with newer windows versions anymore. :-( Use a cheap MIDI interface, it's more reliable! But please don't buy this one: http://www.ebay.com/itm/USB-IN-OUT-MIDI-Interface-Cable-Converter-PC-to-Music-Keyboard-Adapter-Cord-/271286969299?pt=US_Cables_Snakes_Interconnects&hash=item3f29f6a3d3%C2%A0 It's on the black list: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Instead I recommend a "Neusonik uMIDI/O22" which is cheap as well, but very reliable. Best Regards, Thorsten.

Hi, seems that EEPROM_Init() (or your application) hangs up for unknown reasons. Could you please check if the same happens with an existing application which is using the EEPROM driver, such as MIDIbox KB? If yes: then I've to troubleshoot the problem at my side. If no: then it's very likely related to your application, e.g. the way how you initialize parameters which are stored/restored to/from EEPROM. Best Regards, Thorsten.

It should work, latency shouldn't be an issue - but I never tested this by myself, and I can't exactly say how many MBHP_DRIVER modules can be used in a chain. But with only two drivers in the chain it should work. Best Regards, Thorsten.

Hi Roelli, yes, it makes sense to give each core an individual device id. Under http://www.ucapps.de/mios_download.html you can find the "change_id" application, which allows to change the ID without reflashing the PIC. See the README.txt for further details. Best Regards, Thorsten.

With suitable resistor values the switches shouldn't influence each other. Which values are you using? Best Regards, Thorsten.

I've read the whole thread again - of course, you already answered this question... Since the correct IC is used, the reason must be releated to the cabling between STM32F4Discovery board and the 74HC595, especially ground and SCLK. Remote diagnosis is very difficult here - but the photo of your breadboard shows that you are using long and thick cables everywhere, this could lead to such a bad signal quality (and EMC issues, etc.) - I'm normally using thin wirewrap cables which reduce the risk for such issues... Your scope pictures show very spiky signals as well, but I'm unsure if this is just because you've connected unshielded probes, or if these are the actual signals - in this case again an explanation for the issues. The shift register is working properly when a probe is connected: the probe adds an impedance to ground, this filters spikes. Again an indicator for a cabling issue I would propose that you improve the ground connections between the 74hc595 and the discovery module first. Here you are allowed to use a thick cable ;) If this doesn't already help, try a short, thin cable between discovery and the SCLK pin Best Regards, Thorsten.

The communication channel to a BLM16x16+X is MIDI based. The communication channel to a TPD is SPI (SRIO) based. They can't be combined together. You can only connect a BLM16x16+X to the MIDI based BLM port and no other devices. The TPD has to be connected to the SRIO chain at J8/J9. If you are using Wilba's Frontpanel, then directly connect the TPD to J2 of the frontpanel. If the TPD is not in the same device like the frontplanel, consider to use the MBHP_LINE_DRIVER PCBs. See also: http://www.ucapps.de/mbhp_line_driver.html This picture shows the wiring for a similar purpose: Just replace the DOUTX4 module below by a TPD and you know what I mean ;-) I've already tested this combination of modules, communication with the TPD is working stable over long distances. Best Regards, Thorsten.

This is strange indeed! Could you please check if you are using a 74HC595 or 74HCT595 device? It should be a 74HC595 (without T) Best Regards, Thorsten.

Update: another reason for this behaviour could be, that the wrong pins are measured. E.g. because some connections are swapped. Therefore another hint: after entering (for example) "testlcdpin rs 1", check that J15:RS got the high-level, and check that RW, E, D0-D7 are at 0V. If RS is 0V, and another pin is at high level instead, you found a wrong connection! Best Regards, Thorsten.

Everything that doesn't freeze at 0°C ;-) Thanks again to all donators for the support! Best Regards, Thorsten.

I just doublechecked this at my side, with V1.018 I can control all pins on a STM32F4 core. You are writing "set the pin to 0 or 1" Which pins did you try exactly? There are some pins which are controlled by the core directly, such as RW, RS, E1, E2 And some others which are controlled via a shift register (D0..D7) If even RW/RS/E1/E2 are not working, then it's more likely a measurement error, check your scope settings, it should show the current waveform (and not a captured waveform) Alternatively use a multimeter. Usage hint: in MIOS Terminal, you can use the cursor-up/down keys to browse through the command history. This simplifies the command entry, no need to enter "testlcdpin" again and again, just get it back from the history and modify the parameters which should be tested. Best Regards, Thorsten.

Unfortunately I've no time to add this feature before christmas (even the simple implementation). I will come back to this topic in 1..2 weeks - stay tuned! :) Best Regards, Thorsten.

I was also surprised that the assembly code still looked familiar after 5 years where I haven't touched it. ;-) Yes, MB6582 users only need to update the master core with MIOS V1.9h, see also Best Regards, Thorsten.

MIDIbox SID V2.044 has been released Aside from the encoder handler improvements (which require a MIOS V1.9h update!), we also got a nice christmas present from Lis0r. She improved the OSC Detune function by a new "SuperSaw" mode which is based on the research from this paper: http://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2010/rapporter10/szabo_adam_10131.pdf Your SIDs never played so fat sounds before!!! :hyper: Changelog: MIDIboxSID V2.044 ~~~~~~~~~~~~~~~~~ o This version got an improved rotary encoder handling. Please update to MIOS V1.9h before uploading the application, otherwise the improvements won't be effective. o swapped behaviour of ENC speed control again, so that encoders are at fast speed by default, and slow if SHIFT button pressed. This behaviour can now be alternated in your setup_*.asm file by changing the DEFAULT_SHIFT_SPEED_CONTROL_MODE option o implemented special encoder testmode which can be enabled with DEFAULT_TESTMODE_ENC_SPEED in the setup_*.asm file o envelopes are now released properly when a note is played via the SysEx editor (or with the PLAY button) o added new "SuperSaw" detune mode which has been created by Lis0r. In distance to the normal (legacy) mode, results are much better especially on higher detune values! The detune mode (DtM) can be selected in the OSC page for lead engine patches, and in the O23 page for bassline patches. For your own comfort here some concrete update instructions for the complete update (the last MIOS8 update happened 5 years ago, so that some of you might have forgotten what needs to be done ;-) connect your MIDIbox SID to a MIDI interface (bidirectional IN/OUT connection required) open MIOS Studio, select the MIDI IN/OUT port there Query should result into "Application is up&running" Now upload the mios_v1_9h/pic18f4685/midi/mios8_v1_9h_pic18f4685.hex file of the mios_v1_9h release package Thereafter upload a matching setup_*.hex file of the midibox_sid_v2_044 release package The MIOS V1.9h update is only required for the master core (because slave cores don't use the encoder handler) If a MB6582 or similar MIDIbox SID V2 with multiple PICs should be updated (so: no sammichSID for example), clone the application to the remaining PICs by pressing&holding the MENU button while the version number is displayed on the LCD. Best Regards, Thorsten.

MIOS8 got an update for the rotary encoder handling in FAST mode as discussed in this forum thread: Especially MIDIbox SID V2 users will benefit from this change! :) The new mios_v1_9h binaries are available at the MIOS download page: http://www.ucapps.de...s_download.html As usual, open MIOS Studio and upload the appr. hex file which is matching with the PIC of your MIDIbox. Thereafter upload the .hex file of the application -> done. Best Regards, Thorsten.