TK.

There is no real danger to write it this way, since you will never read >= 2^31 bytes (s32 ranges from -2^31..2^31-1) Best Regards, Thorsten.

I don't think that it will compile this way (there is a missing bracket) Why are you checking for <= 64? I would expect a check for < 32, since matrix[] is in the range 0..31 And why do you multiply by *8? There are 16 channels... somehow I'm missing a clear concept. It makes sense to add a comment what actually the function should do, and what are the constraints. This would make it easier for others to find out what's wrong in the code. Or it could even help you to find the error by yourself ;) Best Regards, Thorsten.

Btw.: matrix[] is declared as: static unsigned char matrix[32] ; [/code] Why are you checking for <= 64? I would expect a check for < 32, since matrix[] is in the range 0..31 Best Regards, Thorsten.

It's better to calculate "8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex" only a single time, and to put the result into a temporary variable. Btw.: you forgot the 8* multiplication inside if() Best Regards, Thorsten.

no, this isn't strange. Because "random effect" means that something could happen that you won't notice immediately, or that you will never notice... In this particular case (when 0xb2 is received) the programming error caused an effect that you noticed immediately: the application crashed, probably because a frequently used runtime variable has been overwritten. Best Regards, Thorsten.

Er... what are you doing in MPROC_NotifyReceivedEvnt() of the second core? void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { int channelIndex = evnt0-0x90; int noteIndex = evnt1; unsigned char value = evnt2; matrix[8*(noteIndex - 1 + _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0 } [/code] this function will write into a RAM location depending on the received event. There is no if() branch which filters the expected events, accordingly any received event will write something into the matrix[] array. Let's assume 0xba 0x02 is received: channelIndex = 0xba-0x90 = 0x2a (instead of 0xa --- hint: it's better to write "unsigned char channelIndex = evnt0 & 0xf") noteIndex = 0x2 -> matrix[8*(0x2a-1+_NOTE_MATRIX_OFFSET)+0x2a] = value Thats somewhere outside the array range.. Something random will happen (*) after this write operation. The effect will change whenever you add new/remove old code. So, I strongly recomment you to check for the received event -> if( (evnt0 & 0xf0) == 0x90 ) and to add some additional checks to ensure that matrix[] is never written outside the declared range. It's also better to use "unsigned char" (8 bit values) instead of "int" (16 bit values) for faster code execution. The same programming error exists in MPROC_NotifyReceivedEvnt() of the first core. Best Regards, Thorsten. (*) this could also explain similar "strange effects" that you noticed in the past.

issue 1) could happen if your application running on core #1 doesn't send a complete MIDI event, so that core #2 will freeze until the timeout period has passed. There are more possible reasons if course (e.g. programming error in application running on core #2), but with the given details it will only end into speculations. Maybe I could give you more explicit hints by posting your MIDI sending routine used for pot events, and the MIDI receiver routine of core #2 Best Regards, Thorsten.

I think it's better to measure the voltages instead of continuity with a beeper. Each pot outputs a value between 0V and 5V at the middle pin. Check this first. Whenever you turn the pot, the output voltage must change. Thereafter disconnect J6 of the AIN module from the CORE module, and connect the J6:A/B/C lines directly to 0V or 5V. There are 8 combinations how these lines can be connected to 0V/5V Each combination selects another pot (1 of 8), and you can measure the voltage of the selected pot at J5 of the AIN module. If during measuring it turns out, that a certain combination doesn't route the pot voltage correctly to J5.Ax, you know that the error (e.g. missing cable) is located between the 4051 multiplexer and the appr. pot Best Regards, Thorsten.

Of course, the MBHP_BLM_SCALAR concept allows to connect RGB LEDs, and the transfer protocol considers this as well. But this is more an option for people who like the excotic stuff. It isn't an option which I would prefer for myself. Do you really want that we create a layout for an EBay article which is only available for a short time in small quantities? There might also be an issue with the power consumption. More than 5A require a different concept for source/sink drivers. They will be expensive as well. Do you really want that *all* people who are interested on PCBs have to pay much more money compared to the Duo-Colour option just because a small number of people think that RGB *could* be useful? ;) Best Regards, Thorsten. P.S.: there is always the option that those people interested in RGB LEDs could create their own PCB layout for buttons/LEDs, and use the same BLM_SCALAR board.

Power Consumption? Best Regards, Thorsten.

It's released now in beta12 :) If you've created some useful presets, feel free to provide them in the Downloads section of this forum! Best Regards, Thorsten.

Beta12 is available now: o Tracks can now be stored into/loaded from preset files on SD Card. This features opens some new possibilities: - you can store your favourite track configurations, melody lines, drum loops, etc. in separate files to recall them later - you can prepare drum maps for different instruments - you can prepare CC setups for different instruments - you can share the files (which are stored in the preset/ directory) with other users - you can view and edit the files with a common text editor. The preset functions are available in the MENU->EVENT page You've to create a "presets" directory in the root directory of your SD Card before using this feature (the DOSFS driver used by MBSEQ doesn't support "mkdir") [/code] Best Regards, Thorsten.

