Rio

this fix refers to the following issue (midibox seq v4 release feedback): The quantized recording loses its sustain (GLD) due to the offset of the next step, since the note of the step to be played is not passed and the recording loses the (note/sustain) information in the next step. seq_core.c: 1. replace this line: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_core.c#L1053 with: if (SEQ_RECORD_NewStep(track, prev_step, t->step, bpm_tick)) mute_this_step = 1; mute or not to mute? thats the question! seq_record.c: 2. insert this code: if (t->state.REC_DONT_OVERWRITE_NEXT_STEP) { int next_step = new_step + 1; // tmp. variable used for u8 -> u32 conversion to handle 256 steps properly if( next_step > tcc->length ) next_step = tcc->loop; new_step = next_step; } before: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L727 3. replace this line: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L735 with: if( any_note_played ) { which also passes flagged REC_DONT_OVERWRITE_NEXT_STEP. 4. replace this line: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_record.c#L843 with: return any_note_played; // no error instead of no error code, but it is enough that it is returned positive. Note: It is more of a hack than a concrete fix (it only works for tracks that are played forward), but for my purposes it works - if you actually like to use the quantization feature for live recording. But your desire to get an "undelayed, unquantized recording" has nothing to do with this solution. This hack is suitable for a working quantization during live recording of tracks that already contain & process midi data. Maybe quantization can give better results when recording notes, except that it does not conflict anymore with existing (already recorded) data in my modification.

Hello steve, Is it possible for you to make your own binary from the sources? I have written a fix for quantized live recording in the past... you could try the code changes/snippets which it affects. Let me know if you would like to try it out. Oh, you mean a possibility of an exact "unquantised recording". Of course, my suggestion doesn't fit there. greetings, rio

I have sent you a PM.

yes, the PIC18F4620 is the core for the SEQv3, but as already mentioned, the SEQv4/v4+ goes a lot further (SD Card instead of EEPROM support, the source code is mostly written in C++ instead of ASM etc.). DINX4, DOUTx4, on the other hand, are compatible.

fine If you end up uploading the Midibox SEQ app via midi, you should be able to manage sessions from the midibox options menu. You do not need to make sessions via the terminal - but it is possible. If you have the feeling that something in your 'old' session is stored incorrectly or is corrupt, then you can also try to load this session and copy certain things (patterns etc.) into your new (cleanly created) session - all this directly on the unit. And maybe in future just make a backup of the SD more often. no corrupt files have happened to me in all that time, but I always make chronological backups on the PC. That's tooo long! So my suggestion: please test a new SD Card <= 4GB! I also had problems in the past with SD cards of different types. Maybe my old thread helps out (but note, I use a LPC17 core - but the conclusion is to use a smaller SD card, which I have already mentioned): Perhaps as a tip for the future: I can't say anything about the hardware problems, but you should also check all the connections to the SD card - in case you soldered together your own SD card board (or the previous owner). Otherwise, test another SD card).

You should backup these files as long as they can be read on the PC.

I never said it shouldn’t be a hardware link. Maybe the right term is „debug Interface“, … …but I don’t have STM32F4 in use for my mbseq.

I don‘t think, that you have care about a SD card for uploading mios32 app or (in the worst case) flashing bootloader by a linker.

This is a standard message when the bootloader/mios32 is on. It is good that it is running. After that, you can safely upload the MBSEQ, but for the right core! - which is not quite clear here yet (probably STM32 core).. but MIOS Studio should already give you the info back with the USB midi connection. more infos here: http://www.ucapps.de/mios32_bootstrap_newbies.html and here: http://www.ucapps.de/index.html?page=mios32_bootstrap_newbies.html Mios Studio 2: http://www.ucapps.de/index.html?page=mios32_bootstrap_newbies.html

Please use another SD card!! Terminal output would be nice too.

What country are you from? Greetings, rio

Hi, there might be something wrong with your board. I tried it several times with my all kind of lpc 1769 boards - a,b, d Rev. Woth success. so you can check your board for bad solder points and the debugger board interconnection..

how can it break? as long as you haven't trotted up, it should still work.. probably the mios firmware/app on that device is corrupted, isn't it? as long as the bootloader is still there, which is in a protected area, you can fix it. And yes, you can not take a PIC18f4620 - different features, different storage area.

Hi, you could create a simple program, also with a PIC core board with the help of a bare skeleton available here on ucapps. the k2 speakjet project is a good example for a serial communication (max232), but for your needs IIC would be more comfortable (as long as it is supported by your speakboard). you may get faster results with an Arduino board too. With all this knowledge you can surely also hack the SEQ for your needs, but that takes quite a lot of time to understand everything that is already there. you could still allow a control via midi on your own board too. greetings

wasn't it the 6581 emulation that had more bang?