TK.

It might be possible for V4L with some (simple) app extensions, but not for V4 since Lemur can't display LCD contents. The virtual MBSEQ V4 runs only under MacOS. Unfortunately it doesn't work anymore with the latest MacOS changes due to a incompatibility with PYMIDI. Actually it should be rewritten so that it uses Juce as a framework, so that it would also run under Linux and Windows, but this is some work (and I'm still searching for a skilled programmer who could take it over :smile:) Best Regards, Thorsten.

Hi, did you also upload the hwcfg/wilba/MBSEQ_HW.V4 file into the root directory of the SD Card? Without this special configuration neither buttons, nor LEDs will work. strange! The timeout indicates that something is received, but that the incoming MIDI stream is corrupted. Does this even happen if no MIDI device is connected to the board? This board has to be connected to J4A - are you sure that the ribbon cable is connected correctly? Which app are you trying exactly? It seems that it hasn't been prepared for STM32F4 Best Regards, Thorsten.

See also http://www.ucapps.de/midibox_seq_manual_fp.html - search for "ALL" NEW since v4.074: if the ALL button is active (regardless if pushed or not), and the encoder of an unselected step is moved, the editor will generate a ramp between the selected step and the moved encoder. Another possibility for this behaviour could be a lose contact on your ALL button, so that it isn't permanently active when you are pushing it. In this case values will only change with relative increments. Best Regards, Thorsten.

In theory it is possible, but it's a lot of work and no success guarantee. You probably won't be able to simply take over performance hungry synth features which might be added by somebody else, therefore it's normally a more clever to spend +14EUR for a second core. Best Regards, Thorsten.

Yes, a lot of features have been added to the Jam page in the last months. :) If you want to get immediate feedback of the recorded notes, you've to enable the "Fwd." switch (-> MIDI forwarding) Best Regards, Thorsten.

I'm glad that we solved this! :) Best Regards, Thorsten.

I adapted the sample rate so that it matches with the original project. This is probably the better way anyhow, e.g. to get equal envelope slope times. Currently the waveform calculation takes 35 uS on a STM32F4, it's triggered each 113 uS, which means that the CPU is only loaded by ca. 30% However, I'm not planning to extend the synth from my side, I only did the adaption in order to allow somebody else to take this as a basis for further developments. :smile: A prebuild binary is now on the server as well (-> release/STM32F407VG/project.hex) You can download the files with a subversion client (google for good clients which are provided for your preferred OS) Once you installed the client, take following URL: svn://svnmios.midibox.org/mios32 Alternatively check this page how to install the toolchain, so that you are able to build the firmware by yourself: http://www.ucapps.de/mios32_c.html Best Regards, Thorsten.

Alright - no problem, this was a nice challenge (something like a text adventure ;-) Desoldering will be extremely time consuming, and there is a higher danger that tracks will be damaged and the circuit won't work anymore without fixes. It's probably easier if you would cut some tracks with a sharp knife, and re-connect them with short wires. Best Regards, Thorsten.

I've an assumption: there isn't a problem with the smaller footprint, but the circuit behaves like if the upper two pins of the button are not connected internally. If you follow the D0 track in the schematic, you will see what I mean: it goes from U2 to GP7, GP5, GP3 and GP1 via the buttons. The datasheet says that the internal connection exists: https://www.e-switch.com/system/asset/product_line/data_sheet/143/TL1100.pdf (pin 3/4 and 1/2 are connected together), but somehow this isn't the case at your side...? You could check if this assumption is true by soldering a short wire at the upper two button pins of all GP buttons (start with GP7, and check if GP5 is working thereafter) No wire is required for the two lower pins. Best Regards, Thorsten.

Could you please do an electrical continuity check? E.g. with an ohmmeter or a "beeper". See also following schematic where I marked the interesting measurement points for the GP1 button: direct download: http://www.ucapps.de/tmp/wilba_pcb_check_matrix.png All 5 "D0" points should be connected, as well as the 4 marked "M5" points. In addition it would be interesting if the "din_testmode" shows a message if you connect D0 of U2 (this is a 74HC165) with M5 of U7 (this is a 74HC595) with a short cable. This should trigger the "Pin M5 D0" message. Best Regards, Thorsten.

This is really strange! Especially because the working buttons are scanned over different matrix lines there is no simple explanation. In order to get a better picture, it would be interesting which buttons (and encoders) are working exactly. For this purpose I added a new testmode into the firmware: -> http://www.ucapps.de/mios32/midibox_seq_v4_089_pre1.zip After the upload, enter "set din_testmode on" into MIOS terminal, and then push all buttons and turn all encoders. Let me know, which buttons are working exactly (I need the Mx and pin number), and if the encoders are working. Best Regards, Thorsten.