For MBSEQ V4 I implemented an additional abstraction layer (seq_file.c) which simplifies file accesses (see seq_file_c.c) But probably it's easier for you to start from scratch by accessing the DOSFS functions directly. Best Regards, Thorsten.

Wilba already helps with the layout of the upcoming MBHP_BLM_SCALAR (a scalable button/LED matrix) So, you would pay more than 300 EUR for buying 256 RGB LEDs instead of ca. 50 EUR for 256 Duo-Colour LEDs? Best Regards, Thorsten.

...and I thank you for this nice inspiration - this new method will speed up my own workflow as well. I already implememted the dialog pages and export function today (most functions already exist and only had to be customized). So, I decided to provide a special "PRESET" button in the track event page: It opens a dialog which allows to select the preset file (left side), or to store a new preset: Different sections can be selected before the preset is imported: Exporting a track: just enter the name - done: And this is how an exported track looks like. Some values are hard to edit for a non-programmer, but as mentioned earlier, the most comfortable way is to use the CS anyhow. Alternatively somebody could program a GUI (running on a computer) which allows to edit such a file as well. # Only keyword and the first value is parsed for each line # Value ranges comply to CCs documented under doc/mbseqv4_cc_implementation.txt # The remaining text is used to improve readability. # DON'T CHANGE THE ORDER OF PARAMETERS! ParInstruments 16 ParLayers 1 ParSteps 64 TrgInstruments 16 TrgLayers 2 TrgSteps 64 EventMode 3 (Drum ) # Track will be partitioned and initialized here. # The parameters below will be added to the default setup. # | | | | | | | | | | | | | | | | | Name ' BD SD LT MT HT CP MA RS CB CY OH CH Smp1 Smp2 Smp3 Smp4 ' TrackMode 1 (Normal) TrackModeFlags 3 (Unsorted: on, Hold: on, Restart: off, Force Scale: off, Sustain: off) MIDI_Port 0x00 (Def. ) MIDI_Channel 0 (#1) DirectionMode 0 (Forward) StepsForward 0 (1 Steps) StepsJumpBack 0 (0 Steps) StepsReplay 0 StepsRepeat 0 (0 times) StepsSkip 0 (0 Steps) StepsRepeatSkipInterval 3 (4 Steps) Clockdivider 15 (16/384 ppqn) Triplets 0 (no) SynchToMeasure 0 (no) Length 15 (16 Steps) Loop 0 (Step 1) TransposeSemitones 0 (+0) TransposeOctaves 0 (+0) MorphMode 0 (off) MorphDestinationRange 0 (1..16) HumanizeIntensity 0 GrooveStyle 0 GrooveIntensity 0 TriggerAsngGate 1 (A) TriggerAsngAccent 2 (B) TriggerAsngRoll 0 (-) TriggerAsngGlide 0 (-) TriggerAsgnSkip 0 (-) TriggerAsgnRandomGate 0 (-) TriggerAsgnRandomValue 0 (-) TriggerAsgnNoFx 0 (-) DrumParAsgnA 9 (Roll ) DrumParAsgnB 0 (None ) EchoRepeats 0 EchoDelay 7 ( 8 ) EchoVelocity 15 EchoFeedbackVelocity 15 (75%) EchoFeedbackNote 24 (+0) EchoFeedbackGatelength 20 (100%) EchoFeedbackTicks 20 (100%) LFO_Waveform 0 ( off ) LFO_Amplitude 192 (64) LFO_Phase 0 (0%) LFO_Interval 15 (16 Steps) LFO_Reset_Interval 15 (16 Steps) LFO_Flags 0 (Oneshot: off, Note: off, Velocity: off, Length: off, CC: off) LFO_ExtraCC 0 LFO_ExtraCC_Offset 64 LFO_ExtraCC_PPQN 6 (96 ppqn) NoteLimitLower 0 NoteLimitUpper 0 # MIDI Notes for Drum Instruments: ConstArrayA 0x24 0x26 0x29 0x2b 0x2f 0x27 0x46 0x4b 0x38 0x31 0x2e 0x2a 0x2c 0x3c 0x3d 0x4c # MIDI Velocity: ConstArrayB 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 # MIDI Accent Velocity: ConstArrayC 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f # Parameter Layers: Par 0x000 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x010 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x020 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x030 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x040 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x050 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x060 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x070 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x080 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x090 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0a0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0b0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0c0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0d0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0e0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x0f0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x100 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x110 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x120 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x130 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x140 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x150 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x160 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x170 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x180 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x190 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1a0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1b0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1c0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1d0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1e0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x1f0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x200 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x210 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x220 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x230 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x240 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x250 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x260 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x270 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x280 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x290 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2a0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2b0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2c0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2d0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2e0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x2f0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x300 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x310 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x320 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x330 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x340 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x350 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x360 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x370 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x380 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x390 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3a0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3b0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3c0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3d0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3e0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Par 0x3f0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 # Trigger Layers: Trg 0x000 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x010 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x020 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x030 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x040 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x050 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x060 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x070 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x080 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x090 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0a0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0b0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0c0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0d0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0e0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Trg 0x0f0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 [/code] I will implement the parser (for the import function) tomorrow, thereafter this feature is completely available. Importing a file will take less than one second, and sequencer timings won't be affected thanks to FreeRTOS based task handling. :) Best Regards, Thorsten.

