TK.

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]

Fantastic work! :) Best Regards, Thorsten.

Max/Msp can handle MIDI messages as well. The advantage of OSC is the more comfortable and more flexible usage, but it isn't faster (in distance, it loads your PC as well as the STM32 core more than compact MIDI messages). However, STM32 is fast enough so that you won't notice a drawback on typical usecases. Why not connecting your TG77 directly to the STM32 core? ;) You can set the program change in a mixer map, and a mixer map can be combined with patterns in "phrase mode" An OSC method could be implemented which allows to modify the mixer map via OSC messages. Yes, no problem - OSC path "/aout/<port>/<channel>/value" Yes, thats possible - I already tried this with my STM32 based OSC->CAN bridge, which acts as a proxy between Reaktor and MBSID V2. But I noticed that the CPU usage of Reaktor increases dramatically once the LFO waveform is sent with an update rate of more than 1 kHz. This wasn't an issue while sending the LFO waveform via MIDI. The issue could somehow be related to the ethernet driver of my Mac, or to Reaktor itself. I haven't tried this under Windows yet... Best Regards, Thorsten.

my early work - most .sid files are only remixes created with a selfwritten C64 based SID tracker (of course) - at this time I already noticed, that sequencing without a sophisticated control surface is hopeless due to my underdeveloped musical talents ;)

Hi Dave, the MBSEQ V4 firmware is in a pretty good state meanwhile - all functions I've implemented so far are working flawlessly, and whenever I find the time (currently not so often...) I'm able to add new features with much less effort than with the old PIC based firmware. I also already did some experiments with OSC via Ethernet and don't see a blocking point. E.g., I controlled the motorfaders/buttons/LEDs of my MBLC via OSC datagrams from an Reaktor environment, and I also tried an OSC->CAN bridge which works fine. So, for the MBSEQ V4 controlling the BLM matrix via OSC wouldn't be a big task, maybe 15 lines of code since the OSC parser is implemented in a very generic (and flexible) way. Also increasing the number of BLM lines isn't a big problem (from the software side), as the driver provides parameters to define the number of rows and columns. MBSEQ V4 itself will be able to send and receive OSC messages via ethernet. The configuration has to be done in a (simple) .c program, because this is much more flexible (and less RAM consuming) than providing a configuration file which is read from SD Card - this also means, that there won't be a limit to customize the OSC server/client for your own needs. Example for sending a button value: ///////////////////////////////////////////////////////////////////////////// // Send a Button Value // Path: /cs/button/state <button-number> <0 or 1> ///////////////////////////////////////////////////////////////////////////// s32 OSC_CLIENT_SendButtonState(mios32_osc_timetag_t timetag, u32 button, u8 pressed) { // create the OSC packet u8 packet[128]; u8 *end_ptr = packet; u8 *insert_len_ptr; end_ptr = MIOS32_OSC_PutString(end_ptr, "#bundle"); end_ptr = MIOS32_OSC_PutTimetag(end_ptr, timetag); insert_len_ptr = end_ptr; // remember this address - we will insert the length later end_ptr += 4; end_ptr = MIOS32_OSC_PutString(end_ptr, "/cs/button/state"); end_ptr = MIOS32_OSC_PutString(end_ptr, ",ii"); end_ptr = MIOS32_OSC_PutInt(end_ptr, button); end_ptr = MIOS32_OSC_PutInt(end_ptr, pressed); // now insert the message length MIOS32_OSC_PutWord(insert_len_ptr, (u32)(end_ptr-insert_len_ptr-4)); // send packet and exit return OSC_SERVER_SendPacket(packet, (u32)(end_ptr-packet)); } [/code] On a similar way you will be able to generate messages sent by the sequencer itself. Arduinome: you have to consider, that Monome (and derivatives) always require a PC based proxy to convert text messages into OSC datagrams. This means, that it doesn't really matter if the HW device itself sends MIDI or text messages or any other format, since a proxy has to convert them anyhow. Therefore - so long a proxy is used anyhow - I don't really see an advantage if the HW sends text based messages instead of MIDI messages. In distance, using MIDI messages would speed up the transfers, since they are more compact (IMHO a design flaw in Monome) For MBSEQ this means: so long it isn't a problem for you to use a proxy (like for Monome) to convert a datastream into OSC messages, you could use the common MIDI protocol, sent via USB (-> superfast!) This also has the advantage, that you can configure OSC messages in the proxy (very flexible, as the firmware doesn't need to be touched) If you prefer a standalone OSC solution which works without OSC proxy, and is able to send directly to ethernet, the "true OSC" option for MBSEQ could be interesting for you which only requires a MBHP_ETH module in addition. Components: the old Frontpanel can be re-used. An improved (and easier to build) frontpanel is provided by Wilba. Only the core module has to be replaced by MBHP_CORE_STM32 A SD Card is strongly recommented (no support for BankSticks anymore) And MBHP_ETH is optional The MBHP_CORE_STM32 PCB itself is final - SmashTV is still working on a solution for providing presoldered STM32s when shipping the kits, which saves you from soldering SMT parts Best Regards, Thorsten.