I spent some time this evening to make a proper map index handling possible - hopefully with success! Please try this version at your side: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre7.zip step by step please! First we've to try to get the firmware stable again after the changes, this requires careful testing at both sides. I remember that there is an open request for defining transponse and split point, but my current focus is on fixing bugs, not adding new bugs^H^H^Hfeatures ;-) Best Regards, Thorsten.

Ok, I added the new type "NoteOnOff", because there are more use cases (e.g. this btw. obsoletes the ain_mode=NoteOnOff) Could you please check if this works at your side? -> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre7.zip This is a critical change, because there are some implications in the firmware that the type index matches with the MIDI event index + 8 (I tried my best to avoid a conflict, but it could be that I forgot a certain case) Best Regards, Thorsten.

The DOUT module will work independent from the AOUT module. If you never tested the module before, it makes sense that you test it with another application. E.g. upload MIDIO128 and play some notes The MIDIO128 application also allows you to set DOUT pins directly from the MIOS Studio Terminal: set dout <pin> <0|1>: directly sets DOUT (all or 0..255) to given level (1 or 0) Best Regards, Thorsten.

Huebsch :) Gruss, Thorsten.

Hi, this is because how maps are handled. With the current implementation, maps with duplicated values won't work. I've to check if an alternative option is possible which allows to handle your use case, stay tuned... Best Regards, Thorsten.

Hi Justin, I don't know when a weekend starts at your side... ;-) However, here the quick&dirty migration: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fgoom%2F I expect that somebody else takes over the maintenance of this code, especially whenever Marks is doing updates. The code is taken from his website, it seems that sound parameters can be updated via Chn1 - at least I get some sounds when setting some CCs and playing notes. Best Regards, Thorsten.

You could change the value to 0 during forwarding, this should result into NoteOff. Something like: fwd_id=SENDER:1:0 Best Regards, Thorsten.

More likely somebody will use the 64 gate/triggers and control them from one or more drum tracks (which can be nicely configured with the BLM) than sacrificing common tracks for this purpose. Please don't get me wrong: such an option could be easily implemented into the firmware, and the configuration could be well hidden into a configuration file (or in the UTIL->Options page) in the hope that somebody (aside from you) will ever use it. But somehow I haven't the feeling that this is a useful feature compared to existing possibilities. And actually I would prefer to spend some time to overwork the CV/gate channel assignment concept and come up with a more flexible solution instead of providing just another poorly conceived extension. The current CV related possibilities are already too confusing and especially not scalable, as it turned out in various forum postings. Best Regards, Thorsten.

The discussion gets confused - what is the actual use case for the 16 gates? And how should the gates be handled for drum tracks, which has actually multiple gates (one for each drum instrument). Best Regards, Thorsten.

Hi, the first problem sounds similar (but not exactly) like the observed behaviour if a core with multiple USB ports is used under Windows. It would be interesting: - which windows version you are using - how does it behave if the "single_usb" option is enabled in the bootloader? -> see http://www.ucapps.de/mios32_bootstrap_newbies.html (you need to upload the bootloader update app to change the flag) - if you are using an older Windows version, such as WinXP, it might help to install the GM5 driver Strange indeed! I need more input under which circumstances this could happen, resp. if it can be reproduced. Has anybody else observed a similar issue in the past? Btw.: which MBNG version are you using? Best Regards, Thorsten.

Just had a look into the source code - it shouldn't be so difficult to port this to MIOS32, I will check this next weekend. :) Best Regards, Thorsten.

No, this isn't possible because the MBSEQ V4 based scheduler works MIDI tick based, not time based. Best Regards, Thorsten.

The usage of the core based IO pins is dangerous, and therefore not recommended. Either a buffer IC (like the 74HCT541) is required for level-shifting (and protection), or just use a DOUT shift register which is the recommended and documentation solution at this page: http://www.ucapps.de/midibox_seq_manual_hw.html Best Regards, Thorsten.

Well, actually I wanted to provide the "big solution" which allows complete external control - but it's too much effort compared to the benefit, especially since I always used the existing CS by myself whenever I made music with the MBSID (no need for any external editor capabilities at my side...) However, here the cheap solution: http://www.ucapps.de/mios/midibox_sid_v2_045_pre1.zip 0C/f) F0 00 00 7E 4B <device-number> 0C 20 <channel|instrument> F7 Changes the selected SID channel or instrument: - lead engine: selects between --, L-, -R, LR (range 0..3) - bassline engine: selects between --, L-, -R, LR (range 0..3) - drum engine: 16 instruments -> range 0..15 - multi engine: 6 instruments -> range 0..5 Numbers outside the range will be silently ignored In the hope that it satisfies your request, and doesn't require additional extensions... Best Regards, Thorsten.