"No change" is selected when the position shows "-:--" Best Regards, Thorsten.

Discussion about preset patterns will be continued here: Best Regards, Thorsten.

How about following implementation (I think that this is feasible without much programming effort): template tracks can be stored as separate files into a special directory (e.g. presets/*.V4T) parameters are stored in text format, so that they could also be edited from a computer they can be selected in the Track Event mode page as suggested they can also be stored from there (last item in list "Store new Template") while importing a template it will be possible to selected parameter groups which should be inherited (e.g. Name, Chn, Layer Config (e.g. to import a drum map only), Steps, All) By storing templates into files the number of patterns wouldn't be limited, and we could easily share the presets :) Any other ideas? I splitted the thread and moved this part into the MIDIbox SEQ section. Best Regards, Thorsten.

Thats no problem if you give me a list/some concrete ideas It was clear to me that sooner or later somebody will request to load predefined labels/maps from SD Card. But the reason why I don't store them in RAM is neither lack of programming skills, neither lack of time, but just because I want to reserve the remaining 4k RAM for more useful features. ;) There could be a way to transfer a .txt file from SD Card into flash memory later. Or alternatively: to provide different preset patterns stored in a special bank. Would the availability of preset patterns really slow down the editing process so much - would a text file entry complicate the editing process too much? What would people prefer? (I for myself would prefer to edit preset patterns directly from the MBSEQ CS instead of using a text editor) But so long nobody sends me ideas for labels/drum maps I'm not sure how much memory should be reserved for this. In addition, I will have to balance the memory usage with the required code size for future features. My proposal: write a new forum topic in the MBSEQ section with a list of your label/drum map ideas. Let other users add their own ideas. This should give me a good overview about the requirements, so that I can implement the appr. functions into the firmware quickly w/o the fear that I will have to change the programming concept again and again due to new requirements. Best Regards, Thorsten.

Such informations are mainly available in a hidden forum section for programmers only ;) However, some quick notes are located here StrydOne started a tutorial for Windows users here - it should still be valid with one exception: probably it isn't required to install MinGW and to copy the make.exe anymore, as somebody told me that MSYS now contains a working make.exe version. Btw.: could you please check this? It would really simplify the installation procedure: - install the precompiled GCC toolchain - install MSYS - set the MIOS32_* environment variables -> ready :) Could you please inform me about the additional labels that you are using later, so that I can integrate them into the official release? (there is enough memory free) Best Regards, Thorsten.

Thats a classical race condition - it's unpredictable which core will be ready for receiving MIDI events first (e.g. it depends on the code which is executed in the Init() function). Another issue: interrupts are not enabled during Init() - than longer it takes, than longer the core won't be able to receive MIDI events. Do you generate this "hello message" for debugging, or is it required for your application? In this case, there are much better methods which I could propose. MIOS specific SysEx events generated by the first core are filtered by the second core. They are not tunneled to avoid feedback loops. You could temporary turn your second core into a common MIDI merger (w/o endpoint enable) by using the Debug Tool which is integrated into MIOS Studio. It allows you to execute the MIOS_MIDI_MergerSet() function with WREG=1 (=MIDI merger enabled) for Device ID 01, so that MIOS specific messages of the first core are forwarded by the second core. See answers above - both are explainable and expected. Best Regards, Thorsten.

Thats normal under Win98SE, WinME and WinXP Great! :) Best Regards, Thorsten.

Thank you! :) And: POIDH! (the forum has such a nice gallery function now where we can archive user pics) Best Regards, Thorsten.

Hi Andy, it looks like a driver is installed on your PC which overwrites the original Microsoft Audio device driver. E.g., Nils noticed this with the "Logitech QuickCam" driver, and after he uninstalled it, USB MIDI was working again. You are always able to upload via regular MIDI. But you will really miss the fast USB speed (100x faster than MIDI) If you have the option, I strongly recomment you to use MacOS (*) - in distance to Windows, the USB MIDI driver implementation works perfectly without any limitations! :) And in distance to Linux, it is guaranteed that it will work without additional driver installation/troubleshooting/incompatibility issues. Best Regards, Thorsten. (*) note that MIOS Studio requires mmj or Mandolane to access the MIDI ports in Java.

A new version of MIOS Studio is now available for download. Changes: Enhanced MIDI Filter GUIGUI elements saved to XML filesAdded MRU lists for workspace configurations, MIDI filter definitions and hex filesLoading of .hex files into upload window now significantly faster (relevant for large MIOS32 projects)added SysEx Send/Receive window As always: thanks Adam for help! :) Best Regards, Thorsten.