TK.

c-2 is note number 0 and it's (unfortunately) used at some places to identify unplayed notes. However, I just checked how to make this possible without breaking legacy - with this new build you should be able to play this note by transposing the track. E.g. transpose by -1 octave and c-1 becomes c-2 -> http://www.ucapps.de/mios32/midibox_seq_v4_098_pre10.zip Best Regards, Thorsten.

Hurray! Yes, this totally makes sense - an unexpected error with plausible effects: than weaker the pull-up & than more PICs are connected, than more likely unstable CAN communication Best Regards, Thorsten.

Interesting, this gives a different picture! No, the problem shouldn't be related to any core. The master can communicate with slave cores (which means: a lot of things are working fine!), but the entire communication breaks down once 4 cores are connected to the CAN bus. Two new ideas what could go wrong: power consumption: does it work if you pull out the SID chips? If you still see the same problems, the PSU is fine another potential problem could be that the 1k pull-up resistor isn't connected properly to the CAN wire. Without PICs in the socket you should measure 1k ohm between all RB3 pins and a +5V track Best Regards, Thorsten.

Yes, very likely a connection issue. The CAN bus is a single wire bus, all RX pins are connected together, and TX pin drives the wire via a diode. Do you have a multimeter with continuity & diode tester ("beeper")? Then: pull out all PICs, check for continuity between all RB3 pins in both directions. Then check that continuity between RB2 and RB3 pins is only in one direction: if Minus is connected to RB2 and Plus to RB3 it should be "beep", if Minus is connected to RB3 and Plus to RB2 it should not "beep". Best Regards, Thorsten.

Yes, I can confirm that RB2/3 are marked correctly. You can ignore D3/D2, because in distance to MBHP_CORE the RB2/3 pins are not connected to these datelines, but to different IO pins at J5 (that's also the reason why a special LCD driver is required when displays should run in 8bit mode) On this picture I can see that the diode is connected the right direction, so this is not the problem. However, you mentioned that you installed a custom LCD driver - which one exactly? The custom driver doesn't need to be installed on the other cores, and also jumpers are not required for these ones - only for the master core where the display is connected. Just to be doublecheck: if you swap core 3 and 4, do you get the "CAN bus error" message as well? This would confirm that it can only be an electrical issue. Best Regards, Thorsten.

Hi Niles, very good analysis so far, this helps to think about potential problems! CAN bus error means, that something is wrong with the CAN bus connections. E.g. the response from a slave core violates the CAN protocol, which indicates an electrical problem. Here the schematic: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf J15.D2 (=Pin RB2) and J15.D3 (=Pin RB3) are the CAN TX/RX pins What comes into my mind: the diode for core4 is soldered in the wrong direction, ensure that the cathode is connected with RB2 (like for the other PICs) or there is a short around pin RB2 Best Regards, Thorsten. P.S.: thanks also for the background information about PICkit- - I added it to the documentation!

Well, "did not understood each other" brings up an important point - let's talk about the background of our debate. From my point of view: you are very unhappy with the MIDIbox SEQ UI and after you noticed that I became a bit more active you bring up some points + improvement ideas under the assumption, that I've all time of the world to discuss each detail and rework the appr. firmware parts based on your wishes. But fact is, that my focus is still on very different topics, that a serious rework would require much more time to assess options with multiple users (like I did >10 years ago with onsite meetings), that the implementation probably has to be done by a programmer who needs to be funded. The energy I can spend on MIDIbox projects these days is still very low, and my motivation to continue discussions in the mode that you prefer is also very low. Maybe this helps you to understand a bit better why I don't react like you think I should do. Best Regards, Thorsten. P.S.: I'm off for some days due to business reasons...

So, this is how the edit screen looks today: We can clearly see the note played for each step including a velocity bar (which is useful and doesn't consume CPU power...): Your proposal: Does it really look better? Best Regards, Thorsten.

Please take care for your wording - it sounds like you are blaming me! Some years ago I quickly added a requested feature for a particular user, and now I'm blamed by you that I didn't spend more time to introduce higher flexibility (without knowing exactly for what additional options would be useful to judge if the implementation goes really into right direction). Your recommendation to use mute+track button: you can do this already by disabling auto-select unmuted track, so you personally should be fine with that, right? Majority of other MBSEQ users don't have a second GP button row, please consider this when doing proposals. I would like to close this topic - if somebody can describe a scenario where auto-select track on mute would be useful, I could add this option, but I'm not doing this because somebody thinks that I did a bad job and should do everything totally different just to get it right in his own universe. Best Regards, Thorsten.

By pushing the edit button you get quick access to some edit features, including generators (what you call "Pattern Fx") How else should it be done - inventing a new dedicated button, or hiding the options at a different page? Best Regards, Thorsten.

Why are you blaming me? I wrote that I could add a special condition (no option) to prevent this. Best Regards, Thorsten.

EDIT (but also PATTERN and SONG) are just pages - so far it didn't make sense to add a toggle behavior. However, I see synergies with this discussion: However, if EDIT/PATTERN/SONG/PHRASE become modes instead of pages it would still not make sense to add a "toggle option" - they would work more like "radio buttons" Best Regards, Thorsten.

So, let me summarize to check if I understood correctly + some questions: there should be a clear separation between EDIT and SONG mode what about PATTERN and PHRASE mode? Step/Track/Parameter/Trigger/Instrument/Mute buttons should optionally switch to corresponding overview page, but only in SONG mode same behavior in PATTERN and PHRASE mode? Or all optional: optional in EDIT, optional in PATTERN, optional in SONG, optional in PHRASE mode? Step/Track/Parameter/Trigger/Instrument/Mute buttons should permanently and not temporary switch to the corresponding overview page another option? which means overall 8 new options - for EDIT/PATTERN/SONG/PHRASE mode switch or don't switch to overview page, permanently or temporary currently PHRASE and SONG button have almost the same effect, might get a new function based on the discussion here - but I think that this has to be elaborated further currently EDIT/PATTERN/SONG are just pages, and no permanent modes which change UI behavior SONG and PHRASE are closely coupled, PHRASE is just a song of multiple pieces - are there ideas to differentiate PHRASE from SONG further? (I'm asking because this might affect the UI handling as well...) Best Regards, Thorsten.

This is no bug, but just the behavior as implemented already in MIDIBox SEQ V2 - it's consistent because regardless if ALL is selected or not, whenever somebody turns a GP encoder the corresponding step will be activated. But I understand that it would be better to avoid this in ALL mode - this would be a special condition, no "bugfix" Best Regards, Thorsten.

When I recall it correctly, the user who requested this special handling wanted a quick selection of the EDIT track after unmuting it, that's all. If such a track selection also makes sense for mute - I don't know and would like to know the exact scenario before adding another option. Best Regards, Thorsten.