TK.

It seems that I've to re-adjust the prefetch time which ensures a proper synchronization. It's the most timing critical operation, because a lot of data has to be loaded from SD card while MIDI notes from previous patterns are played by the scheduler. Since the problem happens at the 7th song, it indicates that some additional FAT32 table read operations take place which cause a delay which I haven't considered yet. Could you please create a minimal session which allows me to reproduce this issue at my side for further analysis? Best Regards, Thorsten.

and even more steps are required to implement alternative solutions, especially for somebody who has no access to the hardware extension you have in mind. The assembly based implementation makes it even more difficult to add extensions w/o extensive testing! So: please don't expect support from my side, there are more interesting projects in the queue :) Best Regards, Thorsten.

Thanks for the compliment! :) Hopefully I will get some time to doublecheck the most recent Lemur version at my side this weekend. Best Regards, Thorsten.

Based on your screenshot: https://www.flickr.com/photos/68202862@N03/13710200005/ Change: 0110 = HS-PLL enabled freq=4xFosc1 Disable LVP Disable PORTB = analog input All ID bytes have to be programmed with 00 Best Regards, Thorsten.

Ok, it won't work with a 1:1 connection Best Regards, Thorsten.

In meinem Setup (_tk.asm) habe ich noch zusaetzlich ein AOUT_NG Interface aktiviert, deshalb wird mehr Speicher verbraucht und es kommt abermals zu einem Overrun. Doch eigentlich war das File nur fuer meine eigene MIDIbox FM relevant - "war", weil ich ja mittlerweile den PIC18F452 durch einen PIC18F4685 ersetzt habe, und das setup_pic18f4685_mbfm_tk.hex file verwende, so dass es keine Speicherprobleme mehr gibt, und noch weitere (sehr schoene) Features freigeschaltet werden konnten. Gruss, Thorsten.

Yes, tie them together and connect a single ground wire to a central ground terminal, e.g. at J2:Vs Best Regards, Thorsten.

MIDIO128 only supports the AINSER64 and not the AINSER8 module. So, currently it won't be possible to use the AINSER8 module properly. I added this to the wishlist. Once a new firmware version is available, you have to update it with MIOS Studio. So, use the time to find a solution for this (e.g. by booting a different Linux version, or by using a different PC) Best Regards, Thorsten.

Yes, (unfortunately) the OSC ADSRs are hardware implemented in the SID chip and can't be emulated via SW - this would solve many things, especially the infamous ADSR bug... Best Regards, Thorsten.

Hast Du es auch mit dem .hex File aus dem neuen .zip Package versucht, das ich heute generiert habe? Die Versionsnummer ist gleich geblieben, da sich an der Firmware selbst nichts geaendert hat. Nein, daran liegt es nicht, denn der Upload funktioniert ja. Dass er bei 98% abbricht hat eine andere Ursache, die mit dem neuen .hex File eigentlich behoben sein sollte. Welches .hex File aus dem Package laedst Du auf? Bzw. generierst Du Dir ein eigenes .hex file? (bspw. nach einer Konfigurationsaenderung?) Gruss, Thorsten.

This is a great idea! :smile: Please try this pre-release: http://www.ucapps.de/mios32/midibox_seq_v4l_082_pre1.zip Button assignments: o CLEAR button now allows to clear individual tracks with the GP buttons: - CLEAR+GP1: clear note triggers (values are kept but not played) - CLEAR+GP2: reset velocity values to 64 - CLEAR+GP3: reset note length values to half step - CLEAR+GP4: clear Pitchbend - CLEAR+GP5: clear all CCs - CLEAR+GP6: clear Seq1 + track configuration (*) (like before) - CLEAR+GP7: like GP6, could be used for other purposes in future - CLEAR+GP8: like GP6, could be used for other purposes in future Same for GP9..16 for Seq2 (*) track configuration won't be changed if 'PasteClrAll' set to 0 in MBSEQ_GC.V4 file As long as the CLEAR button is pressed, the LEDs act as some kind of "track activity indicators" to notify the special function, and to give an oversight about the track utilization. Unfortunately the clear functions of GP#4...8 resp. GP#12..16 conflict with the activity monitor. E.g. track 4/12 not only store the pitchbender, but also the first 3 CC lines. Track 5..8/13..16 store the additional CC lines (4 per track). But GP button 4/12 will only clear the pitchbender (by intention), and GP button 6..8/14..16 will clear the complete sequence instead the assigned CC lines. This could be confusing, on the other hand the additional button assignments are more important than a consistent display. With some dirty patches in the seq core I could improve the activity monitor depending on how important the display capabilities are. Alternatively, I could change the recording function, so that CCs are not stored in the same track like PitchBend anymore. This would also solve an inconsistency in the mute function (which mutes PB and the first 3 CCs) - a difficult decision. Best Regards, Thorsten.

