TK.

It will work again once I get access to the backup. Most pages (58 .html files) are repaired now based on my private backups or new package releases. Best Regards, Thorsten.

Hi, a script kiddie has attacked the midibox.org server through a security hole. Some files have been modified (links to a phishing site have been added), but I've a complete log so that all changes are documented. I quickly repaired the most important pages with default files or personal backups, and waiting for Twin-X to get access to the latest backup files. Best Regards, Thorsten.

Shipped today: ballpein PTOPRoJect Flexinoodle Protosx lindeborg Sold out! Best Regards, Thorsten.

Ich habe ein aehnliches Problem mit P18, und bei mir liegt es an einem Scanner Treiber, der im Hintergrund immer mal wieder ueberprueft, ob der Scanner angeschlossen ist. Wenn ich ihn deaktiviere, gibt es keine sporadischen Aussetzer mehr. Gruss, Thorsten.

I don't see a reason why MIOS_MF_FaderMove() should behave different if called from another hook, it should even work from an interrupt service routine. But there could be an issue with the "manual move detection", because your faders are not moved precisely enough, so that the driver "assumes" that they are manually moved. In such a case, MIOS_MF_FaderMove() positions will be ignored for a short timespan. In order to overcome this, just call MIOS_MF_TouchDetectionReset(<fader-number>) before calling MIOS_MF_FaderMove(<fader-number>, <new-position>) Best Regards, Thorsten.

Mute scenes are feasible, but the described handling conflicts with the multi-mute selection, as you already noticed. I also find it confusing, if settings for a song have to be done in another page. Any other ideas? probably yes ;) no problem yes, meanwhile the MIDI IN Port for Transposer/Arpeggiator/Recorder can be selected between "All" and an individual port. With a separate selection it's possible to define the MIDI Clock Source port. Best Regards, Thorsten.

Thats normal, but I will improve this in one of the next releases. Best Regards, Thorsten.

Hi, there shouldn't be a performance problem, especially not with sm_fast or sm_slow, as these routines are executed much faster than a new MIDI event could arrive. How does it work if the first core is removed from the chain (keyboard directly connected to MIDI In of second core which executes sm_fast)? If you still notice failures, try a dummy application w/o any app code but Merger enabled. If you still notice failures after such a change, it's a hardware issue (hints to such issues later if required) Best Regards, Thorsten.

Ok, so it is the MIDI interface. I would propose to check an alternative MIDI Monitor (e.g. MIDI-Ox) to ensure, that the problem isn't related to your Java installation. It could also make sense to check the MIDI cable (or just try another one if available) Best Regards, Thorsten.

Thanks for testing - this simplifies remote diagnosis :) One purpose of the test is to check the SysEx robustness of a MIDI interface, but another purpose is to check, if the chain: MIDI Out of your MIDI interface -> MIDI In of Core Module -> MIDI Out of Core module -> MIDI In of your MIDI Interface is working. For this test, you could also send MIDI Notes (e.g. with a virtual keyboard), or any other MIDI event just to check if it goes through the chain. MIDI Data displayed by the MIOS Studio Output monitor should also be displayed by the Input monitor. Apparently there is an error in the chain. Now you've already an hint, that the error isn't related to the PIC. Accordingly, it isn't required to update the firmware (usually it isn't required to update MIOS or the firmware anyhow, it's very very unlikely that the internal flash memory gets corrupted) Next test: check if your MIDI Interface is working. Loopback MIDI Out->MIDI In of your MIDI interface, and send some MIDI notes with MIOS Studio. Result? Best Regards, Thorsten.

Could you please try TEST INOUT1 - this test ensures, that the whole MIDI IO path is working w/o the PIC. Depending on the results we could give you more hints Best Regards, Thorsten.

Great work guys! :) Would you borrow me your Solder slave for creating a duo coloured 16x16 BLM? ;) Best Regards, Thorsten.

Thank you! It fits nice below the daily Dilbert :) Best Regards, Thorsten.

Congratulations! You mastered SMT soldering! :) Best Regards, Thorsten.

I would expect D7, D6, D5, D4, D3, D2, D1, D0 (see also this table) How is MIOS_DOUT_PinSet() triggered - via buttons, MIDI, MIOS Studio, ...? Best Regards, Thorsten.