Hi, the PIC based MIOS doesn't allow you to add interrupt handlers (this has changed in MIOS32) This means, that the timer overrun flag has to be polled by a routine which is executed periodically (e.g. from the USER_Timer hook, if it is called more often than the target interval of TMR0) Under http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fsid_se.inc You will find a very simple example - the BPM generator is executed from USER_Timer each mS, but it uses it's own time base TMR0 ;; check timer0 overrun flag BRA_IFCLR INTCON, TMR0IF, ACCESS, SIDSE_Clk_NoInc bcf INTCON, TMR0IF ; clear overrun flag SET_BSR TIMER0_RELOAD_L bcf T0CON, TMR0ON movf TIMER0_RELOAD_L, W, BANKED ; (dummy add to update TMR0H, and to get carry flag of addition) addwf TMR0L, W ; (update TMR0H) movf TIMER0_RELOAD_H, W, BANKED addwfc TMR0H, F movf TIMER0_RELOAD_L, W, BANKED addwf TMR0L, F ; 16bit register update takes place with this write bsf T0CON, TMR0ON SET_BSR SID_BASE SIDSE_Clk_Inc ... your code which will be executed periodically SIDSE_Clk_NoInc [/code] TIMER0_RELOAD_[LH] defines the timer interval: 0x10000 - (interval / (2*100 nS)) e.g., a reload value of 0xc000 leads to an interval of 3.277 mS Initialisation in USER_Init: [code] ;; ensure that timer0 interrupt not enabled bcf INTCON, T0IE ;; internal clock source, 16bit, prescaler 1:2 movlw (1 << TMR0ON) movwf T0CON Best Regards, Thorsten.

You have to post your public DSA key here: http://www.midibox.org/forum/index.php/topic,10644.0.html Best Regards, Thorsten.

Meanwhile I got more requests than available GM5 chips - so, the preorder phase has started again! I've still some GM5 chips in stock, and I'm waiting (again) for people to pay their order. Deadline is next monday. Best Regards, Thorsten.

Die Nullen tun nicht weh. Allerdings befindet sich in Deiner Doku noch ein Fehler: das 64k Derivat heisst PIC18F4620, und es ist nicht 1:1 binaer-Kompatibel. So werden die ADC Kanaele bspw. nur mit der MIOS Version im pic18f4620 Verzeichnis richtig initialisiert. Ein PIC18F457 wird nicht unterstuetzt (gibt es den ueberhaupt?) Solange man den Dump auf das gleiche Derivat aufspielt, sollte es keine Probleme geben. Gruss, Thorsten.

To have the same understanding: the MBSID firmware is doing *much* more than simply bridging a MIDI synth to the SID chip. You won't achieve the same possibilities by controlling the SID from external. Best Regards, Thorsten.

It's somehow cool, but it leads to borring results. You will really miss the mighty MBSID sound engine :) However, some time ago I did some experiments with controlling SID registers directly via OSC protocol. The MBHP_CORE_STM32 module is used as an Ethernet->CAN proxy: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fmbsid_can_osc_proxy%2F This allowed me to write into the registers of up to 8 SIDs from an Reaktor environment. OSC Path: /sid<sid>/<l|r>/<1|2|3>/direct/frq, .../pulsewidth, .../ctrl, .../adsr E.g., "/sid1/l/direct/frq 440.0" to change the frequency of SID1, left channel to 440 Hz, or "/sid*/*/direct/adsr 0 0 15 0" to change the envelope parameters for all SIDs There is also a path to control the gates of all SIDs with a single message. I was able to play an additive synth (24 voice organ sound! :)) directly from Reaktor, even FM and PW modulation from Reaktor was possible :) Alternative solution: use the ASID protocol, which allows direct access to all registers as well. It works with SysEx messages, is the fastest solution for UART based MIDI and is already part of the MBSID V2 firmware (no additional core required) -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fsidplay.inc But the resulting sound is very C64 like due to the slow update rate of max. 70 Hz. However, some people like this ;) Best Regards, Thorsten.

The specified pulsewidth for the CS# and WR# input (tCSW and tWW in the datasheet) is 100 nS. The MBFM_REG_Write routine generates a pulse of ca. 200 nS to be on the safe side, but it could be that with such a long cable the pulse will be shorter due to the higher impedance, accordingly the required timings will be violated. It would be interesting if it works better with long cables if more than one NOP is inserted between CS=0 and CS=1, e.g. try: bcf MBFM_LAT_CS, MBFM_PIN_CS ; activate chip select line nop nop ; + 100 nS nop ; + 100 nS bsf MBFM_LAT_CS, MBFM_PIN_CS ; release chip select line [/code] Note that this change has to be done at two places. Best Regards, Thorsten.

Too bad, it was such a nice logical explanation ;) This shouldn't be a problem so long the bipolar PSU is powered on before the application is booting, because the driver will reset the YMF262 in MBFM_REG_Init to ensure defined starting conditions before OPL registers will be initialized. Best Regards, Thorsten.

You've now access to the programmers section of this forum, where you will find the informations to get SVN access. Best Regards, Thorsten.

The unique ID isn't explicitly forwarded by MIOS32, the calculation is OS dependent (e.g. by name, vendor/product/device ID, USB node, etc...) Best Regards, Thorsten.

I think that I found a logical explanation for this failure effect. From the beginning: first I had the idea, that this failure could happen if D6 and D7 are clamped to 0V, since bit #6 and #7 of address 0xc0..0xc7 control the audio channel C/D assignments. But by "forcing" these bits to 0 via SW there was no sound at all. But I didn't give up and tried out other bits forced to 0. Finally with D2 forced to 0 I noticed the described behaviour: I hear a sine sound on Channel A and B, but not on Channel C and D So - could it be that our hero forgot to run the interconnection test completely before asking for support in the forum? ;) And could it be, that our hero cannot differ between a 1kHz sound, and a ca. 500 Hz sound? (because with D2 forced to 0V the resulting frequency is ca. one octave lower) ;) I'm curious - unfortunately this nice explanation doesn't work if I try this out on the MIDIbox FM firmware - most patches sound completely wrong. /Edit: another possibility - maybe our hero swapped two data lines? Best Regards, Thorsten.