TK.

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.

Hm... one day ago I thought that I could add a Mute/Solo feature in maybe 1..2 hours. But the additional feature requests sound like I've to work on this for several days - not at least to satisfy your ideas, get feedback, iterate. So, how can we come to a conclusion? ;-) The proposed "track settings view" mode sounds powerful, but the information which needs to be displayed (such as several track configuration flags) isn't stored in RAM in a way which makes it possible to pass it to the BLM without loosing a lot of CPU time to fetch the different flags from different variables. Mute and Solo are available as 16bit variables, and can be directly passed without re-arrangements. That's another reason why I would like to focus Solo/Mute. The proposed "button mode" which cycles between 4 states has the disadvantage, that it isn't suitable for live situations where you may want to control the device "blindly" (the big advantage of the tactile feel of a BLM in distance to touchscreens) Best Regards, Thorsten.

Hi Sylwester, the Frontpanel PCBs are now provided by SmashTV, but there is a very long waiting list (it could take several months) So: feel free to create your own PCB. It isn't possible to add more LCDs, because it's not supported by the firmware. If you've some programming skills, I could give you some hints what needs to be done, but it will be a lot of work (which I don't want to do by myself ;-)) Best Regards, Thorsten.

Hi, I'm able to power the MBSEQ + BLM16x16+X + TPD from this USB hub: http://www.reichelt.de/USB-Hubs/MAXXTRO-MX-UAP/index.html?;ACTION=3;LA=444;GROUP=EU3;GROUPID=4831;ARTICLE=99781;START=0;SORT=artnr;OFFSET=16;SID=11TVLbZ38AAAIAAG9MIgIec1e46ae3eb4fc2fe4e011f269170227 The PSU delivers up to 2A at +5V (no need for -5V) Best Regards, Thorsten.

To elaborate your ideas a bit further: replace PLAY and STOP button by MUTE and SOLO on/off buttons would work, right? I can't flash the LEDs, this would be too much Launchpad specific, or would generate some (unwanted) MIDI traffic. But we've three colours, therefore I would propose: Mute and Solo off: no colour Mute on, Solo off: green Mute off, Solo on: yellow Mute and Solo on: red (because the muted soloed track won't output MIDI messages) Ok for ALT+MUTE/SOLO combinations. But I don't want to add more ALT functions. Nobody will remember them in 1..2 months. Best Regards, Thorsten.

Need more inspirations how it could look like. Best Regards, Thorsten.

Hi Carl, MBSID V2 works a bit different compared to V1. Instead of Play and Goto commands, you just specify the begin and end of the WT sequence in the WTC menu: In addition you can specify a Loop point. So, for the particular sequence above, specify: Beg: 00 End: 0A Lop: 01 Btw.: there is a wavetable tutorial in the "first steps" section of the user manual which explains the basics: http://www.ucapps.de/midibox_sid_manual_fs.html Best Regards, Thorsten.