Thats normal - Patch #1 is always redirected to the internal EEPROM, and the EEPROM can only store a single patch. The appr. patch slot in BankSticks is used for other purposes Best Regards, Thorsten.

Solved in MBSEQ V4! :) // take next step if it will be reached "soon" (>80% of current step) if( SEQ_BPM_IsRunning() ) { u32 timestamp = SEQ_BPM_TickGet(); u8 shift_event = 0; if( t->timestamp_next_step_ref <= timestamp ) shift_event = 1; else { s32 diff = (s32)t->timestamp_next_step_ref - (s32)timestamp; u32 tolerance = (t->step_length * 20) / 100; // usually 20% of 96 ticks -> 19 ticks // TODO: we could vary the tolerance depending on the BPM rate: than slower the clock, than lower the tolerance // as a simple replacement for constant time measuring if( diff < tolerance) shift_event = 1; } if( shift_event ) { int next_step = seq_record_step + 1; // tmp. variable used for u8 -> u32 conversion to handle 256 steps properly if( next_step > tcc->length ) // TODO: handle this correctly if track is played backwards next_step = tcc->loop; #if DEBUG_VERBOSE_LEVEL >= 1 MIOS32_MIDI_SendDebugMessage("Shifted step %d -> %d\n", seq_record_step, next_step); #endif seq_record_step = next_step; t->state.REC_DONT_OVERWRITE_NEXT_STEP = 1; // next step won't be overwritten dont_play_step_now = 1; // next step will be played by sequencer, and not immediately } } [/code] Intensively tested by recording drum/mono/poly sequences which are played by Logic Audio, shifted by delays of +/- 20% of a 16th note. Best Regards, Thorsten.

Ok, das ist der Fehler. Aus dem Schaltplan: Gruss, Thorsten.

You shouldn't get dropouts, as the MIDIbox firmware gives the incoming MIDI stream higher priority than internally generated MIDI events to avoid the typical "bottleneck" issue. There is a theoretical chance that you will notice dropouts with standalone MIDI mergers like "midi solutions" merge box or "kenton" midi merge or "motu" midi timepiece, since they get two input streams with the same baudrate, don't prioritise MIDI streams, and have to output the events with the same baudrate again -> bad! Best Regards, Thorsten.

Hallo, ...und die 8 x 10k Pull-Up Widerstaende entfernt? (bzw. gar nicht erst auf die Platine geloetet?) Im setup_midibox_lc.asm File INITIAL_DISPLAY_PAGE auf 2 setzen und neu assemblieren, oder den Display Modus waehrend der Laufzeit mit LAYER+PAGE2 umschalten. Die LAYER Taste befindet sich defaultmaessig auf D7 des elften Shift Registers, und die PAGE2 Funktion auf D2 des ersten Shift Registers, solange die LAYER Taste gedrueckt ist. Alle verfuegbaren Funktionen sind im src/lc_io_table.inc File aufgelistet, und lassen sich dort auch auf andere Tasten mappen. Gruss, Thorsten.

This topic has been moved to Fleamarket. [iurl]http://www.midibox.org/forum/index.php?topic=13380.0[/iurl]

The prices are fair. It would be nice if you could sell the parts through the forum. Inside the community they should be in good hands. :) Therefore I moved this article to the fleamarket. Handling this as a single purchase could be difficult, but it's your decision. Best Regards, Thorsten.

Hi, yes, you are right. The volume parameter wasn't updated correctly. Since you are not the first one who complains about the pitch depth, I reduced the intensity by factor 4 - more doesn't make sense, as you won't notice any effect anymore due to the (low) 16bit resolution of the frequency register. It isn't possible to provide an alternative CC I hope that this change won't lead to MIDI IN buffer overruns if all voices are modulated, as it increases the synth update cycle by ca. 10 uS! The synth engine already extremely loads the CPU, so that I cannot exclude failures anymore. Here a snapshot of the current version - please try and give feedback: http://www.ucapps.de/tmp/midibox_fm_v1_1d_rc2.zip Best Regards, Thorsten.

Ich wohne in Muenchen/Altperlach - bekannt durch die Forschungsbrauerei ;) Du kannst gerne mal vorbeikommen, um an einer realen MIDIbox zu drehen. Gruss, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=13331.0[/iurl]