The current draw isn't that high, because LEDs are time-multiplexed. A 1A PSU should be enough, this can be delivered from a USB hub based PSU. The firmware doesn't support LED matrices with 32 LED rows, 16 LEDs per row is the limit (and I can't change this anymore due to conceptional reasons). It isn't a good idea to construct a matrix this way (and similar to the 16 LEDs per row max limit, also the column selection lines are limited to 16 for good reasons). E.g. if a matrix has 8 selection lines (as proposed above), each LED row will display a pattern for 12.5% of the reload period. With 16 selection lines (possible, but not so bright anymore), each LED row will display a pattern for only 6.25% of the reload period anymore. The pattern is still visible, but it's very dimmed. With 32 selection lines (your idea...), each LED row will display a pattern for only 3.125% of the reload period. I guess that with such a short duty cycle nothing will be visible anymore! Instead it's better to use multiple matrices (meanwhile up to 16 matrices are supported) with 8 selection lines each. Each matrix will require 3 DOUT SRs (one for 8 selection lines, two for the 16 LED pattern) Best Regards, Thorsten.

I'm aware of this issue, but unfortunately the problem has to be solved in Ableton. Best Regards, Thorsten.

Found & fixed the problem - it was related to the midichannel handling. Could you please try the new version in the repository? Best Regards, Thorsten.

Hallo Lutz, der Fehler passiert wegen des reduzierten PIC18F452 Speichers - leider wird aufgrund des Abbruchs das interne EEPROM nicht mehr beschrieben, und deshalb ist der Patch leer. Der Fehler sollte mit dieser Release nicht mehr gemeldet werden: http://www.ucapps.de/mios/midibox_fm_v1_4i.zip Gruss, Thorsten.

Yes, you can change the drum notes in the EVENT page (assumed that the track has been configured for drum mode). The drum instrument is selected with GP#11, and the note with GP#12 Best Regards, Thorsten.

Well, it has been requested that END shouldn't stop the sequencer anymore, and nobody complaint. If you want to get back the old behavior, you've to rebuild the firmware with following change in seq_song.c: search for following lines: case SEQ_SONG_ACTION_End: #if 0 if( song_active ) // not in phrase mode SEQ_BPM_Stop(); #else song_finished = 1; // deactivate song incrementer #endif break; and replace "#if 0" by "#if 1" Best Regards, Thorsten.

Hi, many files have to be changed to support another STM32F4 derivative, especially when it's smaller (memory & package wise) than a STM32F407! Even for me this would take a couple of hours (therefore I can't give you simple instructions for the required changes). Most difficult topic is to decide the IO pin configuration for the reduced 64pin package. Many peripherals won't be available. However, since you already own a STM32F407, it's probably better to skip this idea anyhow. Best Regards, Thorsten.

Great! :thumbsup: Best Regards, Thorsten.

Hi Florian, yes, I could add this to the firmware. I'm unsure about the best access method for this function - which one would you prefer: a) using a key combination, e.g. "COPY+CLEAR" (or similar) b) a dedicated button function, which can be configured in the MBSEQ_HW.V4L file on SD Card. Then you could sacrifice a typically unused button (e.g. UNDO?) and assign the new CLEAR_PB_AND_CC function to this button instead. Best Regards, Thorsten.

Hi Lisa, They seem to have little effect on the sound, other than making it quieter. They also seem to effect the sound all the time, even when "ext in" isn't switched on. yes, the pots will affect the sound regardless of the "ext in" switch. Therefore turn the pot full left if you don't want to use the feedback option. You should hear an effect with "ext in" on, cutoff low, resonance high, pot at least in middle position. Best Regards, Thorsten.

I can confirm that ULN2803 helps to get consistent brightness. Proven in the LRE8x2x4 project: For best brightness results, consider to use 8x16 matrices (each matrix outputs 8 meters, each with up to 16 LEDs), and not a 16x16 matrix, because than more meters share the same row SRs, than less time per meter to display the pattern! Best Regards, Thorsten.

The SID volume shouldn't be modified if the V2A option is enabled in the ensemble menu. From the user manual: V2A (Volume to Analog): Volumes are forwarded to external CV outputs as well (assignments have to be done in the setup_*.asm file). Note that the effective volume value behind the modulation path is taken - accordingly you are able to realize an external VCA to overcome the ADSR bug. Best Regards, Thorsten.

The MIDI router is not enabled by default, therefore this won't work without further configuration. And to confuse you even more: the MF module has a special MIDI router, which is configured with the "MF" command, and ensures that "direct" communication between MF and core module won't be forwarded. Did you already found the configuration examples? E.g. -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fmf_cc.ngc The MF command specifies an midi_in_port, midi_out_port and config_port Did you already consider this? If yes: which configuration are you using exactly? Best Regards, Thorsten.

Yes, you are right, the connections are wrongly named at the Discovery side, they are correct at the J10A side. I can fix the schematic in ca. 2 weeks... The PCB has the correct connections. Best Regards, Thorsten.